Since the release of Dolphin 4.0, things have advanced quite a bit. With compatibility rising to their highest levels yet alongside features that seemed impossible and extravagant, s have been asking about the next stable for almost a year now. For previous releases, including Dolphin 4.0, the staff mostly ceased work on new features while crashes and regressions were addressed. In the case of working toward Dolphin 5.0; there were just too many interesting and exciting features on the way to risk stalling out by asking developers to wait. So a release was delayed indefinitely.

So in mid-June, we decided to do things a little differently. Instead of slowing Dolphin down for a release, at 4.0-6727 we forked Dolphin into two branches. The development branch has continued forward as usual with all the bells and whistles without worrying about impeding the next release. Meanwhile, all commits relating to crashes, regressions, and other important fixes would not only be merged to master, but also to stable. This allowed the developers to continue developing the latest and greatest features, while still preparing a stable successor to Dolphin 4.0.

Today, we're happy to announce the first release candidate for Dolphin 5.0! Dolphin 5.0-RC is now on our s page. These builds need to be heavily tested and any bugs; crashes or regressions found in Release Candidate builds should be tagged [RC] when reported to the issue tracker. While we will be switching issue trackers later this month, we intend to transfer all issues to a new tracker to make sure the hard work of our s throughout the years doesn't disappear.

Any future release candidates will be below the development builds on the 's page.

As to be expected until Dolphin 5.0 is complete, any non-essential crash fixes and features from this point forward will not be in the final release. For the latest and greatest features, the development builds are still your best option, and the Progress Report will keep on reporting what's new. With that, please enjoy this month's notable changes!

Notable Changes¶ 39372c

¶ 6nt53

SDL (Simple DirectMedia Layer) was created to be the ultimate hardware interface system. Most hardware interfaces are very specific, such as DirectInput exclusively serving controllers and other human interface devices, but SDL does everything. Controllers and input devices, disc drives, video, audio, and more! By combining every use case into a common open source framework available on almost every operating system, SDL was envisioned as being the final hardware interface tool anyone would ever need. While that dream ended up with the usual result, SDL is still under development and has been a de facto standard on Linux for years.

Unfortunately for Dolphin, the vastness of SDL has caused a number of problems over the years, and has slowly been removed bit by bit. For example, in 4.0-1628 the SDL backend was removed from Dolphin on Windows due to numerous crash reports related to webcams. SDL was reading the webcam as a controller with thousands of buttons, crashing the emulator. While Dolphin was partially at fault for some of these issues, there comes a point where maintenance costs more than the feature is worth. Since Dolphin on OSX has not used SDL since 2011, only Linux was left. Unfortunately, Dolphin still had many issues with SDL even in its ideal environment.

Notable SDL Bugs and Issues in Dolphin

• Opening the controller menu after running a game would crash the emulator.
• Running more than one game in a session would crash the emulator.
• Running a game after opening the controller menu would crash the emulator.
• Dolphin could not respond to SIGTERM signals.
• Does not all axis on various controllers, such as the Dualshock 3/4
• Generally sporatic release schedule that doesn't align with our own generally sporatic release schedule.

None of these are outright horrible issues that couldn't be hacked around, but the base problem was that Dolphin was relying on a third party program when it really didn't need to be. phire took on the the task of writing an evdev backend that communicates more directly with Linux's controller handling. This allows project to work on features as needed and address any crashes or bugs that crop up immediately. Linux s should notice a huge rise in stability as well as some nifty new features on certain controllers. Asg the DS4 touchpad to Wiimote IR not only works, but is very useable and allows s a good alternative to the mouse.

¶ 6nt53

A long time ago during the development of the Wii Network branch it was discovered that a few games and the Wii System Menu would open multiple handles pointing to different locations of the same file. They expected that something written through one file handle could be read instantly from any other handle pointing at the same file. This worked perfectly fine on the Wii's simple operating system, but modern operating systems, such as the ones that run Dolphin, tend to break this assumption.

In order to make things stable, a work-around was implemented into the emulator to prevent problems. Dolphin would now close the file after each read/write and open it again before the next read/write. This forced the operating system to keep the multiple file handles in sync and fixes problem titles such as PokePark Wii and the Wii System Menu. At that time, no performance impact was noted.

