One of the most enjoyable parts about being a part of emulation is seeing the classic gaming community use the tools we provide to find hidden bits of joy that would be impossible to reach otherwise. Freelook has found secret after secret hidden away just off-screen, and there's even a youtube series that focuses entirely on them! Savestates basically made speedrunning and TASing possible, allowing for quick testing of routes and sequence breaks to push games to their limits. But communities can go far beyond that, with tools now allowing us to look directly into game files and expose unreleased and rare relics. In the past couple of months, we've had two incredibly interesting leaks: A TGC file ripped from a store preview disc containing a pre-release version of The Legend of Zelda: The Wind Waker and a very early prototype of the never released Spider-Man 4.

Each of these games give a very specific look into their development. Wind Waker's prerelease demo is very close to the retail product and fully playable beginning to end without the imposed timer. Those that have looked into it have found a plethora of minor differences and glitches between this build and the one Japan would see a few weeks later. Spider-Man 4 on the other hand, never saw release and this was just about everyone's first look at the game. While it emulates just fine in the latest development builds, it does not run in Dolphin 5.0, due to broken support for unencrypted Wii discs. If you do run it, you get to see an incredibly early preview of the game with many non-existent textures, placeholder graphics, and incomplete collision detection. Still, we're happy that Dolphin was chosen as a platform to test out this unique prototype and the game worked without needing modification. With that bit of interesting news out of the way, let's get back to our regularly scheduled Progress Report.

Notable Changes¶

5.0-11129 - Don't Crash When Running Wii Freeloader by JosJuice¶

Jumping straight from unreleased prototypes to unlicensed releases, we once again welcome an old friend. When it comes to unlicensed GameCube and Wii software, it's hard to think of any other name than Datel. Over the lifetime of the two consoles, they released a ton of applications, games, and even a GBA emulator. On this particular day, we're talking about the Wii release of Datel's Freeloader, a handy bit of hackery that allowed Wii owners to launch games from other regions.

Since Dolphin can be any and all regions, Freeloader isn't really all that useful for our users. Even so, Freeloader is still quite a neat curiousity for us since it relies on multiple exploits and weird console behaviors that's challenging for us to emulate. In fact, Datel's Freeloader for Wii crashed Dolphin all the way up until this change from JosJuice for a reason completely apart from all its exploits. For whatever reason, Freeloader sets framebuffer width to 0. Because Dolphin divides by a variable derived from width to detect interlacing, Dolphin would crash due to no failsafe for this particular case. While we haven't completely tested the consequences of what Freeloader is doing, Dolphin now has a safeguard against dividing by zero when detecting interlacing.

Now that it wasn't crashing, the main challenge became testing Freeloaders exploits in Dolphin. Part of the problem was having a system menu version vulnerable to its exploit, as Nintendo patched out everything they used by the time 4.x System Menu revisions hit the scene. For our purposes, we tested 3.2U (NTSC) and 3.1E (PAL) which were known to work with Freeloader for Wii. While it took us quite a while to figure out exactly what it wanted us to do, we were able to test and verify that it worked in Dolphin.

GameCube imports were the simpler of the two cases to test. Insert the Freeloader disc, wait for the Wii to freeze while watching the disc channel, and once the Wii rejected the disc, simply swap in an import disc and it'll boot up as per normal. However, Wii games did not work with this method and left us puzzled. Through trial and error, one of our testers discovered that you needed to put in a valid in-region disc after Freeloader is rejected, eject that, then insert your import.

Interestingly, Freeloader itself struggles with a lot of issues that Dolphin has tackled in the past regarding various regional behaviors. When Dolphin first added MIOS support, games that required MIOS patches failed to boot and the same thing happens with Freeloader. Freeloader also has no way of handling text for other region's games when they require the BIOS provided typeface. On the Wii side of things, any of the games that froze with the wrong language configured in Dolphin also freeze with Freeloader, such as Tales of Graces.

