With the holiday season reaching its apex, we have a few surprises for those of you that have been patiently waiting. The latest release of Dolphin is stuffed with treats. Our first present is presentation - frame presentation, that is. Two new options have arrived and will help users both reduce latency and smooth out games that struggle with frame pacing.
Some games do outright naughty things that make emulation difficult. A slew of them are being coerced onto the nice list this year thanks to a sack full of patches that bypass their troublesome behaviors. Fans of the Broadband Adapter (BBA) have a great present tailored just to them: a new local mode BBA! Designed for allowing multiple instances of Dolphin on the same computer to connect together, it's perfect for use with Parsec or other similar services. And perhaps another gift will have you singing your favorite Wii hits?
But alas, what fun would the holiday season be if we spoiled all the gifts? Read on to unwrap the latest edition of the Dolphin Progress Report.
...
...
Huh? We've received word that apparently the Android users have made the nice list? Really? That can't be right... but this gift is addressed to them.
After more than a couple bumps in the road, RetroAchievements support has finally arrived on the Android version of Dolphin! In Release 2512, the core achievement experience is now available in your pocket. This initial version hasn't quite reached parity yet with the desktop experience, but we didn't want to hold things up any longer. The important thing for Android RetroAchievements users is that you can log in and unlock achievements in supported GameCube games. Because some menus are incomplete, it may be best to have the RetroAchievements website open in the background for achievement lists and other things while we finish up the in-app UI.
Notable Changes¶
2509-493 - Add Rush Frame Presentation and Smooth Frame Presentation Options by Billiard¶
Latency was once a huge challenge for emulators, and it is still a major concern. At one point not too long ago, it was pretty much infeasible for most emulators to match the latency of their console counterparts. Compared to a dedicated game console racing the beam on a CRT television, emulators had to deal with sluggish OS window managers with on-by-default triple-buffer V-Sync holding three frames back, first-gen wireless controllers that added latency right at the source of input, slower displays that added several additional frames of latency (much more if that display was a TV without game mode), and on top of everything the emulator still needed to do its job and take time to actually emulate everything.
Dolphin just missed out on the worst of this. By the time Dolphin's performance and compatibility were good enough for users to worry about things like latency, the overall situation had improved dramatically. Low latency and high refresh rate monitors paired with features like Exclusive Fullscreen removed most of the major bottlenecks that emulators had to fight against.
The designs of the GameCube and Wii also afford Dolphin some opportunities that other emulators don't have. The GameCube/Wii are double buffer V-Sync'd by default, resulting in a final input latency of roughly 60ms on a CRT in an optimized 60fps title. However, because of how the XFB Output Pipeline works, Dolphin has the opportunity to bypass the buffers and grab those XFB copies early, and immediately present them directly to the screen. We call this feature Immediately Present XFB, and it cuts out quite a bit of the latency present on the console.
Tricks like these let Dolphin match console latency as long as the host device is capable enough. On extremely optimal setups with low latency VRR monitors combined with Immediately Present XFB, Dolphin could even dip a frame below real console latency!
There are some caveats, though. While Immediately Present XFB is a powerful tool for reducing latency, it is also a hack that relies on games behaving in a specific manner. If a game messes with the XFB pipeline, such as if it applies post processing using the CPU, or stitches together multiple XFB Copies, the hack will cause Dolphin to output nonsensical garbage.
Even when Immediate isn't outright breaking the game, the XFB pipeline is a big part of how some games handle frame pacing, so bypassing it can make the game feel less smooth. For the best experience in many games, a user probably would prefer superior latency and good frame pacing.
And that was Billiard's goal. He saw an opportunity to improve the situation and started work on two new options. One feature was a way to reduce latency without disrupting how the game rendered, and the other would allow smoother frame pacing even in games that struggled on real console. How would he accomplish these feats? Well, by making the emulator throttle smarter.
Modern computers are powerful enough to emulate most GameCube and Wii games faster than the original hardware could run them. Disable the framelimiter and try it for yourself! To keep emulation on pace, Dolphin’s Throttle function stalls emulation to produce a mostly properly paced simulation of the original hardware. Throttling is necessary for playable emulation on modern systems, but making the host CPU wait adds time. If input from the user and stalls are aligned poorly, throttling can add a small amount of latency.
To address this, Billiard has added a new throttling mode called Rush Frame Presentation, where throttling becomes centered around presenting the frame as soon as it can after the input is read. In theory, this reduces the time between click and photon and can have a very noticeable effect, especially in lower frame rate titles. To the end user, all of this is completely invisible. All of this is happening sub-frame, so Dolphin still will throttle the appropriate amount of time to maintain the correct frame rate.
The faster your computer, the more of an effect this will have because it will be able to emulate the part of the frame faster. We can easily catch the difference in The Legend of Zelda: Wind Waker and Super Mario Sunshine by using a high speed camera, for example.
Some games will also see a further benefit by combining Immediately Present XFB with Rush Frame Presentation. Unfortunately, this combination can lead certain games to looking gnarly as they will just be spitting out the image at whatever point they're finished rendering during a frame. That's why the second new option is important.
Smoothing Things Out¶
Immediately Present XFB could already cause poor frame pacing, and now Rush Frame Presentation could make it even worse. In some games, it can get so poor that VRR monitors will fall out of their operating range!
Smooth Frame Presentation allows Dolphin to delay presentation by roughly 1-2ms so that it can more consistently output frames, using previous frame times as a heuristic. This option can be used in any game that has poor frame pacing in order to try to improve the situation.
The results of Smooth Frame Presentation are good enough that a lot of games that needed the XFB Output Pipeline enabled by default because of frame pacing issues can now take advantage of the lower input latency provided by Immediately Present XFB and Rush Frame Presentation without any noticeable side-effects.
Even if you're using neither of the latency features, some games just have bad frame pacing even on real console. Smooth Frame Presentation can help them, too. There are rare cases, especially when using Rush Frame Presentation alongside Immediately Present XFB, where a game's output will be so inconsistent that smoothing won't help. We're looking at you, Dragon Ball Z: Budokai.
Outside Verification¶
All of these results sound great, but outside of a few camera tests on lower frame rate games, we were mostly trusting latency offset numbers provided by Dolphin. Testers did also report better latency, but given that the placebo effect exists and these are such small differences, we wanted more concrete data. But other than just game feel, how do you test latency?
In the past, we've used the light sensor present on Rock Band 3 guitars alongside an in-game synchronization test to get some very rough offset values. The problem with that is that it will only ever test one game, and the guitar controller isn't particularly viable in most games outside of unusual controller runs.
Before making any claims about our latency, we wanted to do our due dilligence in respect to both Dolphin and real hardware. To accomplish this, we contacted some professionals that have been fighting against latency for quite some time. Fizzi from Slippi.gg and adapter expert Arte graciously donated their time and helped us measure latency in the latest version of Dolphin versus console. Arte specifically developed a GameCube controller adapter with a photon sensor designed to determine controller latency, which is rather convenient because that's exactly what we want to measure.
Their GameCube controller adapter polls the controller at 1000Hz, and a light sensor on it can be programmed to look for certain changes in output from the game. By having access to both the source of the input and the change on the screen, the adapter can provide a real world measurement of how exactly how long it takes for a user input to result in a change on the display - what is commonly referred to as "click to photon". As an added bonus, the adapter can also be hooked up to real console with no conversion or added latency, letting us compare directly with games running on real hardware and a CRT.
The exciting thing about these numbers is that they confirm our experience. Dolphin's latency compares favorably to console. To be fair to the GameCube, Arte's emulation setup included a modern low-latency 144Hz monitor and the lowest latency controller adapter. Dolphin couldn't quite compete with Slippi, but most of that can be attributed to deep modifications to how Super Smash Bros. Melee outputs.
For all the samples above, an input bug present in the original game has been patched out. This is to make getting consistent results a little bit easier. That fix did mean that combining Rush Frame Presentation and Immediately Present XFB no longer benefited that title when testing. However, Arte modified the test to work with other games, and some games respond incredibly well when combining Rush and Immediate.
Due to time constraints with holiday vacations, adjusting the photon sensor for different games, we weren't able to gather all of the numbers we wanted from other games. However, with Wind Waker the numbers were interesting enough that we managed to get enough samples right under the wire, at least in Dolphin. The graph above shows latency with default settings, Immediately Present XFB and the combined efforts of Immediately Present XFB and Rush Frame Presentation. Note that the default settings were measured last, and as such the error range is estimated.
The reason why we wanted to squeeze in this particular case is because it demonstrates that combining Rush Frame Presentation and Immediately Present XFB can result in lower latency than what was possible before. This is not always true, and this 10ms reduction is from an ideal example. Unmodified Melee, for instance, showed the combination reducing latency by less than 4ms. Some games saw no benefit from combining both features together.
In the end, how much these two new options will help varies greatly depending on the game and setup. Currently, we've left them both disabled by default in the Configuration -> Advanced Tab, but that may change as the settings get more testing and we gauge what users want the most.
2509-74 - GameCube - Add SDL Stock Profile by Samb¶
Unlike the wacky Wii Remote and its mess of attachments, the GameCube Controller mostly mirrors modern controllers. Sure, the sticks can't be pushed in, it's missing a shoulder button, the two stage analog+digital triggers can be tricky, and the face buttons are weird. But at the end of the day, it's a four face button, twin stick controller with a D-pad. Close enough?
So we have added an SDL Profile that players can use to speed up their GameCube controller mapping.
Using the profile is simple:
- Go the GameCube "Standard Controller" mapping window.
- Select your controller from the Device dropdown. Pick the variant that starts with "SDL".
- Select the
SDL Gamepad (Stock)Profile and click Load. - Optional: Calibrate your joysticks (please don't skip this Hall effect users!) and set up deadzone.
- Enjoy.
Since the GameCube controller doesn't map 1:1 to modern controllers, this is a best guess stock profile that will reasonably work for most people, most controllers, and most games. If a game demands a button combination that doesn't work with your hands on your controller, or if the face buttons or any other button simply aren't to your liking, you can build from the stock profile and adjust everything until it's just right.
2509-237 and 2509-339 - Add Option to Reset Settings Back to Default by JoshuaVandaele and Simonx22¶
Dolphin is a complicated emulator with a lot of options. Some of it is definitely our fault, and some of it is just the reality of trying to emulate something as complicated as the GameCube and Wii. To the average user, a lot of these settings aren't immediately obvious, even with descriptions.
"Emulated Memory this? EFB, XFB that, VBI what?"
The most experienced users (and even developers) can sometimes get frustrated enough with an issue that percussive maintenance is necessary, leading to one changing lots of settings around until something happens. Sometimes this works, leading to a temporary moment of joy, before it all comes crashing down when none of your other games will boot. Some people might be able to backtrack and figure out what went wrong, but a lot of users are left lost.
Until recently, users had to delete the Dolphin settings files from their computer to restore everything to default. No one liked that, but a button to reset settings was non-trivial thanks to Dolphin's multiple layers of settings that are a handful to manage.
Thankfully, JoshuaVandaele was finally able to sort out all of the implementation details and give us the long awaited "Reset All Settings" button.
Thanks to Simonx22, Android users also get access to this feature. It can be found in the advanced settings menu in the Android GUI.
2509-217 - GamePatch: Modify Certain Games to Behave Better in Dolphin by SuperSamus with additional contributors¶
Some games are more strenuous to emulate than others. Sometimes it's because the game pushes the console, and other times it's because the game does something annoying to emulate - maliciously or not.
The latter situation can be especially frustrating, as sometimes 99% of what the game does is fine, with just one little behavior, design decision, or sometimes even an underlying bug causing problems for Dolphin.
SuperSamus identified a few common game behaviors that causes Dolphin a lot of headaches. Properly fixing these issues would difficult, with some requiring large rewrites to the emulator that probably will never come. Fortunately, there is a simpler solution: patch out the difficult to emulate game behaviors. These small patches increase emulation performance, and sometimes even work around other unwanted behaviors.
Complex Idle Loops¶
Idle loops are a sequence of instructions that makes the CPU run laps doing nothing while it waits for something to happen. Obviously, emulating a CPU burning cycles doing nothing isn't efficient for an emulator, so one of Dolphin's earliest optimizations was the ability to detect and skip these idle loops. This feature is fairly standard among emulators and is called Idle Skipping.
Idle loops are more common than you might think. It's very rare for a game to absolutely max out the console's CPU, so for the majority of frames the CPU will idle a bit. And as long as Dolphin can detect the idle loops, they can be skipped to increase overall performance. Idle Skipping is one of the key things that make some areas of a game more demanding than others, especially on the CPU side of things. Essentially, Idle Skipping is less effective the more that the CPU has to do.
Dolphin can't detect all idle loops, and the scope of what it can find is rather limited. We have to find as many idle loops as accurately as possible while also ensuring that we don't invest too much time and resources into finding them. The more complex the heuristic is, the more of an impact it will have on the JIT. As such, some games have annoying idle loops that we know about but are not worth detecting.
Need for Speed: Nitro and Rayman Raving Rabbids are two such games with these complex idle loops. After examining their code in detail, SuperSamus realized that their idling behaviors could be modified with a patch that would allow Dolphin to more easily detect and skip them.
This results in massive performance boosts, especially in lighter areas, with some menus running at four times as fast. Of course, heavier areas see less of a benefit. We'll have a chart showing some of the raw numbers at the end.
Running Uncapped¶
Dolphin is not a cycle accurate emulator. In fact, Dolphin is fundamentally not designed to be cycle accurate, especially with GPU operations. Dolphin's emulated GPU was designed to be infinitely fast, only being limited by other factors like CPU emulation or the maximum performance of the host device. Nowadays, it has been tamed a bit with synchronization points that provide a rough approximation of the timings of the original command processor, but it is still by no means accurate, let alone cycle accurate. Also, rendering is still infinitely fast, as the only thing that limits it is the speed of your host GPU.
And yet, most games run at the correct frame rate, because they limit themselves.
The GameCube and Wii were designed for analog TVs, so they used the analog television's sign to start a new frame as a synchronization point called the Vertical Blanking Interupt (VBI). All a game had to do was start a new frame every time it saw a VBI and finish the frame before the next VBI, and it would be perfectly synchronized to the frame rate of the display. That's it. It was simple and efficient, so the vast majority of GameCube and Wii library tie their frame rates to the VBI. Thanks to that, Dolphin's early developers didn't even need to care about how fast the emulated GPU runs; as long Dolphin emits VBIs at the correct frequency, most games will just run at the correct frame rate regardless of what's going on under the hood. And this gives Dolphin bonuses like not emulating GPU slowdown, allowing games that struggled on console to perform much better in Dolphin.
But the GameCube and Wii don't have operating systems. Games run on the bare metal and have full control of the machine, so developers could do whatever they wanted. And some games eschew the VBI and run uncapped.
Uncapped games break Dolphin's assumptions. They can render way, way too fast. For example, when running Hulk (2003) in Dolphin, it only displays at 60 FPS, but the physics engine could be doing hundreds of steps per second behind the scenes. This is cool because technically a game like this can easily be hacked to run at higher frame rates, but terrible because it hammers people's devices with all kinds of unnecessary work!
It gets even worse from here. The physics engine's independence from the output frame rate isn't perfect. If the number of steps per second gets too high, small rounding and math errors start to accumulate, and parts of the game not properly tuned to run at these higher frame rates start to break. This mostly results in dialogue timing issues, but in one stage halfway through the game, it causes a physics calculation issue where a required ledge can't be climbed, essentially softlocking the player.
Some other games choose to synchronize to the VBI, but don't bother in incredibly simple scenes where the frame rate doesn't matter. This is most commonly seen with splash screens and loading screens. One such game with this behavior is Bully: Scholarship Edition. Most of the time it is perfectly stable, but because the loading screens are uncapped, it can actually cause the game to randomly hang on transitions. The Simpsons Hit & Run also has this issue, but only during the initial load. While most desktop computers are able to handle the initial load relatively well, Android users have reported tremendous slowdowns where the loading time would take more than 45 seconds.
SuperSamus identified these problems and either created patches for these behaviors themselves, or helped others with those titles create patches. Most of these patches are only one or two lines and simply limit the game's frame rate to the VBI frequency. The patches prevent the game from slamming Dolphin's overpowered emulated GPU, greatly increasing performance while fixing issues caused by the games running internally at too high of a frame rate.
This comes with a little bonus - since they are now bound to the VBI frequency, you can now use VBI Frequency Override to adjust their frame rate up or down as desired, allowing Dolphin to take advantage of the fact that these games "support" running at higher frame rates.
In addition to the games above that had emulation bugs caused by framelimiting, SuperSamus and Billiard also created limiter patches for the following games purely for performance reasons:
Somewhat ironically, by slowing down uncapped games we improve their performance in Dolphin, so when turning off Dolphin's framelimiter they go much faster. ...ignore that and use this as a measure of their performance improvement. If a game's frame rate doubled in this chart, then the performance required to run that game at fullspeed has been roughly halved.