With Dolphin in the thick of the 5.0 feature freeze, things were expected to slowdown a bit. Some of us were worried there wouldn't even be enough content for a Progress Report! Alas, while the gears have shifted toward different things to prepare for a release, there is no shortage of interesting changes. As an added bonus a feature implemented three years ago was rediscovered! That kind of thing just seems to happen over the course of a project.

Work toward Dolphin 5.0 has continued; but, a lot of these cleanups have come at a cost. There have been some noteworthy regressions (notably with netplay) and through testing we've noticed some broken features that have been working incorrectly for some time. As Dolphin approaches its next release, we hope that users will continue to update to the latest dev builds and test for regressions and issues so they can be caught before 5.0 is in everyone's hands.

Something to notice about this Progress Report is that we heavily leaned on Dolphin's FIFOCI infrastructure for screenshots and examples. These images were automatically generated on a server without user interaction and were taken from the exact same frame of instructions sent to the emulated GameCube/Wii GPU. Of course, FIFOCI is limited to graphical bugs, and certain graphical bugs at that. Without FIFOCI, it's possible that these changes would not exist, or if they did, there wouldn't be an easy way to verify what they fixed. In the case of the Wrap Negative Indirect Texture Coordinates, it was developed as a fix for F-Zero GX, but FIFOCI discovered it also affected Skyward Sword.

Notable Changes¶

4.0-8581 - Throttler: Rename "framelimiter" to "emulation speed" by degasus¶

A constant problem for the developers is designing the interface so anyone can understand it, especially as layers of decisions pile up over the years. One such case was Framelimit. The interface for the Framelimiter simply presented a number, without any explanation of what it was. To the devs, making it vague made perfect sense - the precise definition of "frame" varies significantly and it would be very difficult to explain. So the developers settled on a far superior option: the Auto setting. Auto adjusts the Framelimit based on what the game tells the console, and since it is default users never need to touch the Framelimiter at all. So the devs left it at that, confident that everyone would either not mess with it or know to change it back to Auto if something ever went wrong. ...bad assumption.

The number in the Framelimit that some users were unfortunately changing represented the vertical blanks per second (VPS) of the emulated console. VPS is the console's screen refresh cycle - 60hz for NTSC and 50hz for PAL - which for display support reasons cannot change. Frames per second (FPS) can vary from game to game as a fraction of VPS, so by labeling the Framelimiter in VPS instead of FPS it will remain consistent across all games of a region. But the Framelimit setting didn't directly change the VPS. The console is designed to keep the clockspeed and bus in perfect sync with the VPS; touching the VPS alone would break everything! So instead, Dolphin adjusts the clock rate of the entire console, changing the "rhythm" of the emulated system at a percentage of full speed. 60 was 100% for NTSC games, 50 was 100% for PAL games. Unfortunately PAL60 was also 50 as 100%, which was just awful.

So why didn't the Framelimit interface show a percentage? When it was originally created long ago, it had a checkbox: Limit by FPS. Toggling this on turned the Framelimiter into a direct FPS control. While it had some uses, many users were making the horrible decision of turning it on and leaving it, breaking games and creating a LOT of forum threads! That option was removed years ago, but the strange undefined number continued to cause confusion.

Until now! Now the Framelimit is called the Speed Limit, letting users manipulate how fast the emulated console runs with a percentage. Which is exactly how it has always worked and probably how it should have always been labeled. Sometimes very confusing issues have very simple answers!

4.0-8583 - HiresTextures: Also look for directories with 3-character IDs by JosJuice¶

This simple change allows Dolphin to use a texture pack on any region of a game. This means that if there is an NTSC texture pack for Super Mario Sunshine and some of those textures are identical in the PAL version, a single GMS texture pack folder can be used for both games. This will make creating texture packs for multiple regions easier and more compact. Prior to this, the NTSC texture pack would have to be in GMSE01, the PAL in GMSP01, and the NTSC-J in GMSJ01, etc.

4.0-8586 - Poll for controller input at the correct time in a frame by booto¶

In order to set the stage for this one, we need to travel back to a simpler time. The year was 2008. The latest revision of Dolphin was r873, Super Mario Galaxy 2 was but a twinkle in Miyamoto's eyes, and the Wii was the hot new console selling faster than it could be put on the shelves. This was time when someone reported issues with the controls in Sonic Heroes with Issue 237, a problem that has continued all these years.