Yet, after this commit, reports began to surface that saving was taking forever on certain computers. Despite a lot of research and testing, none of the developers could reproduce the issue and Dolphin 4.0 was released without the issue being tackled.

Earlier this month, phire actually ran into the issue. Being a developer, he refused to let this issue go to rest again and immediately began to debug. Upon looking into it, he noticed that the afflicted games were breaking their writes into small (32 byte) chunks, which when combined with the above fix was resulting in dolphin opening the file, writing 32 bytes to the end and closing it thousands of times until the full 144KB was written. This really shouldn't be a problem as modern operating systems can sustain millions of open/closes of the same file per second, even with a spinning hard drive...

Unless the computer were running anti-virus software. The real-time protection feature which most anti-virus solutions provide involves intercepting every file open call and pausing the application until the file had been scanned for viruses. Combine this with dolphin's creative workaround and a strange problem occurs. This same file ends up being scanned for viruses thousands of times, which unsurprisingly brings any computer to its knees.

Rather than forcing everyone to uninstall their anti-virus software and use Linux, phire created a new workaround which catches attempts to open the same file multiple times and only opens it once and leaves it open. This single file handle now acts exactly as the Wii software expects but the 's anti-virus software will now only scan each file once.

¶ 6nt53

When on the Wii, it's hard to notice how much the Wii will disconnect Wiimotes; any paired Wiimote will reconnect upon any button press on the Wiimote itself. That's why developers will often see complaints about Wiimotes timing out, Wiimotes being disconnected, having to manually reconnect Wiimotes, Player 2's controller not working, random Wiimote disconnects, on and on...

Dolphin doesn't communicate to Wii Remotes in the exact same manner as a real Wii. Dolphin handles all Wiimote connectivity itself, emulated or real. Even if the game disconnects the Wiimote, it remains connected to Dolphin even though the game thinks it shut it off. Unfortunately, the game has no way to know if the Wiimote is on or off; it sent the disconnect command and assumes it is disconnected, displays the disconnection notice and requires the console to send a reconnection notice to proceed. Dolphin on the otherhand assumes the Wiimote is still connected and requires you to manually disconnect and reconnect it before the game will notice it again. s just had to know to manually disconnect then reconnect the Wiimote with hotkeys whenever this happened. For experienced s, this was annoying, but for people unfamiliar with Dolphin, it was a confusing quirk that led to much frustration.

Throughout the Dolphin 4.0 era, Wii Remote has gotten easier and better. Toshiba Stack connected real Wiimotes work without issues for the most part. s can quickly and easily connect a Wiimote and play their games just as they would on a Wii. On the other hand, if they idle for more than five minutes or go through an ES_Launch, or the game decides it wants to be one player for menus in a multiplayer game, Wiimotes will get disconnected and the experience becomes more akin to how it used to be.

PAL Wii games were having trouble getting into various video modes in Dolphin, and earlier this month he brought the popular Memory Card Folder feature to PCSX2. Despite all of that, he took up the task of getting emulated Wiimotes to automatically reconnect when they were disconnected by the game.

This task turned out to be not nearly as hard as anyone imagined. The quirk was that Dolphin was already accepting input from disconnected Wiimotes, so the only challenge was to detect when the Wiimotes were being disconnected and reconnect them upon seeing button inputs. And since Real Wiimotes are always connected, it applies to them too! It doesn't work exactly as a real Wii; connected Wii Remotes will always be on regardless of what the game displays, but now if a game disconnects a Wiimote, simply hitting any button on the Wiimote will reconnect it. No more messing with hotkeys or desynced Wiimote states. Happy waggling!

¶ 6nt53

Sometimes the actual bug isn't very hard to fix. Once it was determined what was wrong, it was a pretty simple fix; the entire commit boils down to two lines.

if (a_info->type != OPTYPE_INTEGER)  
    return false;

Yet, this was one of the most difficult bugs to track down in recent memory. Why? Let's look at the entire scenario.

