Since the Dolphin 5.0 release, Dolphin has had opt-in usage statistics reporting to help us determine what hardware and builds users are using. Recently, this feature was also added to Dolphin Android, letting us see that around 10% of our users on development builds are using the Android version of Dolphin. Obviously, Dolphin on Android isn't going to be a perfect experience for quite some time, but in the meantime we will continue to add features and try to make the Android experience as clean as possible, even if the hardware is going to struggle with emulating GameCube and Wii games.

As a part of that, a lot of the major GUI features from the desktop version of Dolphin have been ported over. Just this year, we've seen important features like INI support, INI configuration, auto-update support, and even statistics reporting. Unfortunately, trying to bring the desktop experience to phones has caused some confusion that would seem like second nature to desktop users. Savestates in Dolphin are not compatible between builds and a lot of phone users that had been solely relying on savestates were in for a rude awakening during the next auto-update.

An unfortunate series of events lead to some deserved negative reviews on the Appstore and other mediums. With the brand-new auto-update feature came a bunch of broken savestates for users with no warning whatsoever. Unlike the desktop builds, savestates are immediately available directly from the context menu during emulation without any warnings or other information. Regardless of auto-update, relying solely on savestates for your progress is a risky proposition and we highly recommend using in-game saves as a more permanent way to save your game.





"Updated without warning and my save states were completely lost. The game's save function broke, so those were the only saves I had. For a GameCube emulator on Android it was working really well, but losing all my progress because they couldn't make old save states work with the update was really disappointing." -- User review on the Dolphin App within the Google Play Store





Dolphin's design doesn't really allow for savestates to work between different builds safely, so we were left with a difficult decision. Users randomly losing their save data is not acceptable, but removing savestates on Android would be awful. So as a compromise, we've added an option to enable savestates in the configuration menu, with an explanation of how they are intended to be used so users can understand the risks. We're sorry to anyone who ran into issues in the meantime, but as Dolphin on Android becomes a more legitimate option in the future, we're likely to run into more of these growing pains. All we can do is ask users to be patient and continue to report issues as we go forward.

Now that we've got that out of the way, there's plenty of other notable changes to get through this month so let's start chewing through them!

Notable Changes¶

5.0-8746, 5.0-8968, and 8977 - Android Emulated Controller Enhancements by zackhow¶

We promise not everything this month will be about Android, but considering there are so many missing features, there's still quite a few things being added. Possibly the most notable issue that every single user playing on their phone has noticed is that there was no rumble support unless you were taking advantage of native GameCube controller adapter support. Even though there were no complaints about this, we assumed that their subconscious frustration must have been causing many of the negative reviews and responses regarding the emulator.

Upon realizing this injustice, zackhow lept into action and rectified this egregious oversight. Now Dolphin can vibrate your phone as a way of emulating controller rumble. This makes Mario Party 4's minigames which utilize rumble finally playable on phone touchscreens along with other games that require rumble. In addition, standard controllers that support rumble can also use their rumble capabilities if you're not a fan of using touchscreen controls.

Now you can finally test rumble on the go!

While this is confirmed to work on Xbox 360 controllers, many other controllers that do support rumble doesn't seem to rumble yet for unknown reasons. Perhaps even more importantly, Dolphin now supports per-game controller configurations on Android. This allows you to set custom touchscreen layouts, custom controller layouts, and more on a per-game basis to help control you tune your controls for every individual challenge!

5.0-8783 and 5.0-8900 - Fix Hybrid XFB Texture Cache Issues by AdmiralCurtiss¶

Hybrid XFB has become one of the more lauded features added to Dolphin in recent memory. It greatly reduced the performance requirements of many games while allowing CPU rendered FMVs to show without being locked to native resolution. As with any major rewrite, there have been quite a few regressions since the initial merging of the feature. While most of those have already been handled, a few known regressions have hung on. The first of these only happens with Store XFB Copies to Texture, but despite this the regression was dangerous enough that it was seen as something important to get fixed. Metal Gear Solid: The Twin Snakes was flickering at 120Hz during certain cutscenes where an older XFB copies were used for a blurring effect. Unfortunately, Dolphin had already invalidated those textures, causing the default magenta to render over the screen.

