The last few months have been absolutely hectic, with several long-awaited features hitting the emulator all at once. In order to keep users up to date with these major changes, the blog staff has been busy with feature article after feature article. It has been exciting, but also pretty exhausting! With us burning the candle at both ends to keep up with development, the Progress Reports have fallen a bit behind.

So here were are, bleary eyed and with three months worth of changes to go through. So without further delay, let's go through February, March, and April's Notable Changes! Please enjoy while we go collapse in the corner.

The Article Collection¶

The Great VideoCommon Unification and D3D12 Backend¶

The Great VideoCommon rewrite was expected to bring a ton of benefits and dig up some bugs, but for the most part the transition has been incredibly smooth. This change unites most of the graphics emulation logic in a shared part of Dolphin (VideoCommon), making backend maintenance simpler, easier, and cleaner. The added simplification not only helped fix dozens of backend specific bugs, but also made it much easier to add a new backend to the mix: D3D12.

Each of the backends are roughly half the size they were before the rewrite and going forward, it should be much easier to keep feature parity between all the backends except when the API's limitations are the main problem. If you want more information on the performance implications, added features, and more, please check out our feature article on The Great VideoCommon Unification

The Netplay Server Browser¶

The Netplay Server Browser has had a smooth launch as part of the development builds for making organizing netplay games simple and easy. By design, this feature works better in builds that are used by more people as netplay can only be done between users on the same build of Dolphin. So while the launch was smooth in the development builds, we're expecting to see it get a lot busier on the monthly builds where there are a greater density of users. Linux users need not fear, as the monthly builds are just a normal revision, and we plan on making them more easily identifiable in the future to assist with the usage of netplay features.

For more information on the netplay server browser, please check out our feature article on the subject.

Emulated MotionPlus¶

Emulated Wii MotionPlus didn't seem like it was ever going to happen for many years, but it's finally here. The article has already said all the details and trials that developers went through to get everything done and merged, so instead let's use this space to talk about some of the issues we've seen users running into with MotionPlus emulation and MotionPlus games.

The Pointer in Skyward Sword Doesn't Reach the Edge of the Screen¶

As we tried to hint at in the feature article, but The Legend of Zelda: Skyward Sword doesn't actually use Infrared for the pointer. However, you can control gyro and accelerometer data through Dolphin's pointer thanks to a physics engine that takes into account a Virtual Wii Remote behind the scenes. Even on console, compared to most games you have to move the Wii Remote a lot more than most games when controlling the pointer in The Legend of Zelda: Skyward Sword.

The problem users are running into is that the pointer doesn't reach the edge of the screen with normal settings... and that's expected. For Skyward Sword you'll need to greatly increase infrared range if you want to control the menus with the infrared setting in Dolphin.

Skyward Sword tends to stab after swings¶

This one is an actual bug that has actually plagued the MotionPlus rewrite from the beginning. This was the last thing being worked on before merge, and while it's a lot better than it was in testing, it still tends to have problems after certain motions. This behavior is actually achievable on console... though, it requires hitting something with a Wii remote to create a ton of acceleration data over a very small distance. And that's what the problem is - the physics behind MotionPlus are applying tremendous amounts of acceleration over essentially no distance in some scenarios resulting in Skyward Sword reading a stab.

We're currently investigating the issue and the early prognosis is that it shouldn't be too painful to fix.

I need settings!¶

Configuring Wii Remotes normally can be difficult, and with MotionPlus games requiring more exact movements, users have been struggling to find the right combination for games. This is actually a fairly difficult task, especially for players who couldn't/haven't played the games before with their native motion controls. Our best suggestion is to be patient and let the community figure out the best ways to configure various controllers, as there is a lot more people with a wider variety of controllers and experience playing the games than the people working on developing them.

Our general tip is that MotionPlus titles are mostly looking for unique motions - think about the motions needed to be done in their most simple form and that'll work most of the time.

Notable Changes¶

5.0-9575 - Implement Auto-Updater for macOS by spycrab0¶

Keeping up with the latest monthly and development builds has gotten a lot easier on macOS thanks to spycrab0 and the macOS auto-update infrastructure. Users on macOS can now use the same auto-update plans as our Windows users to keep up with the latest monthly or development builds without having to manually update!

5.0-9869 and 5.0-9795 - Input Backend Upgrades by Billiard and spycrab0¶

