A project cannot survive for nearly fourteen years without making some difficult decisions. Sometimes you're right, sometimes you're wrong, but, to be successful you have to learn from each and every one. One of the most difficult decisions made for Dolphin was the deprecation and removal of D3D9 despite it being the fastest backend at the time. The promise was that we would take a step back then, and make huge gains in accuracy thanks to being able to use integers throughout VideoCommon.

There was a lot of growing pains, a lot of driver issues, and a lot of unhappy users, but it set the tone for what would become the direction of Dolphin heading up to the version 5.0 release. One of Dolphin 5.0's headline features was a brand new D3D12 backend, but as of 5.0-3774, we have decided to remove it. What we learned from the D3D9 backend helped us make that decision. Like D3D9, D3D12 had some core flaws we let slide under promises that it would continue to be maintained and fixed up. When that didn't happen, it was decided we did not want another deprecated backend hanging around, blocking features and enhancements that require work within each backend.

Let's not make any mistakes, the D3D12 backend was a tremendous gain for Dolphin, and what we were able to learn helped us know what to do when designing the Vulkan backend. Unlike the D3D12 backend, the Vulkan backend is actively maintained and does not have the design flaws that made D3D12 harder to work with. Removing D3D12 support also makes it easier for people to tinker with and compile Dolphin on Windows, along with the added bonus of reduced compile times.

Going forward, we're going to continue to optimize the existing graphics backends. In our testing, the Vulkan backend was as fast as, or nearly as fast as the D3D12 backend in every benchmark. While different drivers and graphics cards will not all perform identically, we're confident that moving forward the Vulkan backend will be able to handle the burden of users seeking the benefits of the newer graphics APIs.

...and that's probably not the biggest removal this month. Dolphin's longstanding JITIL (Just in Time Intermediate Layer) Recompiler was finally decommissioned and removed. It's one of those great ideas that just didn't pan out. It never could match the performance of compatibility of the JIT and it was unmaintained in recent years. To even consider JITIL a part of the future, it would have needed to be rewritten to support both Full MMU support and PIE compliance.

We know that some of you reading this are going to be upset or disappointed by these decisions. Hopefully you stick with us and the future gains we make by handling these potential problems now more than pays for the temporary inconvenience. With that out of the way, we have a lot of great additions to the emulator in this month's Dolphin Regress Progress Report!

Notable Changes¶

5.0-3598 - AArch64 JIT - Fix paired_single reciprocal instruction by flacs¶

Sometimes an egregious bug sneaks in that is so bad, it's actually hard to see. In the case of ps_res (Paired Single Reciprocal) the instruction got implemented entirely wrong in the AArch64 JIT, and no one noticed. This made it so any game that used this instruction was pretty much broken, including the Resident Evil series.

Forum user Servlet did the hard work of narrowing down the broken instruction, and once they did, the AArch64 developers did a collective facepalm and hurried through a hotfix.

Let's be clear - the approximation for this instruction is not bit accurate to what the GameCube/Wii would do but is a lot better than the broken estimation. The incorrect implementation was calculating ps_res as 1/sqrt(x) instead of 1/x. Now we do 1/x, but, without really worrying about the various edgecases where the PPC version of the instruction will return slightly different results.

flacs: uh...
flacs: FRSQRTE?
HdkR: lol
flacs: reciprocal square root?
HdkR: yea
HdkR: +estimate
flacs: ps_res is just reciprocal...
HdkR: yep
HdkR: Gekko is silly
flacs: heh: {26, &JitArm64::FallBackToInterpreter}, // ps_rsqrte
HdkR: :3
flacs: wow, ps_res has been wrong since january 2015
flacs: i.e. always

5.0-3723 - Fix GBA <-> GCN issues on DSP-HLE for Zelda Microcode Games by ligfx¶

This change fixes several issues with GBA <-> GCN that were present only when using HLE audio.

• Only one GBA could connect at a time
• Most audio would not play or intermittently disappear

This change improves HLE to the point where behavior is the same as DSP-LLE in GBA <-> GCN games. The most notable Zelda microcode game that suffered from issues on this issue was Four Swords Adventures. Since the New-Zelda-HLE rewrite, connecting multiple (emulated) Game Boy Advances and audio issues persisted when using the feature on HLE audio. This is no more!

DSP-HLE makes this setup far less demanding. Now you just need to assemble your friends! That's easy, right?

These bugs should still have persisted on AX-HLE, as this change only fixed Zelda microcode games, but when doing some testing on Final Fantasy: Crystal Chronicles, that no longer appears to be true.