We'd show the flickering here, but we don't want to give people seizures In-between the magenta lightshow you'd occasionally see valid frames.

AdmiralCurtiss stepped up to prevent this particular visual anomaly from appearing. Odds are Metal Gear Solid: The Twin Snakes isn't the only game that did this, so if you were having problems with a game flickering magenta, it should be fixed now. If it is not, please report it on our forums or issue tracker.

But what if a game wasn't flickering magenta, but was instead flickering an old XFB copy? That should be impossible, but Factor 5 once again defied all expectations and managed to muck things up with Star Wars Rogue Squadron II and III's multi-XFB copy pause screens. Since the merging of Hybrid XFB, if you paused in-game the bottom third of the screen would flicker ancient XFB copies!

How could an XFB copy that is minutes old not be invalidated? This is how the pause screen is supposed to look.

Because old XFB copies are invalidated, it really doesn't make sense that it can pull such an old XFB copy. This behavior was interesting enough that, after having dealt with Hybrid XFB issues in Twin Snakes, AdmiralCurtiss decided to look into this baffling edgecase, and managed to crack the code.

In the image above, the bottom half of the screen is from the last frame of Rogue Leader's widescreen cutscenes, which use a 21:9 aspect ratio to mimick the look of the films. When the cutscene ends (or you skip it) the game switches back to its standard output mode and changes the location that it writes XFB copies. In-game, Rogue Squadron II only outputs a single XFB copy per-frame, so Dolphin can just take it directly from the cache when outputting. At this point there is no visual bug... until you pause.

When you pause, the XFB copy method is switched yet again. This time, it's outputting multiple XFB copies per-frame as part of its process for anti-aliasing, and writing XFB copies to two different locations. And here's where the magic happens - between these two locations is the old cutscene XFB copy still in memory. When Dolphin goes to stitch all the XFB copies onto the screen, it sees the old XFB copy in the middle and stitches it in as if nothing is wrong!

Dolphin doesn't realize that the cutscene XFB Copy has been partially overwritten and displays the copies in the order they appear in memory. The game actually expects to render the XFB copies in the order they were created, not the order they appear in memory.

AdmiralCurtiss worked around this annoying edgecase by invalidating the partially overwritten XFB copies. Do note that this still isn't exactly what would happen on console, but it should prevent issues like these from ever cropping up in retail titles again without any regressions.

If you have a gigantic gamelist, it can be a bit daunting to go through and find whatever game you were last playing. What if you could tag games that you were currently playing, or tag other games as beaten or completed? Spycrab0 gives you the power to do just that with the new tagging system for Dolphin's Qt frontend.

Organize your games how you want them with Dolphin's robust tagging system.

Along with the tagging system comes the new tag column. When you click that, it will sort your games by their current tag. This can be particularly useful if you have multiple versions of a romhack, such as the Paper Mario: The Thousand Year Door Shufflizer, so you don't end up continuing your run on the wrong game. You can also give games multiple tags for if you need more something more specific.

A few months ago, Leoetlino changed Bluetooth Passthrough to use packets that were of the correct size with no padding. This worked fine on Wii Bluetooth Adapters hooked up to PCs and the change was merged. Unfortunately, when unleashed into development builds, a lot of users reported that Bluetooth Passthrough was suddenly broken on their generic Bluetooth Adapters. Considering that getting a Wii Bluetooth Adapter hooked up to a PC can be a bit challenging, we've decided to go back to the old behavior as there aren't really any downsides other than it being slightly different.

The fastest video backend.

The Null Backend mostly exists for developers to narrow down bottlenecks and see the true potential for how fast a game can run without driver overhead. Unfortunately, if you selected Null Backend, especially on Android, you could end up creating cached shaders that were incompatible with the other backends. This meant that a simple performance test in the Null Backend would result in Dolphin no longer able to run the game without crashing!

In order to rectify this, Stenzek now explicitly prevents the Null Backend from using/creating shaders that it is never going to render anyway.

Despite adding a bunch of portrait mode fixes just a month ago, we've decided to make the decision to disable Portrait mode by default in Dolphin on Android. After looking at the situation closely, there really wasn't much reason not to do this. On most phones, rotating into portrait mode makes the game screen extremely small and also makes Dolphin's touchscreen controls rather awkward to use. We expect users on phones to have a much cleaner experience with this change - and as a bonus you won't have to worry about turning your phone ever so slightly potentially crashing Dolphin. For users who absolutely need portrait mode, this can be overridden in the options menu. Because of all of the reasons stated above, we recommend you do not do this unless it is absolutely necessary.

