The past few months have been quite hectic with a slew of gigantic changes requiring lengthy articles alongside them. These big features all hitting together seems to have brought up a talking point in the community would be irresponsible to ignore. Everyone wants to know when Dolphin 6.0 is coming. After all, Dolphin 5.0 launched nearly three years ago and lacks features like Ubershaders, Bluetooth Passthrough, Hybrid XFB, Emulated Motion Plus... the list goes on. Unfortunately, we have to announce that we aren't especially close to a release right now.

A release build is about more than just having exciting features, it's meant to be stable, reliable, and highly compatible. Since Dolphin 5.0, there have been a lot of minor and major regressions that haven't been fully worked out yet. Whether it's a game like Ed, Edd, & Eddy: The Mis-Edventures hanging on a loading screen or audio being broken in Resident Evil 2. There are dozens, if not over a hundred of these little issues that just take time and effort to address. Some of these issues are close to being resolved while others haven't even been investigated yet.

All we can ask of users is to continue using the latest development builds, continue reporting bugs, and be patient with the next release. With that out of the way, it's time to get to this May's Notable Changes. As always, users who want to try these features can download the latest development builds on the download page or use the auto-updater to get a new dev build every month automatically. Enjoy.

Notable Changes¶

5.0-10163 - Implement "Drawsome" tablet by Billiard¶

Last month, Billiard implemented third party encryption and alongside it, emulated uDraw Tablet support. But Billiard wasn't done there, there was actually a second Wii tablet with its own lineup of games. This competing tablet was made by Ubisoft, which you'd think would have made the uDraw tablet given the name, but no, that was actually produced by THQ. Instead, Ubisoft brought us the Drawsome tablet, which can be easily mistaken for a uDraw tablet at a glance. Unfortunately, if you ended up with this tablet, you'd be stuck with its library of three games:

• Drawsome! Artist
• Drawsome! Sketch Quest
• Drawsome! Artist and Drawsome! Sketch Quest

5.0-10131 - Implement "Taiko no Tatsujin" Drumset by Billiard¶

Taiko no Tatsujin is another game series that supports a hardware attachment to the Wii Remote, and thus Billiard wanted to emulate the device. This time, we're talking about the game's optional drumset accessory, known in Japan as "TaTaCon". With it, you can become a drum master and bang your way through tons of songs in this frantic rhythm game. It's a lot closer to the original arcade experience than simply pushing buttons on a Wii Remote. Thanks to emulation, using these is just as convenient as the originals, except now you don't even need to worry about batteries for your Wii Remote!

Of course if you are mapping the emulated TataCon to a gamepad's buttons then it's not all that different from playing with a Wii Remote, but if you are using PS4 or Switch TaTaCon, this is transformative. The TaTaCon aren't two buttons, but four, with the drum and rim divided down the middle. Thanks to this, players can navigate menus and play entirely by smacking the TaTaCon, just like in the arcade! But if you have a modern TaTaCon and try to map it to onto the simpler Wii Remote controls, you can't navigate and play with the same config; you have to configure navigation to a separate controller. Now with proper emulation, users can navigate and play with just their modern TaTaCon, and have matching menus to boot! As Wii TaTaCon rapidly disappear, this change will help preserve the proper Wii Taiko no Tatsujin experience for years to come!

5.0-10188 - Allow interacting with the render window while configuring controllers by Pokechu22¶

This is a bit of an odd behavior that cropped up when switching over to Qt. When a controller configuration window was opened, you couldn't actually bring the game window to focus. This meant that in order to test changes you've made to your controls, you'd have to close the window first. This made adjusting controls while playing games a bit inconvenient. Pokechu22 modified the window structuring a bit to allow users to interact and move around the render window even when the controller configuration window is open.

5.0-10192 - Set Cubeb as default on Windows by Miksel12¶

With the addition of the Cubeb Audio Backend Dolphin finally had a cross-platform solution to audio output. Developed and maintained by the folks from Firefox, Cubeb abstracts away the need for Dolphin to directly interact with each operating system's platform-specific audio systems. Cubeb also sees heavy testing through its use in Firefox. If an operating system update breaks Cubeb, odds are it'll be fixed upstream before a user even reports the bug to us. Thanks to all of Firefox's work, Cubeb's consistency between different operating systems makes it an excellent choice as our default audio backend.