One of the more archaic behaviors of Dolphin was that outside of native controller support, users on Windows had to have their controllers plugged in before they started the emulator. Any controllers plugged in during execution would be ignored until the emulator was restarted. While users on other platforms had hotplugging support, DirectInput and Xinput on Windows lagged behind. In order to bring feature parity to the various input backends, Billiard implemented hotplugging support in both Windows input backends.

macOS on the other hand was struggling to get all buttons working on certain models of Xbox controllers in Dolphin. On macOS, Dolphin uses an IOKit input backend native to that operating system. spycrab0 dug into the Dolphin's IOKit backend and refactored it, taking out several bugs in the process and finally allowing all buttons and triggers on Xbox One Wireless controllers to be detected properly. Beyond that, we expect this refactoring to erase similar issues across many differnet controllers.

5.0-9950 - Add Game Verification Tab by JosJuice¶

Dolphin has long had the ability to calculate the MD5 checksum of a disc, which could then be compared to against a database of known good dumps of discs. This is how users could verify if their personal collection was dumped properly, assuming a disc had a known clean dump. With GameCube games having lossless compression directly in Dolphin, MD5 checksums work fairly well at identifying problematic dumps. However Wii Discs aren't lossless when scrubbed/compressed in currently supported formats.

In order to help users identify problems across all titles, JosJuice has added a new verification tab to the game properties page. In this page, you can not only calculate the MD5 checksum like before, but Dolphin will attempt to examine the disc for problems and even give an explanation for what various problems may cause.

As an added bonus, this also works for Wiiware titles digital titles. Considering each Wiiware title has a unique signature from the console it was dumped on, MD5 checking isn't typically going to help with finding good dumps. This new verification tab can identify problems with Wiiware and other digital titles.

Note: Many WAD extracters/dumpers for the Wii will alter a WAD file so it can work on any console. Dolphin will report this as a low level issue not expected to impact playability. For more information on how to dump WADs with the signature intact, you can check Dolphin's information on dumping games on the wiki.

5.0-9900 - Netplay Golf Mode by Techjar¶

Netplay has been a wonderful tool that allows us to play some of our favorite local multiplayer games online. From Super Smash Bros. Melee to Mario Party 7, tons of games translate well into netplay. Unfortunately certain games' mechanics make it more difficult to translate into netplay. While every game is affected by latency, it's incredibly hard to time the hitbar in games like Mario Golf: Toadstool Tour with any kind of netplay latency. As a fan of the game, Techjar decided to do something about it!

Golf Mode allows Dolphin to give one player on netplay at a time zero latency, making it possible to play games like Mario Golf: Toadstool Tour on netplay without compromising the experience. And even though the name of the feature is Golf Mode, other games can work, too! For instance, Super Mario Bros. 3 (VC) and the other older, hotseat Mario Bros. games are great choices as well. You can switch players both through hotkeys or through imgui controls integrated into the render window.

One limitation of Golf Mode is that it's built off of Host Input Authority mode, which means that all other players are subject to some extra latency in order to give one player at a time no latency. Keep that in mind when figuring out if Golf Mode is the right choice for your netplay experience.

Note: The initial implementation of Golf Mode does not yet work for Wii Remotes.

5.0-10065 - Netplay - Mii Sync by Techjar¶

While Wii Remotes don't work on Golf Mode, that shouldn't stop you from trying out emulated MotionPlus on the greens with your favorite Miis in Wii Sports Resort. Just remember that the host computer's Miis are the ones used for a netplay session when save synchronization is on.

5.0-9971 - Fix Wii Save Importing by JosJuice¶

For almost a year, a small issue has crept into Dolphin's Wii Save Import feature causing extra garbage data to be added at the end of save files. Because of this, Dolphin's imported saves would fail some games' save integrity checks. This is because Dolphin was mistakenly aligning non 64 byte files to 64 byte lengths.

While it took a long time to identify the problem, once we realized what was broken, JosJuice quickly patched the issue. Anyone who's had issues importing saves over the past few months should try again in the latest development builds, as there was there's a good chance any issues stemmed from this bug.

Note: Dolphin's Wii Save Export is currently not working with the Wii System Menu. This is likely to be fixed in the next couple of days, but, not present in the Monthly build. If you require exporting a savefile to Wii, please wait until Pull Request 8084 is merged before attempting to use this feature or use a stable build.

5.0-9988 - Improved Freelook Camera by Billiard¶

