As the twilight of the Dolphin 4.0 era approaches, code cleanup and regression hunting have become a high priority, fixing the serious and minor issues that have cropped up over the past year and a half that remain unaddressed. From remedial problems such as INI issues to Real Wiimotes issues on OS X, a lot of those important minor issues have been tackled. As if that wasn't enough, there are still exciting developments within several core features to keep users satiated in this month's Progress Report.

Notable Changes¶

4.0-6492 - Fix Multiple Real Wiimotes in OS X by flacs and endrift¶

It's no secret that Dolphin's OS X builds sometimes see the short end of the stick. It doesn't help that spotty drivers mixed with relatively low Dolphin usage means that a lot of problems crop up that are hard to debug. Add in a lack of Dolphin developers using OS X, and fixing issues can take a painfully long time. Multiple Real Wiimotes have been painfully broken in Dolphin on OS X for almost 2000 builds. And while a big problem like this was reported fairly quickly, the issue quickly became finding someone who could fix it.

Fellow emulator developer endrift, the developer of the mGBA GameBoy Advance emulator, frequents the Dolphin developer IRC. endrift uses a Mac, and was repeatedly bombarded with "can you test this Mac issue," style requests. This was the first of them. Within a few minutes of asking endrift to look over the code a solution was found. Then, to spite those who bother random emu-devs, not even a minute or two later flacs, a regular Dolphin dev, came up with the same answer while looking over the code for the regression. Together, they implemented a quick fix and verified things to be working correctly. By the next day, the months long regression had finally been quelled!

So, if the next version of mGBA is delayed, now you know it's because Dolphin has been borrowing endrift's OSXpertise.

Netplay Infrastructure Updates, 4.0-6512 - Wii Blank NAND on Netplay by comex, 4.0-6638 - Netplay Desync Detection by RachelB, 4.0-6839 - Synchronize GameCube SRAM Settings file on Netplay by AdmiralCurtiss¶

Netplay is one of Dolphin's fastest improving features. Between 4.0 and today, the feature has gone from a clunky and difficult system that usually wouldn't work for inexplicit reasons into an easy to use and fully functional netplay platform that only sometimes won't work for inexplicable reasons. Despite that, the overall stability of Dolphin's netplay has allowed it to serve for online tournaments and leagues for Super Smash Bros. Melee and Project M.

Netplay has been stable for GameCube games for some time, but extremely difficult to use for Wii games. In an effort to reach parity on netplay, two huge features were merged to make Wii Netplay more realistic for average users.

The obvious one is "Blank NAND" for Wii Netplay. This feature lets Dolphin more or less uses a dummy NAND during netplay so that users don't have to sync 512MB of Wii Memory each time just to use Wii Netplay. Before, any save differences at all, even from a desync, would force users to start over. This makes things simpler at the expense of being able to store save files. The eventual goal is to synchronize specific components of the Wii NAND's during netplay only as needed.

The next feature is a feature that no one really knew they needed until they finally tried it. RachelB's implementation of desync detection revolutionizes netplay stability be revealing that, most of the time, all of the desyncs experienced spawn from mismatched settings at the start.

Her original plan for implementing this hashed RAM and compared it among all players. While this worked, it caused a pretty significant slowdown for users. tueidj eventually suggested that instead of hashing RAM, that the emulator could just compare the timebases. This allowed there to be accurate desync checking without any noticeable cost to performance.

With this feature in hand testers quickly discovered new settings that caused desyncs, such as PAL60 causing desyncs in NTSC games! A lot of these desyncs would have been impossible to detect or attributed to other things, as the desync could appear thirty minutes into a game. Comex cleaned up the feature so it could be merged after it was left incomplete.

The third feature is confirmation on how useful desync detection is: the SRAM.raw file that GameCube games read from was actually causing desyncs. Now on netplay this file is synced in order to prevent desyncs.

Verified Wii Games Working on Netplay

1. Super Smash Bros. Brawl AND Project M
2. New Super Mario Bros. Wii
3. Mario Kart Wii
4. Dokapon Kingdom
5. Fortune Street
6. Virtual Console Titles
7. Dragon Ball Budokai (series)
8. Super Monkey Ball: Banana Blitz

And many more!

A lot of the current limitations of Wii Netplay will hopefully be addressed in the future. While Real Wiimotes on netplay may be far off, getting working saves, emulated Wiimote attachments, and other enhancements are a high priority.

4.0-6516, 4.0-6606, 4.0-6650 - Various Filesystem Fixes by comex, mimimi, and JosJuice¶

Handling INI files and cheats have been a pretty annoying task; especially for Windows users. While none of these changes individually get rid of the problems, together, they make it so users can again handle INI files with ease.