We will be keeping around our other audio backends, since we do have less control over Cubeb and might still need them one day, and for user preference. Note that existing users will be unaffected by this change - this change in default is only for new installations of Dolphin. Even if you auto-update, your audio backend selection will not be changed.

5.0-10196 - Implement passive stereoscopic 3D by iwubcode¶

3D Monitors don't quite have the luster they had several years ago. The once exciting technology didn't truly catch on and has long been replaced by the Next Big Thing™. Earlier this year, NVIDIA even discontinued support for 3D Vision. It's not hard to figure out why - even with Dolphin, 3D features aren't tested all that often and can be broken for months at a time.

Waning interest in 3D technology didn't stop iwubcode from implementing support for Passive Stereoscopic displays, though. That's because Dolphin already has a lot of the infrastructure in place for 3D output, and while it does get broken occasionally, most of the work has already been done. If you have a passive 3D screen and want to see if your favorite game works well in 3D, now's the time to try it!

For those who might have forgotten, Passive Stereoscopic 3D used polarized interlaced lines and polarized glasses to send unique images to each eye. This was significantly easier to support than Active 3D, which required expensive features such as high refresh rates and active shutter glasses, but cut vertical resolution in half, added interlacing artifacts, and reduced viewing angles. Most stereoscopic displays sold were passive, so it was important for us to support it before stereoscopic displays fade away.

5.0-10270 and 5.0-10344 - IOS HLE Fixes and Passthrough Upgrades by leoetlino¶

The Nintendo Wii was the first Nintendo home console to feature USB ports, and some games and applications would take advantage of this for various USB devices. The Internet Channel received an update that allowed users to use USB Keyboards, the Skylander games use a USB device for players to place and swap figurines, and fondly remembered Tony Hawk Ride came with a USB Skateboard. There's actually a surprising number of USB devices, and many of them have worked in Dolphin for years, unknown to most users and even developers!

Since then, Passthrough has become a bigger part of Dolphin to help users get an authentic experience in their favorite games. From GameCube controllers to Bluetooth adapters, you can pass through tons of devices and use them on Dolphin with minimal configuration. Once set up, it's just plug and play!

The main issues with Passthrough have come from platform limitations. USBv4 (HID) support has been painless since it was originally merged because it only uses relatively simple transfer types. Controllers such as the Skylander Portal and the Tony Hawk Ride Skateboard will behave as expected on all platforms. For devices using IOS's OH0 and VEN (USB 2.0) interfaces, the situation got a bit more complicated. While Dolphin has implemented them since 5.0-2352 support has greatly varied depending on the operating system. Users on Windows in particular were stuck with instability problems due to both Dolphin bugs and issues with libusb. Particularly, support for isochronous transfers (which are notably used for microphones on Wii) has been very lackluster and nearly non-existent back when support was first merged.

As a Linux user himself, leoetlino eventually determined that libusb support on Windows wasn't good enough to support the Wii Speak and USB Microphone consistently, or the USB Camera at all. While the usbdk backend did provide some isochronous transfer support, it suffered from a variety of crashes, connection issues, and transfer bugs that made using the devices on Windows a gamble. The only thing we could do was wait for libusb or one of the backends to add better support.

After a two year hiatus, the situation had finally changed. Both the WinUSB and libusbK backends now have isochronous transfer support, giving us more options to see if some of the bugs from usbdk could be worked around. With excitement, we updated to the new version of libusb and tried out the other backends only be to be greeted with the same problems that plagued Dolphin all those years ago. But, leoetlino wasn't ready to give up quite yet. The fact that some of the bugs were consistent between backends narrowed things down quite a bit.

The first problems were actually spotted in Dolphin. While somehow Linux managed to work with these devices, we found out that Dolphin was using the wrong buffer sizes for games using USB VEN. How this didn't cause more problems, we don't know, but upon fixing that, nothing really improved. It wasn't until several days of hardcore debugging that things started to make sense. On top of the Dolphin bugs, he found three bugs in libusb itself. These fixes are particularly important, because if they are merged upstream, they will improve support for similar devices across other programs and perhaps even other emulators! Until then, we've applied the fixes to the version of libusb that Dolphin uses so that everything works for us right now.