Sonic Unleashed, a relatively popular title for the Wii, had started hanging at some point. The game would be running great and then it would suddenly freeze, with the music playing on as if taunting the player that things were still working fine. Bugs like these are among the hardest to catch; the game itself crashed rather than the emulator. It could be anything from a GPU/U desync, U emulation inaccuracies, save timing bugs or pretty much anything else!

Thankfully, the that reported this bug was able to narrow down the issue by quite a bit by testing options. They were able to determine that this only happened on JIT; not JITIL or Interpreter. JITIL hasn't seen the same level of optimization or completion as the JIT; so oftentimes it will fallback to interpreter and avoid various JIT bugs, making it an invaluable tool for quickly testing certain JIT bugs. Still, even with this hint, narrowing down the issue was a huge task that was going to take some serious time and dedication.

When it comes to mind-numbing testing, JMC47 is usually called upon to do the dirty work. He, unfortunately, had no idea what he was getting into with this issue. His initial job was to go through and find out what U instruction was causing the crash; as that's normally what happens in this case. After several hours of testing the bug at five to 15 minutes per bisect step, he was unable to determine a culprit and returned with his hands empty. Thankfully, phire had another idea as to what would cause something like this.

Like what was said earlier, Dolphin's JIT is more complete than its JITIL; it emulates more instructions and has more optimizations. But it also has a few things beyond that. There are special optimizations implemented through the PPCAnalyst that allow things to be optimized further. Disabling these special optimizations made Sonic Unleashed about 20% slower, but suddenly the crashes stopped. Simply disabling the optimizations for the game would have been an easy fix, but phire wanted to find the actual bug and fix it, especially since it could cause issues in other games. Fortuitously, this would be proven true.

And so, JMC47 was sent on a second journey of bisecting through instructions, this time disabling instructions from using a specific PPCAnalyst optimization called branch merging. After two days of bisecting (and over 14 hours of testing Sonic Unleashed!) he came to the conclusion that the problem was caused by a PPC instruction for floating point addition. After a 90 minute session in-game with zero hangs, the results were confidently brought back to phire where they were immediately refuted. Phire contested that there was no way that this could cause the issue despite the hangs being worked around. In order to debug it further, he added in even more debug logs and had JMC47 do even more bisecting on the issue. This time, they were looking at what instruction sets were being optimized to figure out if any of the combinations could be remotely dangerous.

It was a lot of instructions (scrollable)

While going through the gargantuan list, phire noticed a potential problem at long last. While Floating CoMPare Ordered (fcmpo) and Floating CoMPare Unordered (fcmpu) were blocked from being reordered into the second slot, they could be reordered into the first slot. Because these two instructions can raise interrupts, reordering them at all is not safe and will cause issues. Once this oversight was taken care of, the crashes in Sonic Unleashed ceased without a huge loss in performance. Thanks to phire's hard work in truly fixing the bug, a second game was discovered days later to be affected the same way, Resident Evil: The Darkside Chronicles.

¶ 6nt53

Last month saw the addition of Partial Texture Updates, finally allowing coins in New Super Mario Bros. Wii to rotate with Store EFB Copies to Texture Only for the first time.

But for some people, that was simply not enough. Tinob put his graphics expertise to work and quickly implemented additional features for partial texture updates to higher internal resolutions. Now all of the coins and dynamic objects that would previous render at native resolution and be displayed at whatever insane settings the desires. 1080p? Absolutely! 2K? Sure. 4K? If you really need to. 5K? You do realize this is a Wii game, right?

¶ 6nt53

Virtual and Real External FrameBuffer (XFB) are accuracy options within Dolphin that aren't needed for many games. A quick summary is that the XFB is an area of main memory where a field of output is prepared before being sent to the display device. The Embedded FrameBuffer (EFB) is an area of memory local to the GPU where 99% of field rendering occurs. The Video Interface, which is responsible for sending a field to a display device, cannot access the EFB but can access main memory where XFB is stored. Because most games tend to do all of the work within the EFB, Dolphin's setting of "Disable External FrameBuffer" lets a field be copied to the display device directly from EFB. This completely byes the extra copy to main memory yet produces an indistinguishable result in most games.