Despite our best attempts to bisect, we have no idea who or what change actually fixed those games. It really is big news because this means that all of the GBA <-> GCN titles should work on DSP-HLE now without users being required to get official DSP dumps off of their GameCube or Wii to use DSP-LLE. The only titles unconfirmed to work are those that require an actual game in the GBA, such as Pokemon Colosseum and friends. Considering those can be problematic even on DSP-LLE, we're not too hopeful that they'll work.

We have no idea why HLE is working for GBA connectivity in this game, but we'll take it!

Long-term, the current GBA <-> GCN implementation will need some more serious work, but these fixes make it so that The Legend of Zelda: Four Swords Adventures should be perfectly playable with up to four players on a single computer.

5.0-3766 - Android Touch Control Improvements by SeannyM¶

If you're playing Dolphin on your phone, not only do you have to deal with constant performance limitations, you probably are also using Dolphin's touchscreen controls. While touchscreen controls are not the best a replacement for a controller, that doesn't mean they can't be improved. Veteran Dolphin Android contributor SeannyM returns to add some basic touchscreen improvements. You can now slide your fingers off of buttons to let go of them and onto them to press them, buttons now give feedback and visually show when they're pressed, and joysticks will now follow your thumb! Among these are some smaller improvements, so if you're constantly using Dolphin Android's touchscreen controls, this may be the most important change of the month! Enjoy!

Now it is much easier to tell what you are pressing.

5.0-3825 - Add an option to show the Active Game in the Title Bar by leoetlino¶

Have you ever been playing a game for a while and started wondering, "Oh no! I forgot what game I was playing!" and you have a gamelist with thousands of games and are afraid that you'll never find that game to play again? We've all been there, and have we got the feature for you!

If you ever forget what game you're playing, you can now just look at the title bar!!! Dolphin can now tell you what game you're playing and its GameID to make easier to find the next time you want to boot it!

With our infomercial finished, this change actually shines the most when you're using the Wii Menu. Bouncing around channels, Dolphin can now keep track of what titles have booted and will let you know in the title bar. In order to make sure accurate titles are provided, Dolphin now includes a titles database from GameTDB by default. Users who weren't using a Title database before will now see more accurate title names in the gamelist. This also makes finding screenshots and texture dumps easier to find as the GameID is readily in the titlebar.

Now you'll never forget which WiiWare title you are playing.

5.0-3860 - Add minimum delay for processing command list in HLE audio by hthh and ligfx¶

This is a bit of a tricky change that took a lot of thinking on how to fix. Let's go into the initial problem, and then we'll dig into why this fixes it.

Fixing Star Wars: The Clone Wars, was an arduous process that took several years to do efficiently. When the pull request for Dynamic BATs was first opened, Star Wars: The Clone Wars worked fine on HLE audio + JIT, which allowed for some pretty nice performance. But, between the initial opening of the Pull Request and its eventual merge, a huge set of core timing fixes were merged to Dolphin. These timing fixes made it so Dolphin could no longer boot The Clone Wars in HLE audio.

One of the things that the Core Timing fixes in Dolphin fixed was that interrupts were being sent way late (20,000 cycles late in some cases!) This was causing a ton of games to malfunction in Dolphin. Because HLE audio did not emulate any Command List timings, it was able to boot a bunch of games that would hang on LLE audio. After the fixes, both LLE and HLE audio could boot pretty much anything!

The game would freeze on the initial loading with the last log being about MaxStreak: 0.

...Until Star Wars: The Clone Wars turned up. We didn't actually know this was an audio timing issue until ligfx, sepalani and others did some research on this. Delaying the response by 814 cycles or more would fix The Clone Wars, but putting an arbitrary delay like that was too hacky and the idea was shelved for a while until a second discovery was made.

At minimum, it took 2500 cycles for the DSP to process an empty command list, and thus the delay would never be less than 2500 cycles. By setting the minimum to 2500 cycles, we were able to fix Star Wars: The Clone Wars, and several other stragglers that refused to boot with a combination of the JIT and HLE audio.

This makes Star Wars: The Clone Wars full-speed on high-end hardware, and especially makes running the multiplayer mode much, much more plausible on current machines. This also fixes various HLE only audio hangs in other titles.

5.0-3902 - Add 'Load GameCube BIOS' Option by sepalani¶

This is a feature we at the blog have wanted for a long time, but developers disagreed. After all, all you had to do was uncheck GameCube BIOS, load a GameCube game and hold A to get to the BIOS, right? Still, sometimes we just want to play around in the IPL without all of those steps.