Despite disabling it by default, zackhow also made some enhancements to Portrait Mode for those that still wish to use it.

The old way of putting the screen in the middle meant that your controls would still get in the way even with all the empty space. By moving the screen up, it's now easier to configure your controls in Portrait Mode if you still want to use it.

Other fixes have been done to make Portrait Mode more usable as well, including make it so your controls don't drift off-screen when rotating between Portrait and Landscape view. Regardless of that, we do recommend users do not flip between modes as it does put extra strain on both Dolphin and drivers. If something goes wrong, it can cause graphical corruption or even crash the emulator outright.

As a general user emulator, performance matters for Dolphin. While we try to be as accurate as possible when we can, maintaining a smooth framerate is incredibly important for a good user experience. Over the years, many performance regressions have snuck into Dolphin, some intended while many others were unintended. While we have testers looking out for things, it isn't reasonable for us to catch everything before a feature gets merged.

delroth, the architect of Dolphin's usage statistics reporting, website admin, audio rewriter, Wind Waker heat hazer fixer and much, much more returned to implement an ambitious addition to Dolphin's optional telemetry service. As of this build, Dolphin can now report back how the game is performing every fifteen minutes. This will not impact performance and uses existing functionality in Dolphin. Only now it will also report how fast the game is running and how fast it could potentially be running based on how much idle-time remains. With this performance factor measurement, 1.0 is full speed, 2.0 means that you could potentially run the game twice as fast, 0.5 means half speed, and so on. Without further ado, here's a graph of collected data from the past few days.

The results above have to be taken with some reservations. The current data is taken from a very small sample and is subject to change. We don't expect SD845 phones to remain slower than SD835 phones in Super Smash Bros. Melee, but with the current governor situation in various phones, it's definitely reasonable to expect that some SD835 device users are having a much better experience than some SD845 users.

Also note that we heavily curated the results to only show configurations with multiple unique users. This is just a cautionary step to protect the privacy of the users that have opted into data collection. As a consquence, the displayed data is skewed toward laptops and phones, which are more likely to share the same exact hardware configuration than a custom built desktop. It's also important to remember that different parts of the game are going to be more or less demanding than others. While Dolphin has a heuristic to weed out reports from menus/FMVs to prevent biased results from further skewing the data, there will still be a lot of variation with the small number of results we have. Moving forward, this will allow us to keep track of how performance is shifting across devices and identify performance regressions without the need for bug reports. And with more data, we could even think about features like possibly telling you how well your computer can run a game before you go to the trouble of dumping it!

Dolphin ran into a rather unfortunate problem with Gecko Codes a while back that left things in a rather precarious position. Many Gecko Codes relied on PowerPC cache eviction in order to work correctly, something that Dolphin couldn't exactly emulate. In order to fix this issue, we modified the codehandler to automatically clear the icache for codes to work-around the problem! This fixed the malfunctioning codes... at a cost. Codesize ballooned and many codes would overflow Dolphin's JIT cache between five and 30 seconds! This would cause a long, noticable stutter that prompted users to file tons of reports on the forums and issue tracker. Part of the reason for this is that codes that didn't rely on icache behavior were also triggering these long stutters. The more codes you have, the more quickly Dolphin would have to clear the JIT cache.

While there is a correct way to fix this within Dolphin, by having a smarter JIT cache, such a fix may not happen for quite a long time. One More Try took a different approach and decided to modify the codehandler yet again. This improved improved codehandler now features the fixes for icache sensitive Gecko Codes while still not flooding Dolphin's JIT cache thanks to changes to the ASM. When a Gecko Code tries to edit a game's code in memory, we first check if the patch was already applied. This avoids repeating the patching and cache clearing on every frame. The only sacrifice made is that the Gecko Code handler is a few instructions larger, reducing the space available for the codes themselves. In practice, this means you'll be able to fit ~3 less lines of code.

Special thanks to all of the contributors that incremented Dolphin from 5.0-8713 through to 5.0-8987!