Real XFB is the most accurate way to emulate XFB in Dolphin, but has the downside of being locked to 1x internal resolution output, much like EFB Copies stored to RAM. Still, these accuracy options are around because they emulate a part of the GameCube and Wii, even if most commercial titles don't use them for much. Several games output videos, loading screen animations, or occasionally games like Chicken Little: Ace in Action write everything to the XFB; meaning you see nothing without it!

As such, it's extremely important for these accuracy options to be, well, accurate when they're needed. Unfortunately, RealXFB was breaking in very strange ways in quite a few games while no XFB emulation was bying the bug altogether. Animal Crossing, Nintendo Puzzle Collection, and others were suffering from strange issues once XFB emulation was enabled.

Because these games were seemingly fine without XFB emulation, there wasn't really much motivation to fix this bug. In the end, this bug was inadvertently discovered while working on another bug, so let's change gears to a more apparent problem that was discovered.

Sega Genesis/Megadrive Virtual Console games were very hit and miss in Dolphin. It seemed as though certain titles were doing something strange that was causing Dolphin to output garbage with disabled XFB. Turn on Real XFB and Dolphin outright crashes! As this is something that should never, ever happen, booto's love of accuracy finally got the best of him and he looked into the bug.

As can clearly be seen above, Sonic & Knuckles was absolutely not playable without XFB, and since the game crashed when XFB was enabled making it completely unplayable. In fact, most Megadrive/Genesis games were similarly affected; making it the least compatible Virtual Console system remaining in Dolphin. As booto looked into the bug, he came to a startling realization. Each frame was actually constructed of TWO EFB to XFB copies, each with their own stride (which Dolphin promptly was ignoring.) The combination of ignoring the stride and only using the second EFB to XFB copy resulted in the image above - a tiny sliver filling the entire screen! Once this was discovered, it was only a matter of time before the missing feature was implemented.

that odd behavior mentioned earlier? Yeah, it's unrelated to Sonic and Knuckles, but while implementing this fix, another bug was discovered dormant within Dolphin's XFB code. Lo and behold! Animal Crossing and Nintendo Puzzle Collection now render at the correct aspect ratio when RealXFB is turned on.

As to be expected from booto, he doesn't seem to leave any stone unturned. Looming in the distance are even bigger changes XFB that will push it much closer to perfection.

¶ 6nt53

Considering the NVIDIA SHIELD TV running Android TV has the most powerful Android internals available, making an UI for it was a top priority. sigmabeta went above and beyond in creating a slick UI with tons of bells and whistles waiting for s. While it is not complete yet, it is already a very fluid and functional interface. Check it out for yourself!

The New Android TV UI on the Nvidia SHIELD Android TV

¶ 6nt53

Most emulators these days are spoiled with controllers. The NES/SNES-based control scheme has been standard for so long, many emulators can actually preconfigure controllers so you can just plug in any modern controller and it will immediately have a 1:1 reproduction! Dolphin has never had that luxury. Even the simple GameCube controller rearranged the face buttons and has unique clickable triggers. But that is a piece of cake compared to the Wii Remote. With a completely unique layout, motion controls, IR pointer, multiple orientations, and accessory , the Wii Remote remains one of the most unique controllers of any modern major console. Dolphin's primary solution to this problem is fairly novel: don't emulate it! The main strategy for good Wii Remote emulation is to use a real Wiimote. If you don't have one or a sensor bar, there is an emulated approximation that works in many titles.

But for all its time booting games, Dolphin on Android has never had Wii Remote . Ever since Android 4.2.1 Wii Remotes will no longer pair with Android, so Real Wiimote is impossible. Emulated Wiimote is an option, but the complexities of it on mobile devices have left the developers in knots trying to figure out how to implement it.

For example, consider an emulated Wiimote on a phone. Most games that rely on the pointer rely on it being always active, like a mouse. Touch to point works, but the s finger would have to be on the screen the whole time, blocking the game’s graphics. And how exactly would someone touch the screen for the pointer while using onscreen buttons? Motion controls should be easy right, since phones have accelerometers? But the Wiimote is designed for big movements. Do you really want to swing your $600 phone through the air as hard as you can, all while you take the train to work? And how do you look at the screen while flinging it about?