All of those oddities we can explain and make sense, however there is one thing we ran into that is currently a mystery. While we demonstrated that the Wii Menu would freeze during the exploit in the video above, one of our testers running the same build of Dolphin with the same settings had a different behavior during that freeze. Instead of the Wii System Menu just appearing frozen, they saw the Freeloader logo popup during the freeze, which made it much more apparent that it succeeded! Datel's instructions only mention flashing bars during success, so we still need to verify this on a console with a vulnerable System Menu to see if this is indeed the correct behavior.

5.0-11160 - Show Current Input States in the Advanced Input Window by Billiard¶

From last month, Billiard continues his improvements to the Advanced Input Window. This change is much easier to explain with some screenshots.

In order to make things clearer and help users understand what's going on in the advanced configuration window, Dolphin will now display and update controller button status. When there are tons of buttons listed, this makes it much easier to identify what button does what. Combined with Billiard's previous improvements, the Advanced Input Configuration dialog is remarkably better than it used it be!

5.0-11165 - Add Ability to Override ResourcePack and Load Directory by iwubcode¶

HD texture packs have been a major feature of Dolphin for a long time. The community has produced some remarkable results, with tremendous packs that can even make an old game look as good as an official HD remaster! The cost of this improved fidelity is size; many HD texture packs are actually bigger than their base games!

By default Dolphin's Global User Directory is placed in the user's boot drive, specifically in the place each operating system recommends applications put their files. We placed it there for a lot of reasons, such as having no silly behavior restrictions, being default OS backup locations, and being where applications are supposed to put their files makes our data relatively easy to find. While this put all HD texture packs into users' boot drives, it didn't really matter back then. Sure the combination of a small fast SSD boot drive and a big slow HDD storage drive existed even then, but the texture pack scene and the packs themselves were MUCH smaller in those days, and we assumed that SSD prices would quickly come down so we wouldn't need to really worry about it.

But thanks to industry-scale NAND supply problems, SSD prices actually went up for a couple years. As our HD texture packs kept getting bigger and bigger, users boot drives stayed the same, or even got smaller relatively as more HDD users upgraded to small SSD boot drives. It became a bit odd that Dolphin didn't allow users to choose where HD texture packs go. We approached the problem through other means, such as adding BC7 texture support to reduce texture pack sizes without sacrificing quality, but texture pack creators took advantage all of those gains to make bigger textures, so that didn't exactly go as planned. As users continued to request for the option to change where texture packs are stored, the problem clearly persisted. Fortunately, iwubcode stepped up and finally implemented the option to set custom Load and Resource Pack directories in the paths tab. It's a bit overdue, especially since SSD prices are finally sane and users no longer need to choose between speed and capacity, but for users with a small SSD boot drive in the red, this should help a bit in getting it under control.

Worried that moving the resource pack to a bulk harddrive may cause stuttering as the textures are loaded? If you have sufficient RAM, the Preload Custom Textures feature in Options > Graphics > Advanced can mitigate that entirely.

5.0-11170 - Support Windows 10 Long Paths and 5.0-11195 - Fix Malformed Manifests by CookiePLMonster¶

Here at Dolphin, we take pride in our careful review of pull requests before changes are merged into master. Through thorough checks and community feedback, we do a pretty good job catching mistakes before they can cause problems for our users. But we are only human, and even with very thorough checking with multiple reviewers, sometimes problems can slip through unnoticed. This month had one of those times.

Due to an unforeseen issue, our updater was unable to run 5.0-11170 to 5.0-11195. We did catch it quickly enough to prevent it from affecting our monthly update track users, so not many users were affected. But for all of our dev track update users, the updater ceased to function and they had to suffer the indignity of manually updating to get past it. Ooph.