Freelook may not appear like a very important feature at the surface. For the average user, one might assume that the most interesting thing you can do with it is get a look at parts of the game not normally visible. You can find things like the bowling balls in distance of Wii Sports Resort aren't exactly round or look at how much the game is rendering, but not much else. To a player, it has limited utility.

However, Dolphin's userbase is full of a wide range of users with a variety of goals. For some people, Freelook is among the most irreplaceable enhancements, giving them a remarkable tool for videogame photography! In fact, many of the screenshots from our site's screenshot gallery and nearly all of the blog headers take advantage of Freelook to create interesting and vibrant compositions.

But Freelook was marred by a limitation - it was unable to roll the camera. With only five of the possible six axis manipulable, lots of problems would appear in complex camera moves. For example, in games where the camera follows a character, the camera is almost always high above the character and tilted down so players can see what's ahead clearly. Freelook inherits that tilt from the game camera, so any camera position perpendicular to the game camera will be at a steep angle. Without roll, there was no way to correct this.

Freelook is a staple of the blog, with MayImilae constantly using it to get some of the impossible shots that make up the headers and more dynamic images. Last month's article on MotionPlus featured a dynamic shot of Link flying that you couldn't get without Freelook!

She ran into the lack of rotation issue for quite a few shots over the years and had mentioned this limitation to developers several times, but no one had even looked into it. Billiard, apparently needing a break from groundbreaking peripherial emulation, recognized that it would be a pretty easy fix and offerred to help. With a quick bit of work, Freelook can now roll the camera with the middle mouse button!

Billiard's fix was very thorough. Not only did he add rolling, but he also changed Freelook to a matrix so all camera moves are remembered and work off eachother correctly, all while actually using less code than the old implementation! This elegant solution once and for all solves this longstanding issue with one of our favorite enhancements.

5.0-9993 - Implement Shader Pipeline Cache For OpenGL and D3D12 by Stenzek¶

Users on AMD and Intel drivers will probably want to take note of this change. While Dolphin now caches ShaderUIDs in a generic format that is sharable between backends, those still need to be compiled into something usable by the GPU. We rely on the GPU to cache the shaders in that format so that you don't need to recompile them every single run. Unfortunately, AMD and Intel weren't actually caching D3D12 pipelines. This meant having to recompile all cached ShaderUIDs on every single boot, resulting in long startup times or significant performance issues until they're asynchronously compiled in the background. Stenzek remedies the situation by keeping a shader pipeline cache around for these cases.

Android users also get a benefit from this, as Stenzek extended this behavior to OpenGL as well. This change will also bring much less shader compilation to Android drivers lacking a pipeline cache.

5.0-10063 - Fix Monster Lab FIFO Issues by iwubcode¶

One of the great mysteries from Dolphin have finally been solved. Monster Lab finally works... and it was essentially a single line fix. This is yet another of those problems where the issue was caused by a bad assumption that didn't break any games existed at the time. Because of lackluster (or non-existent) hardware tests, early developers didn't fully understand a lot of the intricacies of the GameCube/Wii hardware. While we have a much better understanding overall now, there are a bunch of mysteries that we still haven't even thought to test.

iwubcode bought the game for the express purpose of investigating this particular mystery. Other developers had looked at it in the past, but, no real headway had been made. Through a stroke of incredible fortune, within 24 hours, they had seemingly stumbled upon a hack that would fix it.

They changed a behavior in how Dolphin handles the Write Gather Pipe (WGP). To simplify things, think of the WGP as a small buffer on the CPU for GPU commands. The commands are stored until there is enough (32 bytes) to efficiently transfer to the GPU's command FIFO. At some point, the game changes the Read-Write Distance (RWDistance) to zero, essentially saying all data in the FIFO's circular buffer has been processed. Dolphin would then clear the WGP of any remaining data because the CPU and GPU are at the same point in the buffer. What iwubcode did was instead of having Dolphin clear that data, it was changed to just be left alone. This allowed Monster Lab and another title on the same engine, Death Jr. Root of Evil to run correctly.

Intrigued by the prospect of this hack, Stenzek and booto investigated further. A couple of days and a few hardware testing later, it was revealed that iwubcode's hack wasn't exactly a hack. Setting RWDistance to zero shouldn't affect the WGP whatsoever, and because Dolphin was erroneously clearing those commands, the games were hanging. Whoops.