With all of these complexities no one really wanted to tackle the issue, and when even GameCube games were barely playable, there was no reason to. Now that games are near fullspeed on some devices, sigmabeta decided to give Wii remote a jumpstart and added some of the basic components of Wiimote emulation and a controller configuration GUI. There is no onscreen button , no extension (nunchuk or classic controller), no motion controls, or anything fancy yet, just asg wiimote buttons to a controller. But even that makes many Wii games playable for the first time!

New Super Mario Bros. Wii on the Tegra X1

Without screen recording, the NVIDIA TV actually runs New Super Mario Bros. Wii about fullspeed aside from a few minor drops. With a few more optimizations, it may run fullspeed without issues at all soon!

¶ 6nt53

Most s stay as far away from the interpreter as they possibly can. Interpreters are an extremely slow, platform independent way to emulate a U, and most emulators start with one before developing a recompiler (JIT). Dolphin's U interpreter, unlike most emulators, is really too slow to be of much use to s. The PowerPC powering the Wii and GameCube is a lot more powerful than the processors emulated by most current emulators meaning that a fast interpreter is just that much harder.

In an effort to make a faster interpreter, degasus used the JIT interface and made it output machine independent code. This new U backend caches the list of interpreted commands and executes them afterwards; hence its name of Cached Interpreter. Because it outputs machine independent code, it can run on any computer capable of running Dolphin, including architectures that Dolphin no longer officially s, like x86-32 and ARMv7. Don't get too excited, though, it's only about two to five times faster than the interpreter. Only on the fastest of existing processors would any games approach playability, and JIT/JITIL will always be much faster. In truth, it's more or less an experimental backend to make bisecting and working around JIT issues a bit easier. That doesn't mean a little fun can't be had, though!

Cached Interpreter Performance Preview

¶ 6nt53

In another one of those "Finally!" features, phire has implemented a heuristic for Dolphin that allows it to detect when GameCube games switch between 4:3 and 16:9 widescreen. Popular games like F-Zero GX, Tony Hawk (series), Star Fox Adventures, Super Mario Strikers, and tons more have built-in for 16:9 widescreen output, but until now it's required s to manually override Dolphin's aspect ratio in order to use it. Many TVs require that too! With this enhancement, Dolphin will now detect when games switch between 4:3 and 16:9, allowing s to get the most out of their games without needing to touch the graphics configuration whatsoever. A neat quirk is that it also detects widescreen codes, such as the Wind Waker 16:9 code! It will even switch back into 4:3 in the pause menu where it would normally just be stretched, then back to 16:9 when unpausing!

, unlike Wii games where the system settings handle widescreen, GameCube games that widescreen need to have the widescreen option enabled in the games' options. As such, this change is disabled for Wii titles, despite games like Super Smash Bros. Brawl allowing players to change the aspect ratio ingame. This is to ensure there are no false positives that cause troubles for s unnecessarily.

¶ 6nt53

For all of Dolphin's 12 years of emulation, an assumption has been a central part of how it displays games - it assumed games were either 4:3 or 16:9. This allowed Dolphin to avoid the nightmarish reality of digital to analog conversion. As the emulator continues to march forward, smaller and smaller issues tend to come to the forefront, and s began to notice that things weren't quite right in certain games.

Subtle issues like this were unfortunately fairly common. Thankfully, most s wouldn't notice these small inaccuracies. It would never be a big issue unless some evil game were to render an absolutely insane aspect ratio. This scenario could only come from an extremely competent developer mimicking the look of a movie...

Thanks to the work of Progress Report newcomer mirrorbender, now Dolphin renders at the same aspect ratio as the console. However there is a slight side-effect. Since Dolphin no longer assumes 4:3 or 16:9 aspect ratios, if a game renders at some other aspect ratio there will be black bars on the side of the screen, possibly even in certain widescreen games. To address this, Dolphin's Crop function (Graphics > Advanced tab > Crop) has been tuned to crop down to 4:3 or 16:9 without losing any important data. This allows s to not only avoid black bars, but still get the benefits of the correct aspect ratio.

Because of the extreme complexity of this issue, a full blog post will be coming later to explain all of the technical details.

Last Month's Contributors...¶ 2v561r

Special thanks to 4.0-7141!