A few months ago, we announced our intentions to work on and release Dolphin 5.0 with a new release method. By using a stable branch, we hoped to avoid doing a feature freeze so that devs could both work on new features and continue to stomp out regressions. Unfortunately... that didn't work. Users wanted the newest features to be in Dolphin 5.0, developers were confused on what features needed to go to what branches, and things more or less ended up not working out the way we hoped.

Sometimes, it's best to just admit a mistake and do things right, so, in order to provide users and developers with the clearest path for Dolphin 5.0, we will be restarting the Dolphin 5.0 release process from scratch. That means abandoning the stable branch (along with merging all unique fixes over into Master) and eventually implementing a full feature freeze in order to give time to close all regressions and make Dolphin 5.0 the special release it needs to be.

We hope that users are understanding of the delay. With that, let us continue with our regularly scheduled Progress Report action!

Notable Changes¶

4.0-7937 - Block WX input when detecting controls by mickdermack¶

The hotkey rewrite in Dolphin has been a work in progress for the past year as long awaited new features were introduced alongside a lot of unfortunate bugs and quirks. One of these quirks affected people trying to configure keyboard and mouse for hotkeys or emulated Wiimotes and GameCube controllers. Space, enter, escape, left click, middle click, and right click are used by wxWidgets for menu navigation, and if the user tried to assign them to a key, WX would pick up the keypress as a navigation command and then execute it! Pressing space, left click or enter would assign the key then instantly press it again and wait for a new keypress, assigning middle click would instantly clear it, escape would close the window, on and on. Of course the way around that was to right-click the function and assign it manually within the Configure Control window, but that's really silly isn't it? Why not just make it so WX navigation commands are disabled when assigning keys? Progress Report newcomer mickdermack brings a fix that does just that! Now assigning any of those navigation keys is as easy as any other.

4.0-7993 - DolphinWX: decompress discs to calculate MD5 hash by flacs¶

Ever since MD5 hash computation was built into Dolphin way back in 4.0-1415, users have been able to quickly verify and compare ISOs from within Dolphin. Unfortunately, space needing users that compress their discs haven't found a great amount of use from the feature. GCZs needed to be manually uncompressed in order to get the correct md5; otherwise it would return the hash of the compressed file! flacs resolves this problem with a fairly simple solution: decompress any ISO that Dolphin has compressed during md5 calculation on the fly and get the hash of the decompressed ISO. It does add to the calculation time, but it is important for it to be done so the MD5 hash calculations are correct.

Due to Wii disc encryption, Dolphin has to scrub junk data out of Wii discs when it compresses them. If a Wii ISO has ever been compressed, even by Dolphin, it will return different values from the original even if it is decompressed before the calculation. However this should not affect the ISO's performance in any way whatsoever, even for features like netplay.

4.0-8026 - Exchange XSaveWorkaround for ucrtFreadWorkaround and 4.0-8032 - Patch win7 ucrtbase, and note versions by shuffle2¶

Last month, Dolphin moved to Visual Studio 2015, getting a nice little speed up and lots of new optimization possibilities. But, change is never easy and while a bunch of compiler/library work-arounds were removed, Dolphin ended up needing a new one. The Legend of Zelda: The Wind Waker and other games began experiencing crashes and hangs. Even before the September Progress Report, Microsoft already had a fix prepared, but the patch is currently stuck in QA. Considering there is no time-table for the fix to be merged, shuffle2 has begun the job of patching the issue on each operating system. Currently, Windows 7 SP1 and Windows 10 are patched, and should play the games properly, but Windows 8 still has the bug.

If you encounter any new problems that can be bisected down to the VS2015 changeover, please report them on the Dolphin forums.

Now (most) users no longer have to fear this scene

4.0-8034 - Support Conservative Depth as a fallback for Early Z (Mesa support for ZCompLoc) by phire¶

Supporting various wonky GameCube features by abusing whatever API tricks we can has become a pastime for Dolphin. One of the features Dolphin once struggled with in D3D9 and OGL2 was zcomploc, but in the latest builds that feature is more or less solved by ARB_shader_image_load_store. The one exception to this is the OpenGL Mesa implementation used in Linux and other free operating systems, as it has poor support for this extension. Considering that Dolphin's FifoCI testing suite uses Mesa on several runners means that this is an definitely a problem for the emulator.

In order to work around it while the driver catches up, Phire implemented zcomploc through a more commonly supported extension (ARB_conservative_depth) as a fallback for drivers with poor support for the newer extensions.

Without proper zcomploc emulation, Mario Super Sluggers' minigames are ridiculously difficult

But now Mesa users can play the game with ease

4.0-8061 - Add Frame Advance Hold Hotkey Functionality by RisingFog¶

Ever since the old hotkey system was removed in 4.0-6612, Dolphin has had to adjust to handling features like holding various keys, key repress, how long a single tap takes, etc. All things that were previously automatically handled by wxWidgets now has to be taken into account. Sadly for TASers, Dolphin didn't really handle holding the "Frame Advance" hotkey close to a usable manner since the hotkey rewrite. This made Dolphin's latest builds mostly useless for anything requiring frame by frame input accuracy.