As the fixes piled up, things finally started to make sense and everything came together. When combining the Dolphin fixes, libusb patches, and the libusbK backend, isochronous transfers were finally working consistently on Windows. This means that superfans of the smash hit Your Shape: Featuring Jenny McCarthy can finally be played on Windows along with the other USB camera games.

If you're more into actual games, leoetlino also greatly increased the stability of both USB Microphone and Wii Speak passthrough. So if you're a fan of Rockband, Karaoke Revolution, Guitar Hero, or any of the other games that supported the USB Microphone, you can finally enjoy those games without the risk of randomly crashing at any time.

Updates on the libusb situation¶

With all of these updates, we've changed some of the instructions for setting up USB and Bluetooth Passthrough. Because of the inherent stability issues with using usbdk in Dolphin, we no longer recommend it. If you're a user that uses USB Passthrough, we highly recommend that you update to the latest builds of Dolphin and use libusbK for all passthrough. It has proved to be the most stable and compatible libusb backend through careful testing. While this may change over time, both WinUSB and usbdk have downsides.

• libusbK: Supports all known compatible devices and does not crash.
• WinUSB: Supports most devices, but does not work for USB Camera, USB Microphone, or Wii Speak Passthrough. Will sometimes hang when attempting to detach devices on emulator stop.
• usbdk: Theoretically works for all devices, but has some severe issues. While it does work okay for GameCube Controller Passthrough and some Wii USB devices, do not use this for Bluetooth Passthrough. usbdk is extremely problematic and can even hang your game resulting in it immediately closing due to losing connection with the Bluetooth device. Games like Metroid Prime Trilogy are not supported at all due to it having a required ES_Launch, which causes usbdk to fail. It also suffers from random crashes while using USB Microphone, USB Camera, and Wii Speak Passthrough.

For users on macOS, VinDuv helped point that the version of libusb we were previous using has a bug breaking GameCube Controller Passthrough. We've updated to a newer version to restore support.

Another mostly unrelated change is a performance optimization for USB OH0 games. This will mostly affect games on older IOSes as the newer VEN protocol doesn't suffer from the issue. The problem is that the games were opening and closing the device every frame, causing Dolphin to do a full scan for devices, which is quite slow. Dolphin now only waits for the scan to complete the first time the device is opened. As a result, American Idol Encore runs nearly ten times faster than before when a Microphone is connected. There have also been some changes to increase stability. While libusb claims to be thread-safe, we've repeatedly found that to be incorrect so we've added additional safeguards to help prevent crashes when using various forms of passthrough.

5.0-10379 - VideoCommon: Constrain the array_base registers by booto¶

"Random crash" are cursed words in the world of emulation. These crashes are rarely actually random, but the result of some rare and inconsistent event that is very difficult to reproduce. Star Fox: Assault was plagued by one such "random crash". For years, we've had reports of a crash during Mission 5, but our attempts to reproduce it failed time and time again. But as the years rolled by, knowledge about the crash slowly built up in the community, until an issue report three years ago finally gave us a way to consistently reproduce the crash and investigate it properly.

• Use a completed savefile to unlock Mission Select
• Play the fifth mission on any difficulty
• Go through the stage normally until you reach the infected Apparoid Miniboss.
• Purposefully die before finishing the section
• After you respawn, simply play until you get to the miniboss a second time

Being able to reproduce the issue allowed developers to get a better idea what was going on. Through the error messages and simple debugging, we could see that Star Fox: Assault was causing the emulated GPU to try to access out of bounds memory (memory addresses outside the physical memory the GC has). Simply disallowing Dolphin to read out of bounds memory did fix the crash, but didn't exactly answer the key questions.

What exactly was the game doing to generate a bad command? Did the command occur on console, or was it a fault of bad emulation? If this command was sent on console, why didn't the GameCube or Wii crash as well? We didn't know, but that's why we have booto to hardware test bugs like these into oblivion.

