Another month rolls by and now the feature freeze is starting to take a toll on the new features. Aside from Android and D3D12 development, which have an exception from the feature freeze, most of the changes this month were either relatively small or involved Dolphin 5.0 blocker bugs. Progress on the eventual Dolphin 5.0 release is very promising, with over half of the remaining blocking issues with fixes pending! While there is still quite a bit of work to do, we hope this month's notable changes, featuring some oft requested tweaks, will tide people over until the feature freeze is over.

Notable Changes¶

4.0-8877 - [Android] Implement support for real Wiimotes with the DolphinBar by Sonicadvance1
and 4.0-8886 - [Android] Add UI support for newly-implemented DolphinBar support by sigmabeta¶

It wasn't even a year ago when we said this.

But for all its time booting games, Dolphin on Android has never had Wii Remote support. Ever since Android 4.2.1 Wii Remotes will no longer pair with Android, so Real Wiimote support is impossible.

Without the ability to pair Wii Remotes directly with Android's Bluetooth stack, via Android or for Dolphin to interact with Wiimotes directly, Wii Remote support was considered impossible. But impossible for software development usually just means you need to just be slightly more creative than the problem at hand! Having already done the work last month to use Android's USBManager service to properly request a direct connection with the Wii U GameCube Controller Adapter, Sonicadvance1 recognized that the same method could be used to bypass the uncooperative Android Bluetooth stack to access Wii Remotes via the DolphinBar. Since the DolphinBar does all the Bluetooth communication itself and it doesn't send the data through the Bluetooth stack at all, it works.

Now users can finally play Skyward Sword the way it was meant to be. On a 5 inch screen at roughly 2 frames per second with a DolphinBar taped to the phone. That's right, Wii MotionPlus titles are finally playable on Android if you so dare. Ok but seriously, this is great for the NVIDIA SHIELD Android TV.

4.0-8928 - [GameINI] Flag some Wii titles without widescreen support by Jhonn
and 4.0-8945 - Make all Virtual console games 4:3 (and cleanup GameINIs) by phire¶

Unlike the GameCube, widescreen support is a standard feature on the Wii. The console lets you switch to widescreen and Wii titles are supposed to render in widescreen, and it just works. But in a few rare cases of Wii games, and all Virtual Console games, their way to handle it is simply stretching the viewport to fit a widescreen aspect ratio without adjusting any other aspect of the game. That leads to everything looking all stretched.

Oh no, more oval shields?! What can we say? It's a tradition.

And here is how Super Smash Bros.' shields should look, perfectly round.

This is one of those issues where nothing really had to be done with Dolphin. The actual Wii has the same exact problem, especially with Virtual Console games. Users would have to go into their television's settings and change the aspect ratio to 4:3 before playing Virtual Console games to get them to show up in a more proper 4:3 ratio. Same with any other Wii games that don't support widescreen.

phire decided this wasn't good enough. While using the Wii U's Virtual Wii, he realized that Nintendo themselves came up with an interesting work-around. Since Widescreen support is consistent across the Wii's emulated platforms, the Wii U can tell which games supported widescreen or not by looking at the System code of a software's GameID. phire realized Dolphin could do the same thing, and made some tweaks to the GameINI system to apply settings across a platform. With this all set up, users no longer have to mess with aspect ratio settings when playing VC titles, something even the Wii cannot do!

4.0-8933 - D3D12 Backend by hdcmeta¶

Users have long been asking "when will Dolphin take advantage of Direct3D 12 and Vulkan." The core Dolphin developers tried to temper expectations; they expected little or no improvement at all. But users couldn't help but speculate (usually on flawed logic) all the ways that Dolphin could be improved by Vulkan, Mantle (before it was rolled into Vulkan) and D3D12. Would things get faster? Would they be about the same? How long would making a backend take?

It turns out, when someone is absolutely dedicated to developing and finishing a backend, it really doesn't take quite that long. Direct3D 12 is a pretty exciting platform for performance and features, which drew in a new contributor. In this case, hdcmeta blew everyone away with a sneak peek into his Direct3D 12 prototype back in December. In only three months with only a little guidance, a complete newcomer to the project wrote a new backend, to current code quality standards, and managed to pass code review. On top of that, this new backend works very well considering that it's going up against backends with years of work and multiple contributors. While no one is exactly sure what the Direct3D 12 backend is doing to be faster (the devs' initial expectations were that it shouldn't be much faster), it definitely has a sizeable performance increase in GPU intensive titles.

In GPU Intensive games, Direct3D 12 is faster even against NVIDIA's strong OpenGL drivers

AMD Graphics Cards rely on strong D3D support, and D3D12 brings them even with their NVIDIA counterparts

The D3D12 backend doesn't even use any of the new hardware features of D3D12, only API features. What it does better is mostly in the backend's design, taking advantage of ideas not used in the other backends. It's very possible that some of the bigger performance gains made in the D3D12 backend can be backported to the D3D11 and OpenGL backends opening up the performance benefits for everyone. Even if that doesn't end up happening, there's absolutely nothing we know of standing in the way of Vulkan getting the same performance as the Direct3D 12 backend, assuming driver parity.