Thankfully, because Dolphin is handling this manually, people can also manually fix these nitpicks. While working on his Tony Hawk's Underground 2 TAS, RisingFog came up with his own solution to the hotkey issue and eventually submitted it. Now frame advance works in a logical manner once more.

4.0-8065 - Implemented GC Controller inputs via named pipes by spxtr¶

An often requested feature is the ability to control Dolphin through external scripts and programs. There are many advanced applications of this: from advanced Tool Assisted Speedruns to community experiments like Twitch Plays Pokémon. But so far, Dolphin has not had official support for any of this. The emulator used to support UDPWiimote which allowed sending controller inputs to the emulator through the network, but it was ultimately dropped due to lack of interest and maintenance in 4.0-2167. Some of this remote control can be done through the NetPlay protocol, but Dolphin's NetPlay is a complex beast, and mastering its use is overkill if the only need for it is sending controller inputs.

4.0-8065 introduces a new way of sending GC controller inputs to Dolphin from an external application. It uses a very simple protocol combined with Linux/OS X named pipes to achieve the wanted results in a minimal amount of code, reducing the maintenance costs of the feature. Windows support is not yet implemented but should be easily doable using the same interface.

4.0-8078 - [DolphinWX] Added warning to Wii disc compression by Helios747¶

As mentioned earlier, compressing Wii ISOs scrubs data from the ISO, irreversibly changing its MD5 hash values. This isn't a problem in and of itself, it's necessary to compress Wii discs and they will still work precisely the same afterward. But if a user doesn't know about this and they submit an MD5 Hash for our issue tracker, their ISO integrity may be questioned. While writing this, we came to the startling realization that no one knows this! Even many developers didn't know! And how could they? Without looking at the specific bit of code involved, there was no way to know how it works.

Realizing the problem, Helios747 stepped up to take care of it with the obvious solution - a popup.

Who says all solutions have to be complicated?

Fixing GPU driver bugs with FifoCI¶

FifoCI remains an important tool in debugging various graphical issues in Dolphin. This automated system plays back over 50 recorded fifologs in various graphics backends for every single change in to the emulator and notifies developers of any changes in behavior. For more information on how it works, feel free to check out the feature article on Dolphin FifoCI Infrastructure.

FifoCI showing a code patch fixing a lighting bug.

The unfortunate limitation of FifoCI is that it can only test on a few hardware/driver combinations. Coverage for Nvidia hardware on Windows and Linux is done via the use of Amazon's EC2 service, which provides the team with a cheap way to test Dolphin on real Nvidia GPUs. But until this month, we had no FifoCI coverage for hardware of other manufacturers. This month, using some of the money that the Dolphin Foundation gets through online advertisement, the project acquired an Intel NUC. Powered by a Broadwell i3-5010U and an Intel HD5500 GPU, it allows us to test every single change submitted to Dolphin with Intel's Linux drivers. Given that FifoCI already runs on multiple platforms without any issues, setting up this new test runner was expected to be a very quick and painless operation.

However, the first run of FifoCI on Intel GPU gave us an interesting surprise. Two of the 50 tests that are ran by through the infrastructure caused the Intel driver to completely crash, with messages about "GPU hanging" as an added bonus. Considering Dolphin's troubles with Intel GPUs, including many users reporting random or consistent crashes on startup, this immediately sent out red flags. After doing some basic debugging to confirm the Intel drivers were indeed causing the issue, delroth opened a bug report detailing the situation and provided a way for the driver developers to reproduce the crash. Very quickly, Kenneth Graunke, a developer from Intel, confirmed the issue and provided some initial findings from his own debugging. However, work on the issue quickly stalled. Four days later, being the hands on developer he is, delroth launched himself into the crazy task of debugging the problem while not knowing much about graphics drivers or Intel hardware.

One notable thing about Intel's graphics drivers on Linux is that they are open source, making analysis and debugging like this possible in the first place. After some random guessing and with the help of imirkin (developer of Nouveau, open source drivers for Nvidia GPUs on Linux), delroth was able to figure out several ways to work around the issue. And with a full night spent hacking at the problem and learning about the internals of GPU drivers, the bug was found: the use of the new ARB_shader_image_load_store in Dolphin was causing the Intel driver to forget state updates when switching between shaders. These forgotten state updates interacted badly with the "PMA fix" feature, used to optimize Hierarchical Depth Buffer (HiZ) access on Intel hardware. In the end, the confusion caused the hardware to hang, and the driver to crash. After the problem was pointed out to Intel developers, Kenneth cooked up a proper fix for the problem in less than an hour, which has now been submitted to the drivers. Open source collaboration between Intel, Nouveau, and Dolphin developers led to a serious driver problem being fixed. And, of course, Dolphin's new test runner could not be afforded without the support of our many loyal users and readers.

Yet there is no time for rest, as Dolphin's Intel FifoCI runner still runs into random rendering failures, seemingly related to EFB Copies. degasus has already been working on tracking down the issue, so stay tuned for more drivers debugging war stories next month!

Last Month's Contributors...¶

Special thanks to all of the contributors that incremented Dolphin from 4.0-7876 through to 4.0-8078!