Situation One

As of recent, Dolphin has started including some gecko cheats that are known to work within the default GameINI. This allows users to know for certain that these Gecko Codes have been tested and work in the emulator.

The problem is that Dolphin would read these cheatcodes and enable the last one erroneously, regardless of what the user wanted. This meant people trying to play Brawl were stuck with an unlock everything code permanently on with no way to remove it outside of deleting the whole INI. comex quickly fixed the issue once it was finally reported five weeks after the initial bug cropped up.

Situation Two

Dolphin's GameINI files are designed to edited by whatever text editing program the user has; there are even buttons for this right in the game properties window. But for whatever reason, any time Notepad altered a GameINI that used non-ASCII characters, it would add a UTF-8 BOM (byte order mark) to the file. A BOM is a Unicode character that tells software the format of the text within the file. BOMs are not supposed to be used in UTF-8, so Dolphin didn't expect the BOM and would interpret it as an error in the file, and ignore the edited GameINI entirely. But with a simple change, Dolphin now ignores any BOMs that it sees, and users can edit GameINIs in Notepad without worry.

These changes may be small, but they represent a big step forward into making it easier for users to manipulate various settings to work with the emulator instead of being bogged down by frustrating bugs.

4.0-6676 - Remove ARMv7 Support by Sonicadvance1¶

Android Support is a pretty crazy experiment in the making. Making Dolphin, an emulator that relies on high-end graphics cards and processors, work on systems designed for serious thermal and battery life constraints has been anything but easy. Back when the project was started, ARMv7 was the latest version of the CPU architecture found in these devices, so Sonicadvance1 targeted them as the initial goal of the emulator. Much like 32-bit x86 processors, ARMv7 was replaced by a newer version, ARMv8, which has a new 64-bit ARM architecture named AArch64. For the same reasons that inhibited 32-bit on desktops, the 32-bit ARMv7 JIT was limited in what it could do, and the AArch64 JIT quickly surpassed it.

After heavy deliberation, ARMv7 was determined to not be in the future of Dolphin's Android port.

• The ARMJIT32 has been broken on all ARMv7 devices since November 2014
• Dolphin on Android crashes on load on ARMv7 devices with Android 5.0, even on previously working builds
• 32bit was not able to do most of Dolphin's JIT tricks, making JIT updates on x86_64 hard or impossible to port to ARMv7
• AArch64 will be standard very soon, and ARMv7 will be retired before it is fast enough for widespread use

Android users shouldn't despair despite the news. Dolphin's Android port is just beginning to show what potential there is in these high powered tiny devices. While the ARMv7 JIT floundered, Sonicadvance1 put all his eggs in the AArch64 basket, creating a new JIT from the ground up over the past few months. Mix that with Tegra X1 powered NVIDIA SHIELD Android TV, and even in this early state several GameCube and Wii games are able to reach full speed!

4.0-6686 - Lighting Attenuation Fixes 2 by NanoByte011¶

When the original Lighting Attenuation commit was merged a few months back, it fixed most of the lighting bugs in Mario Power Tennis. Despite all of NanoByte011's hard work, the score counter and court preview still were tremendously darkened compared to console. The issue was simple enough: there were still problems left to be solved within lighting attenuation. With these fixes applied to OpenGL, D3D and the Software Renderer in this second fix up, all of the lighting bugs in Mario Power Tennis should be closed.

Darkened models have plagued Mario Power Tennis as long as Dolphin has existed

Until now! All darkened graphics have finally been solved

4.0-6701 - Rewrite Synchronize GPU Thread by degasus¶

Dualcore is one of the best speedups available in Dolphin. By splitting the GPU thread away from the CPU thread, Dolphin is able to spread the load between cores for a massive performance improvement - so much so that it has been vital to making games playable for years. But issues with Dualcore have plagued Dolphin since the option was first presented to users. Various ideas have been presented to fix it throughout the years, one of the best being skidau's Synchronize GPU option. The main issue with it is how much of a slowdown it presents to certain problem titles. On some computers, enabling SyncGPU would make F-Zero GX slower than single core (until recently, when other optimizations again gave Dualcore the edge.) As such, this compatibility option mostly remains unused.

In order to rectify this, degasus took a fresh approach to the problem and decided that we should only sync with the games as much as they needed. All of the syncing methods Dolphin uses (including single core!) are hacks, so experimentation is required to solve this problem and end as many of the dualcore issues as possible. With his rewrite to Synchronize GPU Thread, users and developers can now specify how often Dolphin will sync the CPU/GPU thread, allowing dualcore issues to be squashed with minimal performance impact. It's pretty hacky, but dualcore itself is a pretty nasty hack itself.