The D3D12 backend is still experimental. Currently, it lacks bounding box support (Super Paper Mario, Paper Mario: The Thousand Year Door, Mickey's Magical Mirror and a few others), External Frame Buffer support (GameCube Main Menu, many games), and Performance Queries (Super Mario Sunshine goo). Games that require these features will not work correctly. On top of that, as with anything new, there could be various bugs that the other backends do not suffer from. While users are encouraged to try out the new backend, please understand if there are problems for the time being while it matures. Also note that only Windows 10 currently supports D3D12, and only PCs running Windows 10 will be able to use the new backend.

If you're wondering why there wasn't a feature article on the D3D12 backend: one was actually written up but unreleased. There are too many unknowns involving the D3D12 backend and why it's faster for us to talk about it in-depth for right now. When users tracked down the change themselves and spread the word, the need for an immediate article on the situation dropped and what was left of that article was molded into this progress report entry. The Dolphin Blog is planning on running a Vulkan/D3D12 technical article about the potential improvements they bring to emulation, particularly for Dolphin.

4.0-8969 - [Netplay] Disable Wiimotes by Helios747¶

Poor Wiimote Netplay. Two dedicated developers worked very hard to bring it into the world, but it never got the attention it needed to make it through a feature freeze. It was delayed for the 4.0 feature freeze, and has now been removed for the 5.0 feature freeze.

It showed a great deal of promise once upon a time. Netplay was making excellent strides during this period, and everyone was excited for the new feature! Giddy users even recorded videos when it was first merged in 4.0-17.

The problem is that Wiimotes on netplay really didn't work well, and required so much setup and tweaking for just one session that no one was really sure if they were working or broken. Worse yet, when going back through to test it recently, absolutely no one could get Wiimote Netplay working at all. Even after going through the code and fixing some very obvious bugs, Wiimote Netplay appears to be fundamentally broken. That's why, with heavy hearts, we're disabling Wiimote Netplay indefinitely. While the plan is to return to this feature sometime after 5.0, there's no telling if it needs to be completely gutted and rewritten, or if there are simply a few more minor bugs hidden that just need to be found. Wii games that support GameCube controllers are unaffected by this change, except for the fact that you do not have the option to use Wiimotes now.

It is GameCube Controllers only on netplay, once again.

Spinning in Circles¶

• 4.0-8919 - [DVD] Signedness fix in realistic timing path by mmastrac¶

• 4.0-9019 - [DVD] Ignore buffer when seeking backwards by mmastrac¶

About two years ago, 4.0-1592 made the timing of the disc drive more accurate, starting us along a path of emulating disc timing. But somewhere along the way, Arc Rise Fantasia began to crash 100% of the time during one of the cutscenes when using the realistic DVD timing. At the behest of one of our testers, mmastrac looked through the code and noticed that an integer could underflow when seeking backwards on a disc. Accidentally introducing underflow in a piece of code is an easy mistake to make and it changes the results significantly, so mmastrac did the reasonable thing and tried to fix the underflow. With a confirmation that it helped Arc Rise Fantasia from our tester, it was merged into master in 4.0-8919.

But then, issue reports rolled in of even more games breaking! Instead of reverting, mmastrac did a thorough debugging of the code, and came to a surprising discovery: the underflow was accidentally making the disc read timings more accurate! While it seemed like the original code only would slow down reads far forward from the previously read location, it was also slowing down reads going backwards. By removing the underflow, these backwards reads became too fast and several games broke as a result. The problem was fixed in 4.0-9019 by rewriting the calculation in a way that doesn't underflow but still implements delays for backwards reads, fixing the problem while keeping the code understandable.

Curiously, there is one tiny change. Arc Rise Fantasia previously crashed 100% of the time during one of the cutscenes when using the realistic DVD timing, but now it only happens occasionally. More research will be needed to figure out how to best simulate the disc reading speeds. For anyone worried that Arc Rise Fantasia will randomly crash on you, don't! Use the fast disc speed timing (Speed up Disc Transfer Rate) to avoid whatever edge cases are being hit in the realistic timing path.

4.0-9045 - [D3D12] Stability Fixes by stenzek¶

While D3D12 may have been a very successful launch for performance seekers, those just looking to play games without crashes probably had a bit rougher of a time. A lot of things could cause crashes in D3D12. Taking a pictograph in Wind Waker, loading a savestate, looking at the emulator from a non-standard position, playing a game, not playing a game, etc. The good news is that stenzek went through and made a ton of fixes to help quell these issues!

• EFB Peeks are faster; no longer a 9 second delay when taking pictographs in Wind Waker. Also doesn't crash anymore.
• Touching the texture slider, changing Internal Resolution, opening the graphics menu and other tasks no longer cause textures to disappear.
• Pausing the emulator no longer crashes.
• Loading savestates doesn't cause random crashes any longer.
• Xenoblade Chronicles shouldn't crash whenever it feels like, at least any more commonly than D3D11.
• MSAA should no longer break Metroid Prime 2's scan visor.
• More miscellaneous fixes.

These fixes combined should make a lot of the early issues that users were running into with D3D12 simply disappear.

Last Month's Contributors...¶

Special thanks to all of the contributors that incremented Dolphin from 4.0-8865 through to 4.0-9050!