Thanks to sepalani we finally can. In a cozy place next to loading the Wii System Menu, you can now find load GameCube BIOS!

5.0-3937 - Add Cubeb Audio Backend by ligfx¶

While we were busy removing graphics and CPU backends, on the audio side of things we have a new cross platform Cubeb audio backend. The main goal of this new backend is for it to replace the other backends. Unlike with video backends, none of the actual emulation happens in the audio backend, so all there won't be any surprise emulation issues. The main deal about Cubeb is that it's multi-platform and can provide the lowest latency on all of our supported operating systems. After doing some testing on Windows, we found this to be true!

Note - Latency was tested on what a general users settings would be rather than being optimized for latency. By setting Dolphin's AudioVariance setting lower, you could sacrifice performance to get dramatically lower latency than recorded here.

5.0-3951 - WXWidgets - Gamelist Loading Performance Improvements by flacs¶

If you have a lot of games (let's say... around over a thousand,) in the gamelist, it can take quite a while to load. On average, without a gamelist cache and a huge gamelist, Dolphin can take over three minutes to generate the gamelist. Why? Because it has to make sure the games are valid GameCube or Wii titles, load the GameID, banners, and other decorations among other things. One of the frustrating things about having a huge gamelist is that after it was done doing all this, WXWidgets would freeze at 100% loaded for another 20 to 30 seconds. This change fixes that lengthy delay after the progress bar is filled up, shortening the initial gamelist load dramatically on gigantic gamelists.

On a cached gamelist of over 1000 titles, it still cuts off five to ten seconds, which could be even more sizable since that's over a quarter of the time it takes to load the entire gamelist. If you only have a couple of games, you probably won't notice the difference, but, the seconds do add up!

Just look at how small that scroll bar is!

Qt-ie Patootie¶

For as long as Dolphin has existed, it has used WxWidgets for its GUI. In 2003, WX was the best multiplatform GUI solution at the time, but it isn't as cute these days. In order to support new features, more and more has been bolted on top of WXWidgets aging base, leading to a toolkit that is filled with old concepts, antiquated coding requirements, and strange old assumptions. For example, here we are in 2017, and WxWidget's current latest release still supports Windows 95. Just think of the knots they must go through to support 20 years of operating systems!

But there is another GUI toolkit, of similar age and widespread compatibility - Qt. Where WX has stood still, Qt has had no issue ripping out the floorboards when necessary, creating a much leaner, easier to use API. For example, the recent Qt pull request enabling HiDPI switched it on, had a few lines to tell how Qt we handled the files, and that was it. But in WX, sizes and scaling have to be set for every single element individually. The WX HiDPI pull request was truly monstrous in scale!

Qt HiDPI Pull Request: +93 -37
WX HiDPI Pull Request: +4,419 -3,167

When even minor GUI changes take an immense amount of effort, most developers avoid touching the GUI as much as they can, usually resulting in them at most adding a button necessary for their work then running for the hills. The only reason our UI isn't a disaster is due to the determination of a few stubborn individuals who were so sick of Dolphin's UI problems that they were willing to throw themselves into the WX trashfire. But even with their amazing work, there are so many things that we'd like to do that are just impractical or impossible under WX. Not to mention that WxWidgets likes to randomly freeze. If you've had your game running fine but Dolphin's UI was frozen, WX was to blame.

With all of these problems in WX, why didn't Dolphin switch to Qt years ago? It's certainly not for lack of trying! In the previous two attempts, the coders have tried to handle the transition while making Qt-er design changes at the same time. While Qt is an objectively better GUI backend at this point, design is a subjective beast, and opinions clashed. Faced with a considerable UI transition while dealing with copious bikeshedding, the people behind the move burned out, and WXWidgets survived again and again.

Now we're trying a new way of handling the move, one that isn't going to be as dramatic. This time around, we are just going to replicate the WxWidgets UI in Qt, and leaving Qt design changes for later. This clear end-goal has rejuvenated the Qt move and we're now charging ahead at an unprecedented pace. We're hopeful that a few Progress Reports from now, we'll be announcing the completed Qt UI! Once we are at full Qt-ness, UI work will be phenomenally easier, and we'll finally have a chance to tackle the UI and it's quirks with new determination.

Stay tuned!

Oh by the way - Qt is pronouced as "cute", not "que-tee". If you read the above as que-tee, you need to go back and read it all again.

Last Month's Contributors...¶

Special thanks to all of the contributors that incremented Dolphin from 5.0-3572 through to 5.0-3975!