The biggest news of the month regarding Wii emulation has nothing to do with Dolphin. The vehicle for many of our hardware tests and much, much more, The Homebrew Channel, has gone open source. In its heyday, it was stuffed to the brim with anti-reverse engineering code to prevent nefarious entities from selling the free program. Unfortunately, some of those tricks were also designed to prevent Dolphin from running it. This isn't due to a dislike of Dolphin; in recent years, we've even been tipped off to what we'd need to do to get past the anti-Dolphin checks.
On the 22nd of November, Marcan of Hackmii.com released the Homebrew Channel as an open source application, removed the anti-emulation hooks, and fixed a few bugs in Dolphin so that it could run properly! Nearly a decade after its inception, the Homebrew Channel is finally emulated! Admittedly, it has very little use for Dolphin, but it is extremely cool to have. Some packed Wii homebrew elfs (such as Not64, openTTD) will only run in Dolphin from the homebrew channel currently. This is due to Dolphin being unable to detect them as Wii homebrew.
On the topic of actual features being added to Dolphin, we've been working on some pretty fun features that just aren't quite here yet. But, still, here's a teaser of what's almost here!
Much like in Wind Waker, this tester was on his second quest and thus unlocked the Legendary Pajamas.
But, we all know people don't care about games working, they care about games crashing! Which is why we have even more Twilight Princess shenanigans. This time, PPLToast sends us footage of Dolphin running the game in debug mode and tests out some known crashes.
One more thing of importance: If you are running Linux and have a Sandy Bridge, Ivy Bridge, Haswell, or Broadwell CPU, you may be having some weird performance issues with Dolphin. There's a bug in glibc absolutely decimating JIT performance. The bug has been fixed, but, it may be a while until it's distributed around. This loss of performance is most noticed during FMVs, where even the intro to Super Smash Bros. Melee will drop to less than 30 FPS on an Ivy Bridge CPU, but could potentially affect other games in strange ways. Users on Windows and macOS are not affected by this issue and do not need to worry.
With that out of the way, let's finally get to this month's notable changes!
Notable Changes¶
5.0-1241 - Vulkan Cleanup and XFB Support by stenzek¶
While it was originally planned to wait for Hybrid XFB to wire up Vulkan to the eXternal FrameBuffer, it turns out that feature is taking quite a bit longer than anticipated. Thus, in his latest block of cleanups, stenzek decided to plug Vulkan into the existing XFB code. It was a relatively simple task, and more or less makes Vulkan feature complete. This means that Vulkan can properly run games that require Virtual or Real XFB, such as Star Wars Rogue Squadron II: Rogue Leader.
In terms of overall quality, the Vulkan backend is shaping up nicely. Unlike D3D12, which is still plagued by a lot of instabilities, Vulkan seems to run well on any of the cards that support it. That said, it's not going to revolutionize Dolphin; its merely a bit faster than the standard D3D11 and OpenGL backends outside of a few rare cases, like The Legend of Zelda: Twilight Princess. While OpenGL remains the most accurate backend, Vulkan brings most of the performance of D3D12 without the instabilities in its current form.
5.0-1265 - Renderer: Threaded frame dumping by degasus¶
In order to make the highest quality video dumps from within Dolphin, users will want to use the built-in framedump features. Regardless of actual performance, users can record full-speed videos at any resolution to get jawdropping footage from their favorite games!
But, one of the problems with capturing footage with Dolphin's framedump feature is that it was very slow. Even at lower resolutions, you'd fall into single digit framerates during busy scenes while trying to record. In order to mitigate this, degasus has revamped framedumping to be a lot faster. On a testing machine (Core i5-3570K,) up to 2x Internal Resolution can be recorded without performance penalties! At 3x IR (1080p) the internal framedumping can still run at around half speed. Considering it would drop to single digit framerates at even 2x IR before, this is a huge quality of life upgrade.
Hopefully more users will be able to record high quality footage of their favorite titles without having their patience tested with terrible performance.
5.0-1325 - DolphinWX: Fix toolbar creation on macOS by hthh¶
macOS tends to get the short end of the stick in development. It has less users, thus less error reports, and fewer developers than Windows and Linux, meaning that when an error report is made it takes longer to fix. A very boring cleanup change, 5.0-1164, turned out to be quite a difference maker for macOS users!
Whoops.
Admittedly this was not the end of the world, as the toolbar is technically a series of shortcuts to the options in the primary UI: the traditional file menu. Thankfully, this one was actually caught and fixed fast compared to most Mac centric bugs.
All better!
5.0-1354 - Android: Reimplement input binding by SeannyM¶
In June 2015, the new Android 5.0 UI became the only Android phone UI with the removal of the original Android UI SonicAdvance1 unenthusiastically slapped together a couple years before. Considering how Android devices are barely fast enough to run games now, imagine being a developer several years ago working on the Android builds. Playability and useability wouldn't be your first concerns.
But, there are people who use Dolphin's Android builds, and some very high end devices can handle Dolphin in some situations. Now it's a continuing challenge to make sure everything is put together so that it can provide as high of a quality experience as possible considering the differences and limitations. While performance is going to be a concern for the foreseeable future, users shouldn't be forced to bounce around builds just to configure their gamepads!
When "just use the old version" changes from "use last week's" to "use last year's", something has gone wrong.
Here we are, a year and a half later, and SeannyM has taken up the task of restoring this important feature! SeannyM put in a great deal of work restoring the button configuration UI, bringing it up to modern Android spec and giving it a good cleaning. Now Android users can configure their gamepads without using old versions and other silly workarounds.
Functionality!
Note that Android TV just has a different game list, and uses the phone UI for the settings and configuration. As such, this fixes button configuration on Android TV as well.
In the future we hope to keep closer tabs on the Android GUI. After all, it doesn't matter how good the emulator is if no one can use it.
5.0-1364 - Vulkan: Improved Shader Cache by stenzek¶
We all hate shader generation stutters, so when something goes badly in regard to our current defenses against shader generation stutter, steps have to be taken to fix it.
With Vulkan, especially on the AMD graphics drivers, Dolphin's shader cache was not working as expected. Even when the shaders were already cached, the games would still stutter on those same shaders. This is because nothing was being written to the pipeline cache! The shader cache was actually having no effect on it at all!
A longstanding idea to expand the shader cache has been to store the UIDs instead. Think of these as the the instructions we get from the game to generate the shaders. Instead of generating the resulting shaders, we cache the instructions and then generate the shaders based upon them. This allows a lot more freedom with shaders; we don't have to rely on drivers supporting a shader cache even to avoid stuttering! If macOS actually had Vulkan support, it'd be the first time that macOS users would actually be able to use a shader cache! But, alas...
On the bright side, Shader UID caching has a lot a bonuses. UIDs are a lot more flexible in terms of usage. They aren't tied to a single graphics card or their drivers, meaning cached UIDs can be used on any computer. While Dolphin will currently invalidate UIDs on new builds, this is not necessary and with the proper infrastructure they will only be invalidated on actual shader generation changes. This would mean shaders could be built for hundreds, if not thousands of builds!
The downside? The shaders have to be generated from the UID on game boot, which can take several seconds. This means you will be waiting a bit longer for your games to boot. This can be reduced with multi-threading; but, again this feature is very new and a lot of the bells and whistles haven't been finished yet.
If people end up liking this a lot more than our current way of storing generated shaders, it can very easily be hooked up to OpenGL and D3D11/12 as well! In fact, if all backends used this method of shader generation, playing a game on one backend would generate UIDs that would work on every other backend. So, if you were playing a game on D3D, you could switch to OpenGL and still have your cached shaders!
Is this something everyone wants? Or do you prefer not having a startup cost to shader generation?
5.0-1374 - VideoBackends: Internal Resolution Frame Dumping by stenzek¶
Once again we return to the topic of screenshots and framedumping. This is something we've wanted for a long time, as taking high quality screenshots can be a pain in the butt!
Dolphin has a lot of dumb design decisions within it. This is a fact we cannot deny, and by far one of the most annoying ones for every single Progress Report was that the size of the window was what determined the resolution of video dumps and screenshots. Due to the desktop window manager in Windows, this meant that on a single 1080p monitor, you were limited to dumping images at 1920x1080; it would refuse to let the window get any bigger. Of course you could trick it if you had multiple monitors by exploiting the fact that Windows wants all monitors to fit within a virtual rectangle, and you could use the space outside of your physical monitors in this virtual space. But it was quite the hassle, and only viable if you had an absurd number of displays.
Now where did that mouse cursor go...
This rewrite eschews that ancient behavior for something a lot more logical. Screenshot and video dump resolutions are now based on the internal resolution that you are running the game at. This actually allows for some fairly jaw dropping screenshots without any fiddling with the desktop resolution!
5.0-1379 - Redo every input configuration dialog by aldelaro5¶
Dolphin's wxWidgets GUI has come a long way. While it's been rather maligned by users and developers alike, it remains the most complete UI for Dolphin. One area where it really felt subpar was input configuration, though. This became especially apparent when adding the new hotkey system that could put hotkeys onto controllers alongside the keyboard/mouse. Instead of it replacing the old system it was added alongside it. What followed was regressions, complaints, confusion and much more while the new system was picked apart. The resulting hotkey configuration screen... well...
Oh my...
aldelaro5 took on the task of managing of all of this bloat and organizing it all cleanly. This rewrite attempts to make every window regarding input easier to use by grouping particular hotkeys and inputs into smaller, more logical groups.
MUCH better.
Last Month's Contributors...¶
Special thanks to all of the contributors that incremented Dolphin from 5.0-1211 through to 5.0-1413!