So what happened? The past few months, CookiePLMonster has been on a quiet crusade to fix rare little bad experiences throughout Dolphin. One of those is that Windows can actually refuse to load files if the path is too long. That sounds like a bug one would encounter when playing with a retro computer from 30 years ago, but it is still a thing even in Windows 10. Ever since Windows 95, Microsoft has limited the maximum length of file paths (including the name of the file at the end) to ~255 characters (260 in Windows 10). That's a lot of characters to be sure, but when you combine that with the long nested tree of the Windows file stucture, especially in the User folder where a user's long name may be present, those 260 characters can quickly evaporate. If a file path ever happens to exceed that limit, Windows will flat out refuse to load that file without giving any reason why.

Given that some of our users have encountered this over the years and the absolute nightmare it is to diagnose, this issue has been burned into our minds. Fortunately since Windows Vista, Windows Explorer will prevent users from creating a path that is too long. However, there are still some cases where this check doesn't apply. The most common include setting up a new Windows installation over an old one, extracting a very nested archive, or using some other means to create/move files on the drive.

There were some hacky ways for Windows users to deal with this in the past via regedit or gpedit, but there was nothing applications could do about it. That is, until Windows 10 1607. Windows now allows applications to lift the Max Path limitation for themselves through a manifest attribute. All Dolphin had to do to support long paths is switch our Windows Settings Manifests from v2005 to v2016, and then enable longpathaware. That's it! After testing and review, it was merged, and Dolphin will never again be plagued by Max Path errors when loading custom textures or ISOs.

Unfortunately that was a little too simple. Between v2005 and v2016, Microsoft removed the dpiaware manifest attribute, which we have been using. We weren't aware of this at the time, and since Dolphin.exe silently ignored the nonfunctional dpiaware attribute, everything appeared to be working properly after the manifest update. It cleared review without anyone noticing, and the nonfunctional attribute was merged into master. While Dolphin.exe didn't care, our updater.exe exploded. Loudly. Once users got back with us and we realized what was going on, it was a pretty quick fix. All we had to do was specifically define the dpiaware attribute to the 2005 manifest version, and everything worked once again. It was a tiny change, but that made all the difference for our updater.

All in all, everything turned out fine, and we gained a permanent solution to an annoying little user experience issue.

5.0-11186 - Add /dev/dolphin device for homebrew to communicate with Dolphin by Leseratte¶

This is an incredibly cool feature that has a lot of potential to be used in interesting ways in the future. Developed by Leseratte, this essentially lets games communicate and control Dolphin through an IOS device, much like how games communicate through devices. However, because /dev/dolphin doesn't exist on the Wii, no retail games would ever access nor communicate over this device. While any homebrew or game mod could use this, currently Wiimm's Mario Kart Wii mods use this as a way of communicating real-time timer data with the servers. Because the in-game timer is affected by things such as emulation speed and lag. By being able to communicate with Dolphin and understand these situations, the game can change Dolphin's target CPU clock, emulation speed, and other settings in order to keep the race fair.

This is incredibly important because Mario Kart Wii determines where a player finishes by their time in game. So if a player is lagging a lot, even if they finish 30 seconds behind, they can disrupt the whole leaderboard. By using /dev/dolphin to get realtime clock data from your PC, Wiimm's Mario Kart Wii servers can correct for minor lag and other issues allowing for races to be much more consistent. This should also help prevent Dolphin users from being erroneously banned due to lag-spikes of any nature.

While this feature is very specific to homebrew aware of Dolphin, it could definitely be used and expanded for things like hardware tests, debug information, and be useful for other mods as it gives them the ability to see the state of the emulator that it is running on.

5.0-11191 - DolphinQt: Add accelerometer/gyroscope mapping indicators by Billiard¶

Billiard was working on an enhancement to last month's Motion Input feature, but it didn't make it in time for the previous Progress Report. The change adds 3D visualizations of the virtual Wii Remote to the Motion Input tab. There isn't a lot to say about it really, other than it's super f*ing cool!

5.0-11271 - Do not yield to UI from PauseAndLock by CookiePLMonster¶

