Happy New Year! Now for the big news. On January 7th, 2016, we will be entering a full feature freeze in preparation for the Dolphin 5.0. A feature freeze is basically a period where we all devote ourselves to doing testing and fixing regressions to move us toward the Dolphin 5.0 release, and we've had one for every release we've done! During the feature freeze, no new "features" can be added to the emulator, and only bug fixes can be applied to master. Does that mean there won't be blog updates? No! The show must go on, and the Progress Report will monitor the fixes as they come in, plus there will be articles in the interim about the remaining bugs, some of the great features added since Dolphin 4.0, or just some articles that we've been wanting to put up and never have time.

But the feature freeze hasn't started yet! We have a nice full month of updates for you in this month's Progress Report.

Notable Changes¶

4.0-8258 - Fix Mario Kart Lenses Flare by phire¶

Ever since attempting to unify the EFB Copies to RAM and EFB Copies to Texture codepaths, little bugs have been popping up on both sides. In Mario Kart: Double Dash!! and Mario Kart Wii, the lens flare has always required EFB Copies set to RAM, but, as of recently, objects no longer could block the lens flare as it should! Looking through the changes revealed a simple, yet silly mistake: Dolphin was now storing certain EFB Copies in an incorrect format. Sorting that out fixed some potentially game breaking visual bugs in many games, including Mario Kart: Double Dash and Mario Kart Wii.

Poor Mario is so blinded by the sun he can't see the HUD!

With everything stored in the correct format, the game works normally

4.0-8325 - Real Wiimote Handling fixes; -TR support on Windows 8/10 standard bluetooth by jloehr¶

Sometimes, a project being around for a very long time leads to some outdated viewpoints and bad assumptions. The RealWiimote system was started even before Dolphin went open source in 2008. Back then, Windows 7, 8, and 10 did not exist, and the Wii Motion Plus was nothing but a twinkle in Miyamoto's eye. With RealWiimote built for the original Wiimote and older versions of Windows, when the [RVL-CNT-01-TR Wii Remote Plus] began to appear, it threw everyone for a loop. For a reason no one understood, the -TR wiimotes were able to connect in Linux and OS X, but on Windows they were only able to connect when using the Toshiba Stack, and later, the DolphinBar. The Dolphin developers correctly assumed it was impossible to get -TR Wiimotes connecting on Windows default bluetooth stack, the MS bluetooth stack, due to limitations in what it implemented. The only solution for those stuck using it was staying to the older wiimotes, an increasingly problematic trait since Nintendo stopped making them in 2012.

Thanks to newcomer jloehr this all changed in 4.0-8325. jloehr had already written a Wii Remote connection program separate from Dolphin as part of his bachelor thesis, and had no trouble getting the newer -TR Wiimotes to connect in newer versions of Windows. With this vast knowledge in mind, he made some serious changes to how Dolphin connects and communicates with Wii Remotes, despite limited knowledge of the emulator. Here he is giving a quick technical overview of his changes.

The distinction between Microsoft and Bluesoleil Bluetooth Stack (old code) was cleaned up, and a new API for Windows 8 and higher was implemented (the same that is used for the Toshiba Stack, but slightly different parameters to get it working). The new way/API is unfortunately not working for Windows 7 due to a bug in the Windows HID Class Driver, otherwise all those changes would also affect Windows 7. A distinction detection for the Toshiba Stack was implemented, by examining the Provider Name of the Class Driver of the HID Device.

This all adds up to one very nice addition: -TR Wiimotes now work in Dolphin on standard Bluetooth adapters in Windows 8 and 10! Along with this, there were added fixes to Wiimote Index LED and Wiimote preparation code to make things work better. Wiimote audio also was improved on the -TR Wiimotes, but was still quite buggy, at least until a later fix was added on top. We'll be getting to that soon enough.

4.0-8327 - Configurable Audio Latency by degasus¶

Audio latency in Dolphin has changed a lot since Dolphin 4.0. Because Dolphin adopted working synchronous audio (at least in HLE) so late in its development, there were tons of bugs and issues preventing audio from being prompt and proper. Whether it's a strange bug with a ringbuffer overflowing after 90 minutes of play causing bugs or latency so high that it prompts complaints from users, Dolphin has been playing catchup because of an unhealthy addiction to asynchronous audio earlier on in its development. There are emulators that can get away with asynchronous audio without many repercussions; Dolphin (and any GameCube/Wii emulator for that matter) isn't one of them, so the goal has become focusing on making synchronous as pleasant as possible.

This build gives users a (for now hidden) setting that they can adjust. Users preferring smoother audio during slowdown can adjust TimingVariance in the Dolphin.ini upward, where as users desiring lower latency audio can adjust it downward. For users already running full speed in 60 FPS games, there is no performance penalty in lowering TimingVariance to 17 and shaving off nearly 2 frames of latency over the old defaults. People with faster computers can go even lower; sometimes knocking audio latency to console levels!

Most casual players won't notice any difference with this. For the most part, players of music rhythm games and competitive fighters that rely on audio cues will be the most pleased with this. Three frames lower audio latency may not seem like much to most people, but when a game revolves around audio, it can be just as damaging as input latency!

4.0-8340 - Video Interface: Wait until start of Active Video Lines to Sample External Frame Buffer (XFB) Address by booto¶

XFB Disabled has been the default option in Dolphin for as long as it has existed, even though many (roughly 10 - 15%) games require some form of XFB to output graphics correctly. Popular titles like Star Wars: Rogue Squadron II and III, Bomberman Jetters, and... well, tons of games that aren't as popular. Let's be completely honest: the only reason that XFB disabled is our default is that none of the Zelda or Mario games really need it for anything. And for those games that do require it, we could always use the INI system to force it on.