Right now, the feature is being experimented on in several games known to have dualcore issues, including:

• Pokémon XD
• Metroid Prime 2
• F-Zero GX
• Skies of Arcadia Legends
• The Simpson's Game

Performance in these titles will drop slightly, but, the addition of the option should prevent instabilities and graphical glitches when playing the games in dualcore.

4.0-6704 - Optionally Emulate Accurate NaNs by flacs¶

In this episode of "Horrible, horrible things games do," it's time to look at Dragon Ball: Revenge of King Piccolo. This game is pure evil because it relies on accurately emulating Not a Number (NaN) calculations and results. Why? Because it's evil. Takes a look at what happens when things go wrong and scratch your head alongside flacs.

The game randomly will warp characters around, from enemies, bosses, and even player characters if NaNs are not emulated properly. Emulating this is a significant slowdown, so right now it is optionally enabled for all games that need it. The number of games that it was discovered to effect? Exactly one.

4.0-6736 - Add GUI Support for up to 8x Internal Resolutions by RisingFog¶

With 1440p and 4K monitors starting to reach the market alongside bigger and better graphics cards, the question has come again and again, when will Dolphin support higher resolution monitors? The truth is that the option was added all the way back in October of last year, but only for users willing to edit their settings manually through the INI files.

One of the big arguments against exposing high resolutions to the interface was the fear that users would automatically set the highest number (now 8x internal resolution) and either overheat their poor GPU or cause Dolphin to run unbearably slow. Generally, users shouldn't set the internal resolution above the resolution of their monitor. But, again and again, calls were heard out to let people set the internal resolution to whatever they want, and with high resolution monitors on the rise... here they are! With support for up to 5K monitors, Dolphin's interface is future proofed for quite a while. To help users that might be confused by the added options, the commit labeled the internal resolutions that corresponds with certain resolutions.

4.0-6741 - Use proper reset code by booto and implemented by AdmiralCurtiss¶

Sometimes things in Dolphin don't make sense. If you ask neobrain then he'd say most things in Dolphin make no sense. The reset code in Dolphin literally could not be the value that it was giving games, it was completely and unequivacably wrong. The story behind this varies and no one is sure exactly what happened, but speculation boils down to this. Until a year ago, Dolphin did not correctly emulate Eticket Service Launch (ES_Launch); fixing it was a huge deal. But before that, skidau had made some alterations to Dolphin so that ES_Launch titles would at least function to a degree. His work is why Metroid Prime Trilogy could at least boot into the sub-games until resident miracle worker magumagu somehow tamed the beast that was ES_Launch, hopefully ending those issues forever.

As far as anyone can tell, the improper reset code is a left-over from old ES_Launch experimentation or another hack. booto noticed that the reset code was improper, and AdmiralCurtiss implemented it as a Pull Request since it made a difference in something he was already working on: PAL60 titles (more on this later.)

While it wouldn't be expected for a reset code to do much, it actually fixes two major issues in the emulator, and goes a long way toward explaining a third.

• The Legend of Zelda: The Wind Waker (PAL) will now show the option to use PAL60. This likely also affects other titles with missing PAL60 support
• Phantom Brave: We Meet Again no longer freezes during the credits
• When in PAL60, Wind Waker (PAL) also will not freeze after its credits, allowing access to New Game Plus. PAL50 still hangs

All of that from a one line change of something obviously wrong in the emulator.

4.0-6775 - Fix FreeBSD by endrift¶

It's well known that Dolphin runs on several major operating systems. From Windows, OS X, Linux and even Android, we proudly support and provide builds for each of the targets. But, one of the lesser known facts is that Dolphin has supported FreeBSD for much of its open-source history. But since it isn't exactly tested and none of the developers actively use it as their main OS, support also tends to break quite a bit.

Apparently bored or possibly suffering from severe insomnia, endrift went through and fixed all of the things preventing FreeBSD from building. It can only use JITIL and not the main JIT at the moment, but OpenGL works and games are fully playable. If any FreeBSD fan wants to make our crazy JIT optimizations work on FreeBSD, the invitation is open to them!

4.0-6585 - PAL60 Wii Fixes and 4.0-6794 - Various PAL60 Tweaks by AdmiralCurtiss¶

A trend that tends to happen in emulation is that people prefer using NTSC games, thanks to their higher framerate and more common availability. Oftentimes, this means PAL region games can be neglected and suffer worse compatibility than their NTSC counterparts. AdmiralCurtiss has recently taken up the challenge of fixing some of the strange quirks that make PAL region games more difficult to play. These fixes are centered around the detection of various PAL video modes.