CookiePLMonster has been on a quiet mission that has mostly taken place behind the scenes. His goal? Eliminate all the weird, seemingly random crashes that can happen from changing settings while a game is playing. How he stumbled upon this particular bug, we'll never know. In his initial pull request, he explained the exact sequence of events that it would take to crash Dolphin just by changing the volume while in a game.

1. Volume control hotkey is triggered.
2. AudioPane::OnVolumeChanged is called.
3. AudioPane::SaveSettings is called.
4. InvokeConfigChangedCallbacks is called.
5. VideoConfig::Refresh is called on CPU thread (acquires stepping mutex).
6. CPU::PauseAndLock waits for s_state_cpu_idle_cvar which times out.
7. Timing out causes Dolphin to yield to UI and call processEvents.
8. AudioPane::OnVolumeChanged is called again, and so are further calls.
9. VideoConfig::Refresh attempts to call on CPU thread again.
10. Stepping mutex is not recursive, so attempting to acquire it again results in an exception.

What does all of this actually mean? Basically, spamming the volume up/down hotkeys while a game was running had a chance to deadlock Dolphin and crash your game. Worse yet, this applied to other actions, such as mashing the screenshot hotkey, meaning there were multiple ways that this crash could affect users. Thankfully, Dolphin should be much, much more stable thanks to these fixes, and keep in mind this is just one of many that CookiePLMonster has been hunting down with more to come. He seems hellbent on making sure that Dolphin never crashes. And hey, that's something we can get behind.

5.0-11309 - Android: Native Motion Controls by JosJuice¶

Your scientists emulator developers were so preoccupied with whether they could, they didn't stop to think if they should.

Sometimes, we all get drunk with power and go too far. We don't think about the consequences of what we are doing until it's too late. We see this beautiful new feature on the horizon and rush to it, not truly understanding the full impact of what we are doing. Before we even realized it, we had put an incredible, reckless power in the hands of our users. As of 5.0-11309, Dolphin Android users can now use their mobile devices' own motion sensors as their Wii Remote.

The Nintendo Wii Remote is an uncontrollablle force of destruction known to obliterate anything in their path. If you throw it at a TV? You're buying a new TV. If you drop it on the ground? Congratulations on the new hole in the floor. Accidentally throw it at a Sherman MKII Wartank? You get the idea. Your smartphone is not a Wii Remote, and it will not survive what a Wii Remote can survive. But now you can use it on Dolphin Android as a Wii Remote, complete with motion controls. Authentic Wii Remote controls on the go... but at what cost.

There are responsible ways to use this feature, for certain. Games like New Super Mario Bros. Wii only need a gentle shake or tilt to conquer all of its motion control needs. However, we know it won't stop there. Reckless users will take to the streets playing games like Skyward Sword, putting themselves and everyone around them in danger. But at least, they'll be wielding a fragile phone and not something as deadly as a Wii Remote. However, one drop, and your emulation experience could be over. Unless...

NOTICE: Use Android Native Motion at your own risk. Dolphin is not responsible for any damage inflicted to your device, yourself, or your Sherman MKII Wartanks.

5.0-11333 - Update VS projects/solutions to VS2019 by stenzek¶

While working on the Progress Report, we decided to go ahead and update our Visual Studio projects from Visual Studio 2017 to Visual Studio 2019. It's nothing special really, just us updating our libraries so we can take advantage of new features and benefits in the future. This shouldn't affect users at all; since MSVC2019 binaries are compatible with the MSVC2017 and MSVC2015 runtimes, runtime updates shouldn't be required. We even did a quick test on a PC with only MSVC2017 runtimes and encountered no issues after the update. However, we've since been informed that RPCS3 and Xenia both had a spike in missing DLL error reports after they updated to MSVC2019. If you encounter a MSVCP__.dll error or vcruntime__.dll error, get the latest x64 Microsoft Visual Studio runtimes from Microsoft's website (direct link).

Last Month's Contributors...¶

Special thanks to all of the contributors that incremented Dolphin from 5.0-11103 through to 5.0-11333!