While this may sound like an essential fix, we aren't expecting any leaps in compatibility outside of these two games due to the fact the bug managed to stay hidden for so long. In fact, it might make things a little worse for the time being. Because this change touched Dolphin's FIFO code, it's extremely likely to cause some regressions. While this particular change is hardware tested, it can still affect other pieces of Dolphin's FIFO that relied on the old behavior to perform correctly.

5.0-10039 - Jit64 / JitArm64: Optimized idle skipping detection by degasus and delroth¶

Emulators, at their very simplist, are translators. Whenever a game gives an instruction, Dolphin's job is to translate that instruction into something the host hardware can understand. This translation step is why Dolphin requires a much more powerful CPU than what was present in the GameCube/Wii. Even if an instruction takes only a single CPU cycle on the original hardware, emulating that same instruction will take MANY more cycles on the host system, as much as a 100 times more! So naturally, if we can reduce the number of instructions we emulate without harming accuracy, it would be a big help. That's the idea behind Idle Skipping, a very important performance trick in Dolphin.

Stopping a CPU is an involved process, and it takes a long time for it to wake up. So if a CPU is waiting for something brief, such as for a frame to finish rendering and scanout, the CPU will idle loop, spinning in place doing nothing but keeping itself alive and ready. Until a set time (measured by the cycle counter) has expired or an interrupt arrives, the CPU will dutifully burn cycles doing nothing. While this is all normal, emulating this really sucks for Dolphin. Every one of those cycles is going to cost an order of magnitude more cycles for Dolphin to emulate, yet they are literally doing nothing! So, we skip them. Whenever the game starts idling, Dolphin detects the idle loop and casually nudges the cycle counter a bit so the emulated CPU thinks more time has passed than actually has, and keeps nudging until the loop is complete. This way, the idle loop finishes faster with the majority of waste cycles skipped. Dolphin is already handling syncing and real world timing itself anyway, so Idle Skipping is an easy and safe performance boost.

Of course, this is not cycle-accurate, but the architecture of the GameCube and Wii doesn't require cycle accuracy to emulate properly (phew). If a situation comes where a game breaks with idle skipping, we'll happily disable it for that title. But for our purposes, idle skipping is deterministic for netplay and TASing, so there is no need for general users to worry about it.

So now that we've established all of that, what does this change do? For as long as Idle Skipping has been around, Dolphin has detected idle loops by searching for particular, known idle loops that were manually hardcoded into Dolphin way back when. While this is very inflexible, the loops Dolphin were looking for were the standard loops that Nintendo provided in the SDK, so it was very effective. But, of course, some games just had to make their own unique idle loops, and Dolphin had no ability to detect them. To pick those up, we'd need a much more robust solution, a proper heuristic that could detect any idle loop and respond appropriately. This... was actually in development many years ago, but only really came into fruition recently.

Inspired by an idle loop in Xenoblade Chronicles that was completely undetected by Dolphin's idle skipping code, delroth started work on a better solution. He wrote up a patch that would not only detect the Xenoblade Chronicles loop, but actively search for idle loops and variations, completely replacing Dolphin's old hardcoded model of detection! Unfortunately, he was a bit ahead of his time as other parts of Dolphin simply weren't ready for something like this. Until there were major reworks to Dolphin's emulation of the Memory Management Unit, something like this could never happen.

After many years of the emulator improving, the barriers that blocked delroth from finishing his idle loop detection were gone, so degasus revived the project and resubmitted it for testing. The results were astounding in Xenoblade Chronicles, where performance could nearly double depending on the scene.

Something to take away from the results is busier scenes spend less time idling, so Idle Skipping has less to skip. That said, even the busy scenes in Xenoblade Chronicles tend to run roughly 20% faster with this idle loop detected. This behavior should be consistent across most games with newly detected idle loops for those hunting out more cases.

Even if you're not worried about performance whatsoever, the new idle skipping changes do bring some accuracy benefits. It turns out there were cases where the hardcoded detection picked up busy loops that weren't idle loops, creating to some serious bugs! By swapping over to the new idle loop detection, these false positives and the bugs associated with them are now gone. Assorted hangs in Resident Evil Zero and an extremely popular Wii game called CSI: Hard Evidence have been repaired. A special thank you goes to the very dedicated users who bisected these behaviors and verified the fixes.

5.0-10095 - Disable Memory Watcher by Techjar¶

In other months, a change like this may have warranted a long storytelling segment with twists and turns as poor Techjar spent literally over 20 hours in three days hunting down an issue seemingly caused by the idle skipping optimizations. Techjar is a Linux user, and all of the sudden, Mario Party 7 stopped synchronizing with his Windows friends. While normally a bisect and a quick fix would be all that's needed for a determinism issue, in this case things spun out of control very quickly.