There were two serious problems in detecting video modes that are corrected among these commits. Let's start with the simple one first.

At least two NTSC games, including Punch-Out!!, would see PAL60 set and crash because they're confused. Disabling PAL60 for NTSC games corrects the problem.

The more serious problem that users would run into is that PAL60 detection was extremely spotty, especially in Wii games. To explain this, AdmiralCurtiss did a lot of testing with various titles that had issues and came up with a chart of how they behaved on console.

Games like Mario Party 8 only support PAL50, while The Last Story doesn't support PAL50 at all. Super Smash Bros. Brawl actively warns users NOT to use PAL50 as PAL60 looks better. Without using the System Menu, Dolphin has supported setting these options through the PAL60 and Progressive Scan toggles. Unfortunately, Dolphin is extremely inconsistent at applying the correct video mode.

During this testing, AdmiralCurtiss discovered that booting Wii games from the Wii System Menu alleviated the issue altogether. In the most awkward of ways, it was discovered that the problem wasn't that Dolphin was setting the video mode correctly, but rather that games never expected to set the video mode themselves. So when Dolphin booted up a PAL game that doesn't know how to change video modes, it started everything in PAL50 and was stuck there. In the case of Xenoblade Chronicles, users discovered that hex-editing the game to be detected as Japanese would be enough to get it to run in PAL60.

Why did no one know about these quirks before? Well, booting games from the System Menu in Dolphin only started working last summer, so it hasn't been tested all that thoroughly. Without ES_Launch support, it's possible that solving this bug would have been quite a bit harder.

NOTE: Contains excerpts and data from AdmiralCurtiss excellent report on the matter. Further technical details are here.

4.0-6860 - Partial Texture Updates by mimimi¶

If you love New Super Mario Bros. Wii, this is the commit for you. Let's go into some background about New Super Mario Bros. Wii first, to explain the situation.

New Super Mario Bros. Wii has required EFB Copies to RAM for certain graphical effects, like spinning coins, ? blocks, and blue coins to work correctly. To understand why, a bit of a technical understanding of how the game works is required.

This game is a lot like old games in that it renders mostly everything to a giant tileset! This is VERY alike how older 2D Mario games worked, so it's pretty interesting to see how classic techniques are used in a modern title. In the upper right of the tileset are things like coins, blocks and other objects that can animate. Here's where things get interesting. When using EFB Copies to RAM, Dolphin converts the texture object for the EFB Copy into the GC/Wii graphics format and puts its raw data into memory. This allows games to access the data and manipulate it. In Pokemon Snap, this is how the game can tell if a Pokemon is on screen when you take a picture. Dolphin can tell that the texture is updating from the data within the EFB Copies. On Store EFB Copies to Texture Only, this data is not stored and Dolphin never sees any updates to this giant texture, and thusly, never updates it.

When using EFB Copies to RAM, Dolphin knows that the texture is changed, but has absolutely no code to do partial updates, and thus updates the whole thing every frame. EFB Copies to Ram always drains performance, but constantly updating a 1024x1024 texture made it extremely demanding for New Super Mario Bros. Wii. A theoretical solution to this quirk has been known for years, but no one wanted to invest the time necessary to implement it since it would only affect a single game. mimimi threw that logic into the wind and dug into the implementation.

Partial texture updates makes it so Dolphin now checks if EFB copies are overlapping the memory of a texture, and if it does, the graphics from those EFB copies are drawn into the big texture at the right place. The results are staggering.

Work has already begun on expanding this feature to allow partial EFB copy to texture updates to be rendered in higher resolution, but for now the feature still has the resolution limitations of EFB to RAM.

4.0-6915 - WiimoteReal: Add IOHIDDevice support for OS X by endrift¶

When we wrote the DolphinBar Review, we mentioned that the DolphinBar works on OS X. Well... we didn't have an OS X tester with a DolphinBar, and assumed that since Mayflash said it worked on OS X, it would work with Dolphin on OS X. It turns out it didn't, and it was entirely Dolphins fault: the Real Wiimote code on OS X was only looking at the bluetooth stack, and ignored HID devices such as the DolphinBar. Whoops. Combine a lack of testers, lack of OS X developers, and OS X 10.10 breaking Real Wiimotes entirely for several months until 10.10.3 fixed it, the issue was surprisingly difficult to isolate.

After endrift fixed multiple Real Wiimotes, we realized endrift could possibly fix this, so we used the ad money to send them a DolphinBar. endrift quickly isolated the problem and one insomniac coding spree later, the problem was solved!

Last Month's Contributors...¶

Special thanks to all of the contributors that incremented Dolphin from 4.0-6486 through to 4.0-6915!