What exactly is this seemingly eternal issue with Sonic Heroes? This bug was first noticed in the multiplayer modes of the NTSC version, but it also affects all modes of the PAL version. When the player would attempt to hold a button, rather than actually reading it as held, the game would act as though there was an autofire enabled. Worse yet, this didn't just apply to buttons, it applied to both sticks and the analog shoulder buttons making any movement completely impossible.

Nearly eight years later, with Dolphin booting almost every GameCube games and much of the Wii library flawlessly, Sonic Heroes still suffered from this issue. Finally, on January 6th, 2016, booto decided enough was enough and actually looked into the issue to figure out what the game was doing. Shockingly, he found a pretty serious problem that likely affected many games. Dolphin was actually polling for input at the wrong part of the frame, so, the game would check for if a button was being held, and Dolphin wasn't actually checking for input at that exact moment. This bug also applies to other games; you may notice games like Super Smash Bros. Melee feeling a bit more like console. Any game that relies on very specific or subframe inputs should be noticeably affected; assuming both the user and game are precise enough!

Note: In order to maintain this fix into input recording and netplay, a prior hack (forcing netplay/movie input polling to 120Hz) was removed. This means that on netplay, pad buffer must be calculated differently than before, and in many cases will appear to be higher. This does not mean there is more latency. This hack was originally introduced as way to reduce desyncs, but upon testing both movie recording and netplay still work properly. Obviously, any input movies recorded prior to this build will no longer work on the latest development builds.

4.0-8601 - [Android] Add support for the Wii U Gamecube adapter under Android and 4.0-8858 - [Android] Implement Gamecube Input setting screen by Sonicadvance1¶

Dislike touchscreen controls on your phone/tablet and have a USB OTG port? How about using that handy Wii U GameCube Adapter that Dolphin now natively supports on Android! Just imagine playing Super Smash Bros. Melee while walking down the street; the amazing 10 FPS gameplay, the glitchy graphics, the controller adapter bigger than your phone, and a radical cord ready to trip you at any moment. What a badass you would be! Seriously, the Nvidia SHIELD Android TV has an ok controller, but the GameCube controller is the best, and completely accurate for Dolphin. Perfect controls await!

Nothing beats that new menu smell!

"But wait, I thought Dolphin was in feature freeze? This is a new feature!" Correct! Since Android is not going to have a 5.0 release, there's no need for it to be in the feature freeze. Android users will continue to get new features during the freeze! A few other exceptions are planned too.

4.0-8640 - Better Video Mode Detection by phire¶

Prior to this point, Dolphin has had to detect many video modes from games and calculate the aspect ratio accordingly. This isn't about 16:9 vs 4:3 or anything like that; the Wii itself is capable of outputting a lot of video modes. While it would be fairly easy to hard-code and hack Dolphin to handle each situation, phire decided that wasn't good enough and embarked on a long journey to rewrite how aspect ratios were handled.

This build changes it so Dolphin no longer calculates aspect ratios by pixels, but rather by the signal timings. By deriving the aspect ratio like this, Dolphin can now handle any aspect ratio or video mode sent by the game without special cases or hacks. Conventional video modes like 240i, 240p, 480i, 480p will all provide the correct video output. Even strange video modes that homebrew can sometimes use, like 960i or 243@59.74hz will be handled without issues!

The strange case of 240p before

Now it's rendered correctly

The best thing is, outside of fixing double-strike games (240p), the best way to tell this change is working correctly is to see no real change in output! So, for most people, this huge change will affect absolutely nothing.

Depth Fixes¶

• 4.0-8666 - Render: Clamp the z range to the full range by Armada¶

• 4.0-8723 - VertexShaderManager: Add an epsilon hack to the perspective projection by Armada¶

• 4.0-8709 - TextureConversionShader: Also invert color encoders if they're used to encode depth by Armada¶

One of the consequences of the many, many depth changes is that no matter how many things that are fixed, Dolphin keeps running into edge cases very hard to emulate on current GPUs. The eventual goal of these fixes is to remove the need for slow-depth at all; so that fast-depth can be enabled permanently. As well, there are many bugs shared between fast and slow depth that need to be quelled. This month, three depth issues were taken down that certainly make things more visible and more playable.

GoldenEye 007

It turns out that prior to this our near (close to the screen clipping) value was slightly above zero instead of actually zero. This caused bugs, and thus the clamp was modified to actually reach zero now. Unfortunately, this only works for fast-depth. Don't let the name fool you; fast-depth is actually more accurate than slow-depth on most GPUs.

Now that's password security

But he is a spy, after all

Sonic Adventure DX