After doing a little bit of cursory research on the crash, he began looking into the game itself. With years of expertise, he extracted the game's executable from the disc and statically analyzed it, wanting to figure out if the game had the capability to generating the address Dolphin was crashing on. He found code in the executable that generated the display list, which can be thought of as a list of commands for the GPU to render, and learned that the game was removing the higher bits. Due to this, the game couldn't generate the address Dolphin was crashing on, leading him to believe that Dolphin itself was behaving poorly.

So next, he wanted to find out where the bad address was actually coming from. booto used Visual Studio's memory breakpoint feature and set up a tester to go through a myriad of rigorous tests. Together, they went through stage five using Dolphin's interpreter with a memory breakpoint active, carefully monitoring what was being written to the afflicted addresses. This was an incredibly slow and arduous process, as in these conditions, Dolphin was running at seconds per frame. Even using a savestate ten frames before the crash, individual runs would take minutes.

These tests allowed booto to learn more about the game and what it was doing. After a dozen runs, he was able to even predict where the bad value was going to be written to memory before it would happen. Because of that, they were able to watch that address and just wait. When it hit, booto traced where in the game's executable that command was being generated from.

Remember how we said above that the game couldn't generate the address Dolphin was crashing on? Well, that was only half true. When examining the executable with this new information on hand, booto found a second place where the game could generate the display list. And on this particular version of the code, they forgot to mask off the upper bits! The long hunt had come to an immediate conclusion - the invalid memory access was not caused by an emulator bug, but the game itself!

For the final act, all that had to be done was to find out why this access didn't cause the game to crash on hardware. In order to test this, booto corrupted a simple graphics homebrew and feed it various bogus base addresses to see how hardware acted, including the one present in Star Fox: Assault.

booto determined that the top 6 bits of physical address get discarded by the GameCube GPU, meaning that the memory addresses written to the display list don't necessarily match what the CPU sent in certain cases! This is actually a behavior we've observed in other parts of the GameCube, such as MMIO registers.

If we look at the address that Star Fox: Assault was sending to the GPU, 0xe141007c, we can plainly see that it's out of range of physical memory. The GameCube only has 24MB of RAM, which gives it only 0x01800000 of address space. Thus, any reads of physical memory have to fall within 0x00000000 and 0x01800000. 0xe141007c is nearly 3.5GB of the way through the address space! If the GPU were to actually try to read that address, it would result in undeterminable issues. By attempting to send the GameCube GPU addresses in that range, we were able to determine what address the GPU actually uses.

To get the address that the GPU really read, the first thing we need to do is translate it to binary. 0xe141007c comes out to 111000010100000100000000000001111100. Now here comes the interesting part, the GPU doesn't store this full address. Because the GameCube only has 24MB of memory, the GPU doesn't bother storing top six bits as it'd never need to access addresses that far up in the range. Thus, the 111000 in the address becomes 000000. Converting the new binary back to hexadecimal gives us 0x0141007c, which happens to fall into MEM1's 24MB. This seems to actually be a bug in the game itself, but one that went unnoticed due to hardware behavior.

As an added note, Broadway (Wii) is actually different than Flipper (GC) in this particular case. Because the Wii has more memory the GPU only discards the top three bits of the address to the GPU. We actually can't say for sure what the Wii does in compatibility mode though, as the address in Star Fox: Assault starts with 111000, so it doesn't end up mattering that bits 4, 5, and 6 aren't cleared. Otherwise, Nintendo might have had a bit of an issue.

Thanks to all of these hardware tests, Dolphin now correctly handles all of these cases. All of Star Fox: Assault's known crash issues no longer occur. Unfortunately, this is very unlikely to affect any other game, but, if you've seen the unknown pointer issue crop up in the past, there's just a tiny chance that another developer made the same mistake.

Note: We're aware that some portions of this explanation have been simplified. The existence of memory mirrors and specialized memory locations such as the locked dcache have been omitted but were taken into account when doing hardware testing.

Last Month's Contributors...¶

Special thanks to all of the contributors that incremented Dolphin from 5.0-10117 through to 5.0-10411!