Because XFB is off by default, Virtual and RealXFB never got as much testing as XFB disabled. It's had huge bugs that people outright miss because no one uses it. Turning on XFB and Progressive Scan in Wind Waker causes the game to drop every frame, making it run at a crisp 15 frames per second despite being full speed. In Super Mario Galaxy, Dolphin will outright mess up the ordering of the frames if you try the same combination, resulting in one of the most disorienting gameplay experiences you can get in the seminal platformer.

Thankfully, Dolphin's focus on accuracy over hardcoded hacks has changed things for the better. Largely powered by booto, Dolphin's VideoInterface has seen a change from hardcoded parameters forcing settings that work for most games to a system that is able to check what the games want and configure things properly, just like the console would. This latest change fixes one regression that was hidden by hacks for nearly a decade; Sonic Mega Collection's constant flickering. It may seem like a lot of work to get a collection of games that are more easily emulated on other consoles working, but, in the end it is a GameCube game, and Dolphin is a GameCube emulator, so getting it working properly without needing an anti-flicker hack was a high priority.

There was one regression with this change, but it took all of six hours to track down and fix. Once again, booto broke another hack hiding another bug with his accuracy changes, this one being quite a bit easier than the last, fortunately. In fact, it's already fixed. 4.0-8506 makes it so we no longer use a region override on wads, because they contain region information unlike dols. The previous method used hacks for non-disc based games to force region mainly because Dolphin was originally a GameCube emulator, and there were two options: discs and dols (GameCube Executables). Dols have no region information, so it is smart to force a region for them, but that same functionality was enforcing the region for wads, which DO have region information!

Failing to set the region caused the wrong font file to be loaded

With the region correctly set, Contra ReBirth loads the font properly

4.0-8390 - Real Wiimote: Don't delay speaker data by degasus¶

As we said earlier, 4.0-8325 improved Wiimote audio on the -TR Wiimotes. 4.0-8327; the very next merge that was also worthy of being featured in the progress report, made that audio sound a little bit worse, especially on weaker Bluetooth adapters. This prompted an issue report that wasn't really expected to go anywhere. Considering Wiimote audio wasn't working properly still, a regression in output had little chance of being rectified. That's when hk.konpie (who continually shows up out of nowhere to help with audio problems) pointed out a potential bug in Dolphin's Wiimote audio code. degasus tried the change and it did improve things slightly, but upon looking at the code more closely, he realized there were far bigger problems throughout. While the entire Wiimote handling of Dolphin probably needs a rewrite, degasus opted to make a few tweaks and remove some unneeded code. This was enough to get Real Wiimote Audio working on -TR Wiimotes!

There are some limitations to this, unfortunately. Currently, only -TR Wiimotes have working Wiimote audio. Standard Wii Remotes behave mostly the same as before and struggle to output any kind of recognizable audio. Secondly, Wiimote audio does not like inconsistent speed. Thirdly: while we do know that the MS Bluetooth Stack, Toshiba stack and DolphinBar all see proper -TR Audio Output, users have reported that the same benefits do not extend to OS X and Linux; meaning there's still more work to be done.

Considering the entirety of Dolphin's Wiimote handling probably needs to be rewritten means that further fixes will not come until after the next release. But, now that the surface has been scratched, it's only a matter of time until all of the mysteries surrounding Wiimote audio are solved.

4.0-8476 - Catered for the case where ADPCM audio would loop before the end of the stream by skidau¶

While skidau made the actual change, this is yet another case where hk.konpie showed up to help with an audio issue that probably wouldn't have gotten fixed as quickly or at all without him. Thanks again!

Throughout the early 4.0 era, a lot of strange audio looping issues were tackled. These issues were the cause of very strange issues like videos having garbled audio, music in Skies of Arcadia Legends and Pokémon Colosseum playing incorrectly, and much, much more. Thankfully, skidau and hk.konpie took care of most of those issues and many games that didn't have working audio in HLE or LLE in Dolphin 4.0.2 now work correctly.

Blazing Angels: Squadrons of WWII wasn't about to go down without a fight. Unlike all the other issues, this one actually worked in Dolphin 4.0.2, and regressed when the other fixes were added on! This game actually loops the ADPCM audio BEFORE the end of the file, which was a case the emulator previously didn't handle because none of the other games using ADPCM audio seemed to do that.

While the other ADPCM audio titles were tested with this change and seemed to behave fine, there's always the non-miniscule possibility there are more bugs hidden in there, and that this change could cause a regression. Keep an eye out for any audio issues that occur in HLE and LLE audio; it could be our next ADCPM looping issue!

4.0-8488 - Always load system fonts from IPL dump, if available by Jhonn¶

There are a lot of subtle things that are hard for an emulator to get right. One of these is system fonts: fonts that are included with the GameCube and Wii that games can use. Dolphin can't be distributed with any content under copyright. For games that bring their own fonts it isn't an issue, but for system fonts, we have no choice but to substitute them with open fonts. Specifically, Dolphin has chosen Droid Sans for the job. But Droid Sans isn't very close to the original spacing, and while it is functional, it definitely doesn't look right.

Wii games and homebrew couldn't access the native fonts, leading to some funny bugs

Now as long as Dolphin sees the bios, it will choose the system fonts over the free fonts

Progress Report newcomer and wiki extraordinare Jhonn tackled this issue with a clever solution. If someone has dumped their GameCube's IPL, they already have the fonts! By making Dolphin able to use the fonts contained within the IPL, users now have a much simpler method to obtain and use the original fonts. Considering this limitation, it was impossible to actually load the system fonts on Wii games before now!

Last Month's Contributors...¶

Special thanks to all of the contributors that incremented Dolphin from 4.0-8258 through to 4.0-8516!