Sometimes the introductions to the Progress Reports are the hardest part to write. The Dolphin Blog has been running for many years, and we've gone through hundreds of changes that affect thousands of titles. We've gone into detail on all kinds of games, from top sellers on the consoles to obscure titles that most of us wouldn't have known existed if not for some random bug report. Despite all of these exciting changes, despite seemingly seeing it all over the years, we still see things that amaze us. The GameCube and Wii library still have a few tricks up their sleeves and developers continue to come up with crazy new optimizations and features that keep pushing Dolphin forward.
It's hard to express how happy we are to not only be writing these articles, but still have interesting things to write about. In fact, we were working on a feature article spotlighting some new features, but things were unfortunately delayed. As such, this month's Progress Report is a little hurried. What exactly got delayed? Well, we'll have more on that later this month. For now... please enjoy this slightly belated Dolphin Progress Report!
5.0-13288 - Make Free Look a Proper Controller, Move to Separate UI and 5.0-13958 - Expand Free Look Input Bindings Support by iwubcode¶
iwubcode has continued their ongoing mission to expand the capabilities of Free Look. This Report we have two changes that combine to allow unprecedented flexibility with how users manipulate the Free Look camera! First up is 5.0-13288. This change centralizes the Free Look options and provides a dedicated device for controlling Free Look. This makes it easier than ever to configure and utilize Free Look in whatever way you wish.
The next change makes things even more interesting. Thanks to previous hotkey improvements, it has been possible to map several of Free Looks buttons to a controller or other device. However, Free Look camera rotation was stubbornly still exclusive to the mouse, with no ability remap it whatsoever. Not anymore! With 5.0-13958, all Free Look controls can be configured, including rotation! With this new flexibility, you can control Free Look with any device you want, in any way you want. Want to control Free Look entirely with a controller? You can! Want to control Free Look with a fancy 3D control device? You can do that too! This also opens Free Look to situations where it just was not accessible before, such as laptops without dedicated mouse buttons.
Thanks to the Motion Input system, you can even control the Free Look camera with your controller's gyros if you want! It is not practical and kind of awkward to use, but still, you can.
If you want to use a gyro to control the camera, we recommend configuring it so a button needs to be pressed for the gyro to be active. You can just borrow the syntax from the default mouse and keyboard controls to make it easy. Here is an example config from our testing.
In order to access Dolphin's per-game configuration settings, a title needs to have a GameID. Thankfully, most released games on the Nintendo GameCube and Wii have a unique GameID. There are some rather annoying exceptions, but these cases don't come into play for typical users.
However, simple executable files designed for the console (.elf and .dol) don't have such infrastructure. Almost all homebrew and mods are these executable files, so it has been difficult for them to get the settings they need in Dolphin. This made things harder on both users and homebrew/mod developers who want to support Dolphin.
In order to make things easier, cbartondock has added an automated way to generate IDs for homebrew based on the name of the executable. For instance, if you want to have custom settings for "tetrisNtsc.dol" you can just right click it in the gamelist and go to the editor tab and add settings. This way you can use non-default settings that might be advantageous to the homebrew without having to adjust your global settings every time you run it.
Note that this does not work for titles that need to be booted by "The Homebrew Channel" as homebrew booted by the homebrew channel will inherit the Homebrew Channel's GameID. This is only for homebrew booted directly from Dolphin.
This batch of changes makes things slower. Now wait! Before you take up pitchforks, we must note that this doesn't affect raw performance. Rather, these changes deal with NAND and launch timings, particularly for Wii titles. The problem that actually spurred these changes is rather interesting. Namely the "You will need the Classic Controller" text in The Legend of Zelda: Ocarina of Time (VC) faded out far too fast. This made it so Dolphin could not be used for randomizer races, since it saved roughly ten seconds on every single reset.
What could be causing this, we wondered? Could it be more CPU timing issues, like the crashes that once plagued Virtual Console titles in Dolphin? Could it be a bug in Dolphin's CPU emulation causing a timer not to work? After several years of the issue remaining on the backburner, we got the lead we needed from flagrama. They were poking at the issue separate from us and noted that cIOSes that modified older IOSes actually caused the text to fade out faster. We spent some time looking at the issue and eventually Leoetlino found the problem: we were simply loading the game too fast from the NAND. But Dolphin has File System timings, right? Yes, except the timings weren't implemented for when a game accessed the NAND through Eticket-Service (ES). But simply fixing that wasn't enough, Dolphin also only had a single timing model, when in reality flagrama's testing made it obvious that Nintendo optimized things in later IOSes!
In order to implement the correct timings for The Legend of Zelda: Ocarina of Time (VC), we needed to make sure that each IOS had the correct timing model applied for it. In order to do this, Leoetlino wrote a suite of tests for timing different NAND reads from different IOSes. Using these models, he implemented proper file system timings for older IOS versions into Dolphin. As well, because Dolphin was still slightly faster when booting, he also implemented boot timings from ES_Launch. With all of these together, flagrama confirmed that Dolphin's reset timings now matched that of a real Wii!
So, if you've noticed that your favorite N64 Virtual Console game loads slower now in Dolphin, you know to blame the Ocarina of Time Randomizer community and Leoetlino. However, all of this work actually resulted in a huge mystery being solved! An obscure WiiWare title called Around the World was hopelessly broken with absolutely no leads whatsoever. After this was merged, we were shocked when someone unexpectedly reported that the game was working. We were even more surprised to see that these changes were the result of the game's behavior changing. Because of the nature of the glitches, no one would have guessed that loadtimes were the cause of this:
Now that NAND timings are here, WiiWare and Virtual Console titles might load a little bit more slowly, but the benefits far outweigh the downsides. Dolphin now perfectly matches console timings in key situations, bringing greater accuracy on anything that relies on file system timings.
While Dolphin's Software Renderer may not get the use of its other renderers, it is still used as an important reference for what things should look like; at least when it works. In this case, the software renderer is borrowing from the hardware backends as it was a bit left behind when Dolphin's hardware backends got proper Line-Width and Point-Size emulation. This fixes a few issues in the software renderer, including one that may be a bit surprising to most users!
There are also multiple graphical issues fixed throughout a variety of titles that use Line-Width/Point-Size, including but not limited to Star Wars Rogue Squadron II and III, Mega Man Network Transmission, and Super Smash Bros. Melee.
Android devices are at the edge of being useable for a lot of games. We've seen it again and again, with users hacking up builds, enabling unsafe settings, and doing everything they can to get that extra ounce of performance in order to get their favorite game to be playable. JosJuice has been working on the AArch64 JIT for several months, fixing games and adding several optimizations. However, these optimizations are small and and don't make a huge difference all at once. In their search for performance, we've noticed users going to third party builds and even closed source builds violating Dolphin's GPLv2+ License. In many cases, these builds promised huge performance gains and tons of optimizations without really explaining how or why. After doing some investigation, we found one thing in particular across almost all of these builds right in the configuration file - they disabled all of Dolphin's GPU syncing features.
This isn't some massive change to the codebase or anything special, this is just a debug feature that was in the configuration files for debugging issues with Sync on Idle Skipping. We've known that custom builds were using this setting and some users were even digging through the configuration files in official builds to turn it on there for quite some time. We were hoping that we could avoid this setting being used widespread, but that point has long passed. In order to make things easier on our users, we've decided to add the setting directly in the GUI to make it easily accessible.
This wasn't exactly what we had hoped would happen. The reason why is that Syncing on Idle Skipping is an incredibly important behavior that allows Dolphin to maintain high performance in Dualcore while maintaining some semblance of stability. Even with this syncing, games can still crash and lagspikes can cause problems. This is why many users with powerful computers will enable SyncGPU, a more stringent Dualcore syncing mode, or simply turn on Single Core mode to make things more stable.
Without syncing, you can get all kinds of crazy behaviors that will vary depending on the power of your hardware and the game that's being played. This also can result in behaviors beneficial to someone just looking to play the game at all costs. Less syncing is more performance, and the fact that the GPU and CPU threads run separately mean that a game could drop to incredibly low framerates while still running "full speed". On the other side of things, some games may instantly hang due to operations happening in the wrong order or at the wrong times.
For example, Fire Emblem: Path of Radiance is a game where we cannot detect the idle loop and thus Dualcore runs without any syncing. The game is rather stable on desktops despite this because it's fairly lightweight and will usually run full speed on reasonable devices. You could easily play through the whole game without running into any issues at all on a Core i5-3570K with a decent graphics card. Bring it onto an Android device that can't maintain full speed, and the game will do all kinds of weird things that you would have never or very rarely seen on the desktop machine. Transitions can randomly crash, polygons flicker and explode on lag spikes, and the game in general doesn't seem quite right. You can simulate this by running something intensive in the background on a modern computer to cause all kind of crazy behaviors that wouldn't happen normally.
In the end, it comes down to what you consider playable. If you're willing to live with the potential crashes, less syncing is going to be a performance boost and it can be a significant one in some games. That's why you'll be able to find GPU syncing options in the latest versions of Dolphin.
It defaults to "On Idle Skipping" as it always has, but also has the new options of Never and Always. Never is the situation described above and Always is the SyncGPU option that has been available in desktop builds for years. SyncGPU is a more stringent (and slower) GPU syncing option that can be used to make games that crash in dualcore more stable. If you do enable Never for the performance boost, just be sure to save in game often!
This is another hack added mostly for our Android users. However, this one is very small and easy to manage and brings big benefits in the games it affects. Many of Sega's Sonic titles are very particular about the depth of their in-game GUIs, and if they're even off by the slightest bit, they'll disappear. Dolphin used to struggle with this quite a bit, but it's been mostly put to rest since 2014. Unfortunately, the extensions we use in OpenGL on desktop to make this adjustment work don't exist in GLES or aren't supported by any of the driver manufacturers. While Vulkan on Android does support our current solution, Dolphin's GLES backend is competitive or even faster than Vulkan in many games. For this reason, blaahaj re-added the epsilon hack to the codepath used by Adreno and Mali GLES drivers to restore the missing GUIs.
Unlike the solution used on desktop, this epsilon hack may result in some minor flickering in some situations. The benefits outweigh the issues, as this fixes missing GUIs in Sonic Adventure DX, Sonic Unleashed, and Sonic Colors. This also fixes black screen issues in Sonic and the Black Knight.
Dev Diary - Fifo Analyzer Improvements¶
After merging the Super Mario Sunshine Debug Cube fix that was hardware verified to be correct, we quickly ran into a slew of regressions in other titles. While most of these early reports pointed to track packs made by fans for Mario Kart Wii, one particular regression occurred directly in a retail title: Super Monkey Ball. From there, we started to see missing graphics in other retail games Monster Jam: Maximum Destruction and Fire Emblem: Path of Radiance. Another fix for the debug cubes was definitely broken.
Pokechu22 dug into the regressions trying to find out what could be causing the differences. Unfortunately, Dolphin wasn't especially up to the task. One of the key features in Dolphin that track down graphical issues is the FIFO Player and Analyzer. It allows developers and users to record GPU commands and play them back while inspecting each of the commands to see exactly how the game is rendering. That isn't to say things are perfect. The FIFO analyzer wasn't documenting commands very well, making it hard for Pokechu22 to see what the games were doing. Rather than poke around in the dark, they started fixing up the FIFO analyzer!
Even with these improvements to Dolphin's FIFO analyzer, the bug so far remains a mystery and we're left with a couple of options. It would be easy enough to revert the Super Mario Sunshine Debug Cube fix. Again. However, there are less regressions this time around so we are leaving things as they are for now to see if a fix can be found. And, if this becomes some kind of blocking issue down the line, there is a known hack that could be used to force Super Mario Sunshine to render correctly without breaking the other games.