A few users have been complaining about this one for quite a while. In the case of Sonic Adventure DX the UI wasn't working in OpenGL back in 4.0.2. D3D didn't show any ill-effects. Strangely enough, OpenGL was actually closer to correct than D3D; a far bigger bug in D3D (breaking tons of games) was fixed, but, that same fix broke the Sonic Adventure DX UI. Being a Sonic game, it is only fitting that an epsilon hack, this time applied to perspective projection, was used to work-around the issue. The difference between this epsilon hack and the other one is that this one is most certainly a hack and not a true fix. After Dolphin 5.0 is released, this will be reverted and a better implementation that handles these edge cases will be developed.

Yet another Sonic game with missing UI issues

And yet another epsilon hack to work around it

Metroid Prime 2 Trilogy Scan Visor

This one is thankfully not a hack but a true fix that will stay in the emulator. Under the Direct3D video backend scanning certain objects in Metroid Prime 2 in Metroid Prime Trilogy didn't work and Samus would look off in a random direction and wouldn't actually scan. The problem was quickly found to be a regression from the D3D Depth Inversion change.

At first it was thought to be a fundamental problem with this technique, but after running a few tests there wasn't any indication that the Direct3D backend was inaccurate. As a last resort it was necessary to see what it would take to break the OpenGL video backend, to make it behave the same way. After changing some of the EFB-to-RAM code in the OpenGL video backend it became clear that D3D was failing to make a correct copy, because the D3D depth inversion wasn't applied to all the copies. After a simple correction for that problem the scan visor was able to scan all objects again.

4.0-8715 - Manually Wrap Negative Indirect Texture Coordinates by Stenzek¶

This is one of those issues where every driver seemed to handle the situation differently, and worse yet, handled it differently depending on OpenGL versus D3D. A long time ago before there were even Progress Reports, the switch from floating point to integer math for GPU calculations fixed the raindrop mask for F-Zero GX's "Lightning" courses.

If the skies were pouring this much rain it'd be very, very hard to see

Now all users can enjoy the spectacular Lightning tracks without graphical issues. Except maybe Android users. Sorry

It turns out Dolphin was letting the driver handle negative coordinates for indirect textures. This made the results inconsistent depending on which driver and which backend. By manually choosing the correct way to handle negative coordinates (wrapping), the bug is now fixed on all graphics cards on all backends. As a bonus, this also fixes some strange glitches on The Legend of Zelda: Skyward Sword's map.

Looks like the printer ran out of ink while printing the map. Cheap Skyloft printshops!

The premium printshops do a much better job. Still lacking some color that the original hardware has, though

4.0-8721 - Fix a typo on the size passed in to the IPL descrambler by konpie¶

There was a typo in the font loading code for the Japanese version of the GameCube's Main Menu. Can you spot the change?

This single character change fixes text in the Japanese IPL, allowing everyone to finally see what is going on. Oops. So, for all two of you out there with a dumped Japanese bios, this one is for you!

It seems as though fonts don't load correctly when you don't look in the right place

Now things look as though they should

Bargain Bin Treasures¶

One of the things that are important to verify Dolphin is doing things right is to throw a lot of test cases at it. Since most people don't exactly write hardware tests, the next best thing to that is to run a lot of games and hope they do something weird that breaks the emulator. In the process of doing that, a lot of very strange and interesting games have been found for exceedingly cheap. For those looking for a fun (sometimes even good!) or weird experience may want to buy these games.

Speed Racer: The Video Game¶

For a game that can be found used for only a few dollars, it's actually very, very good. Speed Racer: The Video Game has cheap menus and forced motion controls which is usually a recipe for disaster. Fortunately, the developers behind this game not only managed the Wii's motion controls, they somehow managed to capture the weird combat racing feel and make it fun in the process. While the game does have F-Zero like speed, a lot of the focus is on fighting and destroying your opposition while you race. Just remember it's a bit low on content, but the entire campaign can be played in splitscreen fully complemented by the entire AI field, making for a frantic and fun experience.

Beware, the multiplayer requires a fairly strong computer to run full speed in Dolphin!

Showtime Championship Boxing¶

On the opposite end of the spectrum is this disasterpiece. Showtime Championship Boxing has no redeeming qualities. The only interesting thing about the game is that it seems to use lag to time things, causing some weird timing issues even on console occassionally. Dolphin has the ability to remove all lag by overclocking the the Wii CPU and, by default, emulates a quasi-infinitely fast GPU. Combining these two features results in quite possibly the only entertaining thing to come out of this videogame.

Last Month's Contributors...¶

Special thanks to all of the contributors that incremented Dolphin from 4.0-8518 through to 4.0-8863!