The change that was causing the issue was the one mentioned directly above, 5.0-10039 - Jit64 / JitArm64: Optimized idle skipping detection, which shouldn't affect determinism between different operating systems. The bisect got even weirder when seemingly random changes affected behavior. Plugging in a microphone into slot B (which doesn't work on netplay...) would cause it to synchronize sometimes. Launching the game from BIOS would more or less bypass the issue, and even more strangely, setting Dolphin to report as a retail system instead of development system would also fix the issue.

After all of that, digging through the problem instruction by instruction, he finally found the culprit. Dolphin's Unix-based versions has a memory watcher not present in the other versions of the emulator. For some reason, the idle skipping change triggered a dormant bug. This memory watcher, that most developers didn't even know existed, could actually affect execution very slightly. Because netplay and TASing are important features for many of our users, we've decided to disable the memory watcher for the time being. If the issue is resolved, the memory watcher can be easily re-enabled.

5.0-10101 - Implement 3rd Party Encryption and uDraw Tablet by Billiard¶

If MotionPlus emulation wasn't enough to win you over, Billiard returns with another extension that saw use entirely with drawing games. The uDraw tablet on the Wii was a Wii Remote extension that was used exclusively for the uDraw titles. While users could play these games by buying an actual uDraw and using Real Wii Remote support, there was no emulated option, much like with Wii MotionPlus until recently. Again relying on Ghidra, Billiard navigated obfuscated lookup tables to replicate the encryption and then reverse engineered communication so that you can now select and configure your emulated tablet.

Some Special Notes¶

Always Remember to Update Your Drivers!¶

While testing the VideoCommon rewrite we ran into a rather pleasant surprise. A recent NVIDIA driver update has fixed some crucial issues in Dolphin when using the Vulkan backend. The bug was breaking laying of objects in menus and 2D scenes in games as varied as Metroid Prime 2 to Mega Man X.

Another NVIDIA driver issue that we've been keeping tabs on is the D3D + NES Virtual Console game issue.

This issue has been around for as long as Dolphin could properly run NES VC titles, and has been one of the more mysterious issues. One day, no one could reproduce the issue with seemingly no warning. Because it has been so hard to monitor in the past, we're not declaring this issue fixed quite yet. If anyone is still running into this issue on the latest NVIDIA drivers and the D3D backend with synchronous shaders, please let us know on the forums.

Don't Always Update macOS¶

It hasn't even been a year since Apple officially deprecated OpenGL with macOS 10.14. We didn't really expect anything to happen for a while though, assuming Apple would just leave OpenGL alone (as they have already done for years) for a few more releases. However, a month ago, we were surprised to hear that a minor update broke our OpenGL backend's rendering in macOS! Dolphin's OpenGL backend worked perfect fine in 10.14.3, but the exact same Dolphin version just showed a grey screen in 10.14.4.

We didn't know what was going on, so we let everyone know not to update to 10.14.4, and hoped we could find some workaround. Fortunately, we got lucky! A new contributor to the project, pokechu22, was working on a minor annoyance of the Qt GUI. Namely, when emulation was paused and you clicked away, Dolphin's render window would lose the image. When developing things like homebrew that may stop pushing frames for long periods of time, what was an annoyance turns into a major problem.

Independently of even knowing about the macOS issue, they submitted their fix, which was merged in 5.0-10079. On a hunch, Stenzek decided to try the change on macOS and found that the issue had been resolved. For now, OpenGL is again functional on the current latest version of macOS.

We don't actually know why this fixed macOS rendering. Our best guess is that something in 10.14.4 was giving the Qt interface layer higher priority than our rendering layer, but we don't know for sure. Still, we'll take it! Regardless of this lucky fix, it's important to note that macOS still has the worst driver situation for Dolphin and it is an inferior platform for emulation in general. Once Apple removes OpenGL support completely, the situation will be even more dire. As nice as MoltenVK support is as an option, it's still slower than OpenGL in many cases and is significantly slower than native Vulkan support. Running Dolphin on Windows via Bootcamp is still our recommended way to get the best possible Dolphin experience from a macOS machine.

Last Month's Contributors...¶

Special thanks to all of the contributors that incremented Dolphin from 5.0-9497 through to 5.0-10115!