It's the beginning of the month and time for another Dolphin Progress Report! ...That line doesn't exactly work when it's midway through the month, huh? This Progress Report ended up being a very technically challenging report to write with several huge rabbit holes that go through the history of Dolphin and the games themselves. The first rabbit hole showcases TMEM, the GameCube and Wii's texture cache. Dolphin's approach to emulating this bit of the hardware has been to effectively ignore it exists. Trying to even begin to rectify the problems with this approach and explain the reasoning behind why it sort of wasn't emulated go very, very deep. This Progress Report also contains collaboration with the PCSX2 development team as they helped us understand some of the behaviors of Floating Point Math on the PlayStation 2. The fact that the PlayStation 2's floating point behaviors mattered to us for this Progress Report should tell you the kinds of things we were up against when writing up the changes.

If that wasn't enough, Dolphin also welcomed support for a wealth of mods through support for Riivolution. An easy to use GUI for launching Riivolution mods was added both to desktop Dolphin builds and Android. Speaking of Android, users may have noticed we pushed out an early beta last month. This beta was mostly to showcase and let users on the Play Store try out the newly finished Cheat GUI! We'll finally showcase that after a lengthy delay between when that extra beta was pushed and this Progress Report. While it's not related to Dolphin directly, Apple released the new M1 Max and we got our hands on one to see how it stacks up against the M1 with some rather interesting performance numbers at the end of the report.

With that out of the way, there's no point in delaying things any further. Please enjoy these rather lengthy Notable Changes!

Notable Changes¶

5.0-15178 - Android: Update GUI for Cheat Management and Creation by JosJuice¶

Dolphin has the ability to hook in various types of cheat codes and patches, so even though the Android version lacked the GUI for it, it has always had the ability to use cheat codes. For the past couple of years, enterprising Android users have gone through the trouble of setting up cheat codes by hand through text editors or using the Desktop version to create the settings files they wanted. Some forks of Dolphin even hooked a conventional text editor into the program to try and make editing cheats easier! But all of these stopgaps weren't actual solutions, they were working around the problem. Someone had to get down and dirty and make serious additions to the Android GUI if we were to ever have a permanent solution.

JosJuice has been dealing with Android issues for quite some time, and has become more familiar with the JNI (Java Native Interface) that powers the Android GUI. Much like how DolphinQt calls into Dolphin to handle things like enabling/disabling cheats and editing GUIs, JosJuice completely replicated Dolphin's Cheat interface without duplicating the core code within Android. This means all of the same features that you already enjoy on desktop related to enabling, disabling, and adding cheats are all there, and work exactly the same!

5.0-15438 - Android: Comply with Scoped Storage Requirements by JosJuice¶

The fated day has finally come. Nearly a year ago we expressed our frustrations with the upcoming Scoped Storage requirement in Android. Since then... not much has changed about our concerns, but JosJuice has done their best in order to make sure the experience of Dolphin on Android doesn't change much. The main difference is that Dolphin is now locked to using an app-specific directory for a majority of its user files on Android 11 and up.

Unlike some other emulators, Dolphin does not have the option to simply ask for permission to use other directories. For managing things like the Wii NAND and GameCube GCI folders, Dolphin is reliant on accessing tons of files in quick order. If access to those files is too slow, the user may see noticeable lag, or in dualcore games could even crash. When using directories other than the app-specific one, performance on accessing files is terrible, so much so that it would impact emulation in a negative manner. This doesn't apply to your games however, as when using most game formats in Dolphin, you're only accessing a single file. The main culprit in Scoped Storage performance issues is dealing with many smaller files.

Using the app-specific directory may not seem like a big deal, but there are some tricky things to keep in mind. First of all, you will have an incredibly difficult time trying to copy files into the app-specific directory with the default file manager on Android 11 and up. This is problematic as things like the Wii NAND and Texture Packs need to be in the app-specific directory. The good news is, if you have a PC, you can connect your phone and navigate to the new directory (Android/data/org.dolphinemu.dolphinemu/files/) the same as the old one on most devices. Some users have reported difficulties editing these folders on certain devices, but we've been unable to verify the reports to this point. While this may be a bit frustrating, our biggest fear with Scoped Storage was that, by default, uninstalling Dolphin would delete user files including save data. Thankfully, there is a work-around to that problem provided by Android called fragile userdata. Essentially, we mark the files in Dolphin's app-specific directory as fragile, so if you uninstall Dolphin to downgrade, bisect, or do something else where you would want to reinstall it later, Android will ask you if you want to keep the App's data files. This only works when uninstalling from Android itself; if you uninstall from the Play Store you will lose all of your data.

There is one other exception we should note. Scoped Storage does not apply to you if you upgrade from an older version of Dolphin without ever uninstalling it. So if you download 5.0-15260, for example, and then just continually upgrade without ever uninstalling, then Scoped Storage won't come into effect for you until Google closes this loophole. Though going through that trouble shouldn't really be necessary as all of the known issues have already been quelled. Unless you specifically need things like custom directories for tons of Wii NANDs that cannot be within the app-specific data directory for some reason, you shouldn't see much of a difference if any with the latest builds.

For more information on if Scoped Storage affects you, please check Dolphin's Wiki.

5.0-15249 - Add broken dual source blending bug to MoltenVK on Intel GPUs by OatmealDome¶

MoltenVK was introduced to Dolphin 3 years ago, and it has since become the defacto backend for macOS users wanting to play games in Dolphin. However, it hasn't exactly been smooth sailing. In many games, such as Super Mario Galaxy, Sonic Colors, and the Paper Mario games, have considerable geometry flickering when MoltenVK is used on some Macs.

We assumed it was a MoltenVK bug and ignored it, thinking that it would be fixed eventually in a MoltenVK update. After the issue remained for three years, macOS and iOS veteran OatmealDome decided to look into this longstanding issue and sus out the source. It turns out it MoltenVK wasn't the issue at all, but Intel's macOS graphics drivers. On newer Macs with Intel Graphics, if ocol1 is present in the fragment shader and dual source blending is enabled, entire primitives will not be written to the depth buffer if any fragment is discarded. There's our flickering. Fortunately (or unfortunately), we have already experienced dual source blending issues on other drivers, so we already have a fallback path set up that only allows dual source blending when absolutely necessary. OatmealDome added Intel Graphics on macOS to the list and now the flickering is gone.

5.0-15294 - Extend Minimal TMEM Cache Implementation by phire¶

In the early years of Dolphin's life, developers were very limited in what they could do to emulate the GameCube and Wii. These consoles are quite different from PCs, and most of the tricks that today's computers can use to work around these differences simply didn't exist back then. So developers did whatever they had to, and usually that meant hacks, but sometimes that even meant not emulating something if that happened to work. Now that proper emulation is possible, for the past eight years Dolphin has been unraveling those knots, replacing hacks with better solutions as they come up. However, a lot of these old tricks still remain, especially in cases where they aren't a major source of issues and/or where the work required to replace them would be very high. And one of those such places is emulating the GameCube and Wii's texture cache - TMEM.

_SOURCE

Texture Memory (TMEM) is a 1MiB piece of super fast SRAM that lives within the consoles' GPU. Not large enough to hold a frame but much faster than going to Main Memory (10.4 GiB/s for TMEM vs 2.6 GiB/s to Main Memory), TMEM by default operates as a hardware-managed texture cache that is completely transparent to the game. In this hardware mode, TMEM sits inbetween Main Memory and the GPU and caches every 32 byte texture chunk it can, so if the GPU asks for a texture that happens to be in TMEM, TMEM will provide it instead of Main Memory and the GPU gets it much faster. There are limitations to this of course. While TMEM is HUGE for a texture cache of the period (the PS2's texture cache is 8KiB, for reference), it can still only hold so much, so texture chunks are constantly flowing in and out of the cache every frame. Also, the game can edit textures in Main Memory at any time and TMEM will never know. As such, TMEM is expecting games to explicitly order a TMEM invalidation in this event.

Dolphin ignored all of that. In fact, it ignored that the consoles even have a texture cache. Instead, Dolphin kind of replaced the TMEM's hardware mode with Dolphin's Texture Cache.

Textures straight from the GameCube or Wii will not work on modern GPUs; Dolphin needs to convert them. This takes time and processing power, so Dolphin stores converted textures in a cache on the host GPU for a long time to make the most of this work. However, this cache would balloon to enormous scale if it isn't constantly pruned as even the tiniest variation is stored as a separate texture in the cache, so Dolphin has a horrifying cacophony of heuristics to guess what textures a game will or won't use every frame. It's terrifying, and no sane Dolphin developer will even go near it.

In Dolphin, it is Dolphin's Texture Cache, not TMEM, that is sitting inbetween the GPU and Main Memory. As such, Dolphin's Texture Cache should be respecting TMEM's behaviors to be accurate. It wasn't. Instead, every draw call Dolphin simply hashed all textures in Main Memory, and if the hash didn't match, Dolphin would invalidate the cached copy. That's it. This is what Dolphin does for every texture already, so Dolphin is more or less ignoring that the consoles have their own texture cache at all. Yet for the majority of Dolphin's catalog, this is fine. As TMEM's hardware-mode texture cache is transparent to the game anyway, Dolphin could just take the texture caching job and implement it in a way that worked best for Dolphin, and everything just worked. Mostly.

Four years ago phire discovered one of the limitations of this strategy. Spyro: A Hero's Tail has a highly complex SDR bloom effect which uses 16 EFB copies to build, where it reads the screen then blurs and brightens multiple copies of what it read before stacking them all on top of eachother for scanout to the screen. As it is manipulating textures in Main Memory, the game dutifully invalidates TMEM along the way - except for one step.

In one of the stages of the process, A Hero's Tail orders the GPU to scale a texture from Main Memory up to twice the size. While performing this operation the GPU reads the texture in Main Memory, and TMEM automatically caches it. Then the game EFB copies the 2x version over the original copy in Main Memory while explicitly NOT invalidating the cached version in TMEM. The game then reads from the 1x original in TMEM to generate another texture which it writes elsewhere in Main Memory, then invalidates TMEM. This is a bit of an abuse of the GameCube hardware to help build a complex effect. Dolphin, however, couldn't do this. Dolphin's "emulation" of hardware-mode TMEM and Dolphin's Texture Cache for converted textures in Main Memory are one and the same; it ignored that the consoles have a seperate cache that may have different contents than Main Memory. If something was changed in Main Memory, the version in Dolphin's Texture Cache was automatically changed too. So in Dolphin, when Spyro overwrote the texture in Main Memory with the 2x version, Dolphin did just that, but there was no other cache that still contained the 1x version. When the game tried to read the 1x size version from TMEM, Dolphin's Texture Cache gave it the 2x version instead, breaking the bloom effect.

phire, as later cleaned up by mimimi, dealt with this by adding a backdoor that allows Dolphin to bypass the hash check if a heuristic determines it is safe to do so. With this, some changes to cached textures are allowed to occur without invalidating the cached copy as long as the texture was the same size, the same address, and no explicitly requested TMEM invalidation took place. Since Spyro: A Hero's Tail's bloom fell within that criteria, Dolphin now keeps both the 1x version of the texture and the 2x version of the texture in Dolphin's Texture Cache, allowing the bloom effect to be built correctly.

This isn't proper hardware-mode TMEM emulation, not even by a longshot. Dolphin's wildly different texture caching approach is still there - the patch essentially added a dirty heuristic to “do the right thing” in an edge case. But this was still an important step toward accurate emulation, as it broke Dolphin’s longstanding assumption that textures were always fetched directly from Main Memory and introduced basic awareness of TMEM.

However, there is a reason why no one wants to touch Dolphin's Texture Cache. After this change, a slow trickle of regressions started to flow.

The common thread through most of these games is FMVs. Their videos would become stuck, only playing audio. While the games themselves didn't freeze, this regression made it frustrating to play certain games or impossible in the case of NHL Slapshot.

So what are these FMV games doing differently from other games with FMVs? Normally, games will store many frames in a buffer in Main Memory, streaming a frame at a time as it goes through the buffer. Once it reaches the end of the buffer, it loops around to the beginning where new frames are waiting. That method of FMV streaming still worked fine after the heuristic was added. But the games above (minus NHL Slapshot) share a common FMV library that, in a curious choice, has a buffer in Main Memory of one frame. To the GameCube and Wii's GPU it appears that the same texture is being reused over and over again, because technically it is; the texture is just being updated outside of the GPU's awareness. However, it is hardware-mode TMEM's job to cache textures that are used repeatedly, and it does indeed cache this texture. If TMEM delivered that cached frame, the FMV would become stuck just like Dolphin did after adding the heuristic. However, each frame is too large to fit into TMEM. Once TMEM is full, it just keeps caching, replacing the first parts of the texture with new parts. After the draw call is complete and the GPU asks for the frame again, TMEM notices that it doesn't contain the first parts of the texture, so TMEM lets the GPU get it from Main Memory instead. The FMV library doesn't even need to worry about explicitly invalidating TMEM, as the size limitation naturally invalidates it and prevents the cached frames from appearing on screen.

Dolphin's Texture Cache, however, didn't care at all about hardware-mode TMEM or the fact that it has limited space. It cached the entire texture, and when the GPU called for it again, Dolphin's Texture Cache provided it. And over and over it goes, displaying the first frame of the FMV over and over again until the FMV is done. Before the addition of the heuristic, Dolphin was so simple it managed to escape this trap. The hash check caught the changing contents of the texture in Main Memory and coincidentally followed the pattern the game expected by invalidating the cache texture after the frame was changed. But the heuristic determined (correctly) that the same texture was being reused and bypassed that hash check, allowing it to be cached and breaking the FMVs.

To fix this, Dolphin was going to need to start caring about what fits into TMEM. phire returned to do just that, with an expanded version of their original work that make's Dolphin's hardware-mode TMEM emulation able to keep track of the contents of TMEM and whether or not an incoming texture is too large for it. This allows Dolphin's TMEM hash bypassing heuristic to be much better at estimating whether or not an invalidation is necessary, and brings Dolphin a little bit closer to actual hardware-mode TMEM emulation.

The odd one out for this whole case is NHL Slapshot. It's bug is not related to FMVs at all, instead, it has columns of static graphics during gameplay. We're not completely sure what's going on with this one. We know it is also not respecting the TMEM invalidation rules, and that it is continuously reusing a texture like the FMVs did, presumably for some sort of post-processing effect. But it was fixed before we got the chance to look into it in detail.

Of course, this is still yet another patch for our not-emulation of TMEM. Rather than actually emulating TMEM so quirks in its behaviors just occur naturally, we're manually accounting for those quirks and stepping in to force it to work. This approach is fixing games, but it is a very unsatisfying solution that is definitely not ideal. It is phire's intention to eventually remake this whole system and genuinely emulate TMEM. It won't be easy, but it is possible with modern APIs. phire promises it will be done within this century, so we wait with bated breath.

5.0-15330 - Raise Program Exceptions On Floating Point Exceptions by JosJuice¶

True Crime: New York City has shown up on the Dolphin Progress Report a couple of times now. It's been laughed at for being an incredibly buggy, broken game, that was a stress test for Dolphin's memory management due to how much it swapped data and code between MEM1 and ARAM. But there was another intriguing thing about the game: the game would instantly crash in Dolphin when standing on any kind of dynamic object and no one knew why. This was the primary reason why people within the project knew the game existed, and over the course of seven years, developers spent hundreds of hours debugging the issue. Just glancing at it, we thought it was a typical bad game, but the more we were able to play it the more we realized just how wrong we were.

From the outside, the issue plaguing Dolphin seemed to be simple enough. The game ran fine, but any time your character contacted a physics object, the game would freak out and send you out of bounds. Because of a separate JIT bug, Dolphin would then crash. This isn't especially surprising to see in an emulator, as improperly emulating a CPU instruction can result in the wrong values being passed and eventually result in strange clipping issues or other problems that compound into the catastrophic failure you see here. For the longest time, we thought there was a bug somewhere in Dolphin's CPU emulation but we didn't have many leads. Thankfully, the game actually has a (semi) functional debug menu that let us examine the actual positional coordinates of the player during the crash!

Unknown issues to developers are like a lamp is to mosquitos. The fact that no one knew what was going wrong just made it all the more enticing to fix! booto literally followed a bad NaN (Not a Number) value backwards through tons of functions before eventually finding an operation on an INF (Infinite) that came from a divide by zero, but even then it didn't seem like Dolphin was doing anything wrong. As far as everyone could tell, Dolphin was behaving correctly. By the time 2020 rolled around, developers started to realize this was anything but an ordinary game. Rather, it had a special quality about it. At first developers lashed out against it, calling it garbage game that was poorly coded. And why wouldn't they? The game is super buggy and barely functional on console. In fact, the game will crash if you try to debug it with a USB Gecko, meaning that we couldn't even test to see what was happening in memory on console. All seemed lost... when something amazing happened.

smurf3tte, after having felled several other difficult problem games, decided that True Crime: New York City was worth a look. From there, they realized a rather sickening truth: The fact that the physics engine was dividing by zero wasn't a bug in Dolphin. It was all part of the game's plan. On Dolphin, these DIV0s would result in INFs, which then would become NaNs when used in other math operations that would result in the crashes. Until this point, we thought the way to fix the NaNs would be to stop the DIV0s, but smurf3tte realized that the game itself was using a custom Floating Point Exception handler to catch DIV0 exceptions and stop the INFs/NaNs from happening. Throughout the entire GameCube/Wii library, no one had run into anything like this so there was some skepticism that this was really happening, but the evidence was pretty strong.

Rather than investing a ton of time modifying Dolphin to support a custom Floating Point Exception handler without even knowing if the hypothesis was correct, smurf3tte instead hacked up the JIT to replicate what the Floating Point Exception Handler in True Crime: New York City would have done. Paydirt. This hacked up build unlocked Pandora's Box and could finally emulate True Crime: New York City. It wasn't a "real" solution, but for the first time we could examine the game and how it worked. Now the mystery became why. Why in the world was the game doing this? To do that, we had to dive into the game's history and collaborate with emulator devs from across the land.

The latter half of the sixth gen of consoles was the era of the "Grand Theft Auto Clone". After the success of Grand Theft Auto III, everyone wanted to get a piece of the action. True Crime: Streets of LA was a surprise hit and one of the more well-liked GTA clones of the era. It was successful enough to spawn a sequel, which leads us to True Crime: New York City. With a bigger budget and a taste of success, they set out to make an absolutely massive game with a huge scope. It's easy to point and laugh at it now, but looking back it was clear that the developers were trying to make a special product, even if the final game didn't turn out well. Something as simple as driving down the streets is rather impressive as you can use a real map of New York City instead of the in-game map and actually get around!

For a sixth generation open world game, the map is absolutely huge and densely packed with detail. The world isn't static either; as you clean up New York City, both the exteriors and interiors of buildings will change depending on what you do. If you're a bad cop ignoring crimes and just chasing your own goals, buildings get vandalized, windows are shattered, and stores across the city close down. On the other hand, being a good cop makes the place look nicer. Plants are watered, interiors clean up, and there are even nicer cars on the streets. This even spills into gameplay, as cleaner parts of the city have stores stay open later, which gives you more time to buy health items, weapons, and other upgrades during critical missions.

The story itself also had a lot of potential, with a lot of big name voice actors, branching missions where you can fail them and have to find a new lead, and tons of side activities that you'd expect in an open world game, including dynamically generated crimes. When we first started looking into True Crime: New York City, we thought it was just a case of incompetent developers making a bad game, but everything we saw while playing it made us realize that this wasn't the case. The people behind this game obviously cared about the product and put a ton of thought into the mechanics to really make the world breathe. Unfortunately, development constraints like budget and time cut out massive parts of the game, limited testing, and rushed the game out the door in an obviously unfinished state. And this is just referring to the original PS2 version. The ports weren't quite as lucky.

The PC version is... special. Framerate is inconsistent, sounds are broken/missing, and playing the game on a modern computer is an exercise in futility. The Xbox version looks competent on the surface, but the developers accidentally pushed the wrong build of the game into production according to what we know. The build they pushed has extra AI pathing issues, physics issues, and a mid-boss where the throw mechanic is broken, instead requiring frame perfect inputs or else you'll be softlocked. But none of these other versions can prepare you for the atrocity that is the GameCube version of the game. After playing the game for a few weeks, we've found so many issues with it that Dolphin's Wiki Entry on the game contains a list of bugs for users not to report because they are confirmed to happen on console. While the other three versions of the game look relatively close at a glance, the GameCube version is missing tons of effects and textures and looks like a plastic toy in comparison.

While both the Xbox and GameCube version were ported by Exakt Entertainment, it appears that the GameCube version got far less effort overall. Lighting and shading has been simplified resulting in a flatter looking world, especially during daytime scenes. A lot of other effects are missing completely, such as water physics in flooded basements. Perhaps because the GameCube used mini-DVDs, even texture quality has seen a massive downgrade, with some textures removed and everything being blurrier overall. They even broke the Main Menu, which is just a black screen with text on the GameCube version while the other versions have the Main Menu running on top of the backdrop of the city.

If all of these downgrades meant the GameCube version ran better, maybe it would be forgivable, right? If so, they were really struggling as the game runs a silky smooth 12 to 20 FPS while driving around the city on console. If you have a powerful PC and turn up the emulated CPU clock rate to ~170%, you can get a stable 30 FPS when emulating it. This is the one saving grace of running the game in Dolphin, as it makes driving around the city much more pleasant than it could ever be on console. Even then, the port still sucks and we haven't even gotten to the actually problematic part of the port: the physics engine!

As we said above, the physics engine is flooded with NaNs when playing the game on Dolphin. The reason why is because the PlayStation 2 supports extended floats. Rather than doing things how most other processors, such as PowerPC, x86-64, AArch64, etc. handle things, the PS2 decided that it would be faster to throw away all of that pesky error checking and special casing when handling floating point math. With the help of developers that work on the PlayStation 2 emulator, PCSX2, we started to learn about just how devious that console was when it came to Floating Point Math.

GameCube: 
1/0 = INF
sqrt (-4) = NaN 
INF - 1000 = INF  
INF/INF OR INF - INF = NaN

PlayStation 2: 
1/0 = Greatest Positive Float Number (0x7ffffffff) 
sqrt (-4) = sqrt(abs(-4)) = 2
7fffffff - 1000 = 7fffefff
7fffffff/7fffefff = 1

Essentially, the PlayStation 2 doesn't really have INF or NaN. One of the reasons that our friends working on PCSX2 have so much trouble emulating Floating Point Math on modern computers is because it's just not possible to emulate it quickly and correctly at the same time. We asked for a quote regarding their thoughts on Floating Point Math on the PS2, unfortunately due to the mostly worksafe nature of the Dolphin Progress Report, we didn't see it fit to broadcast such harsh language and we do not approve of insulting one's mother, even if it is the mother of a mathematical concept.

The important part to note about this is that True Crime: New York City divides by zero a lot. As in, every single time you step on a dynamic object, these divide by zeroes flood the physics engine to the point where we had to assume there was something wrong with Dolphin's emulation of a CPU instruction. We never actually considered that the game engine was doing all of this on purpose... yet, we now know that is indeed the case. It is likely Exakt Entertainment didn't have the time nor budget to rewrite and fix up the physics engine to get rid of the INFs. So their solution was to let the game divide by zero, raise an exception to be handled by their custom floating point exception handler, and change the INF to zero. This left us in the awkward position of needing to implement support for Floating Point Exception Handling, something that the developers who designed Dolphin's JIT never expected to need.

With us finally able to understand what was going wrong, the hard part of solving the problem was over. Now all developers had to do was add support for custom floating point exception handlers. The easiest way to do this was to add support to Dolphin's CPU interpreter, and then modify the JIT instructions so that they fallback to the interpreter when FPE handlers are enabled. And that's exactly what we did. The only downside is that there is a performance penalty to using the interpreter for these instructions, but it ended up not being a big deal.

By default, Floating Point Exception Handling is disabled. It was important that we don't let this change impact performance across the library just to support one really weird game. Then there are two settings for enabled Floating Point Exception Handling, with one of which being used for two games in their INI settings. The first is to enable Floating Point Exception Handling for DIV0 (Divide By Zero) exceptions. This allows Dolphin to emulate True Crime: New York City and another game ported by Exakt Entertainment, Call of Duty: Finest Hour, both of which rely on catching DIV0 exceptions to prevent game issues. However, that isn't correct emulation, so there is a second option that allows you to enable Full Floating Point Exception Support. This option is incredibly slow but allows Dolphin to accurately emulate console behavior when dealing with Floating Point Exceptions, even when the game is using a custom handler. This more or less exists for people working on homebrew or if we run into any unknown problems in the future that maybe would need full accuracy in this department.

Note, the original hack by Smurf3tte didn't have much of a performance penalty, but it also wasn't a real solution. Adding a bunch of code to the JIT to support just True Crime: New York City, not even Call of Duty: Finest Hour, just isn't reasonable. Even with the interpreter solution we chose, both games run full speed on modern computers, and the DIV0 fallbacks don't cost very much performance.

Warning¶

The following is a bit of an odd request, but we at the Dolphin team highly recommend that casual users do not play True Crime: New York City in Dolphin or on GameCube/Wii at all. Period. The GameCube version has tons of serious problems, including reports that it could outright corrupt your memory card and cause you to lose all of your savedata. While we never saw anything that corrupted our memory card, we did have one instance where True Crime: New York City just stopped saving until we restarted the game and all of our previous savefiles were missing. Thankfully, with the power of hexediting we were able to fix the savefiles, but any game that has a bug like that should be considered risky to play. We did play through the game on console as well, but unfortunately we were unable to trigger any of the memory card issues there, so we cannot confirm the type of memory card corruption that happened on console that players reported back when the game released.

Even ignoring that risk, this is the type of game where it's common for enemies that you need to kill to just spawn out of bounds where you can't reach them unless you know how to get out of bounds yourself. Sometimes, you can't even use glitches to fix your situation as loading zones might just stop working. And there are the typical problems of random crashes, physics issues with both driving and walking around the city, and you're better off just not unlocking the special driving techniques. Hell, even the controls are broken on the GameCube version as they mapped the horn to the same button as change song and there's no way to remap your buttons! The controls suck on GameCube overall because they ran out of buttons for other things so you have to do a lot of two button combos for actions that just use one button on the other systems. It's a game that fights you the whole way.

Is it possible to beat True Crime: New York City in Dolphin? Yes. One brave developer 100%ed the game in Dolphin, unlocked both endings, and beat the bonus mission. At some point it was less about completionism and more about proving it was even possible given some of the issues in the game, including the fact that one segment of the city will usually crash on the GameCube version. If you have fond memories of this game, you're probably remembering the superior PS2 version, which is buggy in some pretty funny ways while still being playable. Again, if you want to play this game, the PS2 version of the game is cheaper to buy, compatible with PCSX2 and is a much better game in almost every way. There's no reason to go out of your way to play the GameCube version...

Unless.

If you're looking to experience one of the most bizarre, buggy, and nonsensically broken GameCube releases, True Crime: New York City is the closest thing we have to a Sonic 06 level of trainwreck. Throughout testing, every time we played it we discovered new oddities, crashes, and just plain weird behaviors. The sad thing is that the game isn't all that bad when it is working, it's obvious that the developers were trying to build something so much better than what they made. If you have a powerful enough PC to run the game at a healthy emulated CPU overclock, the game can be fun at times. Just remember, we warned you of the risks.

5.0-15407 - HLE Riivolution Patch Support by AdmiralCurtiss¶

The Riivolution patching infrastructure is one of the most popular ways to create large scale game mods for the Wii. By taking advantage of complex IOS patches provided by the Riivolution homebrew launcher, mod developers can redirect disc reads to the SD card, making it easy to develop and distribute mods. For users, it was also simple as there was no extra patching process, and the fact that you could play the mods using genuine game discs made it feel safer for purists.

This format is essentially the standard for a lot of different mods, and Dolphin users have been asking about support for years. Unfortunately, the situation was rather murky. There were methods to convert Riivolution mods to a pre-patched ISO, but this was rather tricky and most mods didn't provide instructions nor did they want users to use the mod that way. Supporting it accurately isn't really an option: supporting cIOS mods requires Low Level Emulation of the Starlet Coprocessor, and Dolphin isn't even close to that. This would also bring a rather hefty performance penalty to users trying to run these mods.

AdmiralCurtiss noticed that there was another option. Riivolution's mod format isn't all that complicated, and could be recreated without the need for cIOSes rather easily. Instead of trying to emulate it, he decided to go the same direction as Dolphin's IOS emulation and directly reimplement the functionality in Dolphin. Thus, he began work on supporting Riivolution mods and making playing them in Dolphin as simple as it is on console.

Riivolution Support in Dolphin¶

Dolphin's Riivolution support uses the same Riivolution mods you download for console and works similarly overall, just with a splash of HLE to implement some cIOS functionality. All users need to do is extract the Riivolution mod to the correct directory (On Windows by default - Documents\Dolphin Emulator\Load\Riivolution) just like you would on a Wii. Because this is handled through High Level Emulation, there's no need to mess with Dolphin's virtual SD card or anything like that, putting it in the folder is good enough. Then, simply right click the game in the gamelist and click Start with Riivolution Patches. Enable the one you want and launch and you're ready to go. Eventually, we plan to add support for being able to boot Riivolution mods directly from the gamelist and on netplay once a few more issues are ironed out.

AdmiralCurtiss also implemented a lot of niceties to make sure that playing Riivolution games is robust and simple. Pretty much any game mod should work, and savegame redirects are supported if you want to have different saves between Riivolution mods and the base game. Not everything works however. Advanced features such as RiiFS and the such are not currently implemented in Dolphin. As well, Dolphin's disc read timings are currently disabled when playing Riivolution mods. This is because Dolphin is not currently able to differentiate which files are located on the virtual SD card and which files are on the disc. A game might expect to be able to jump between a lot of different files on the SD card quickly, but if Dolphin were to apply disc seek timings to the reads, it would cause a huge slowdown and maybe even break the game.

To this point, it may seem like the choice of HLE only comes with downsides outside of performance and ease of implementation. However, there's one rather interesting benefit as well. On console, because Riivolution relies on IOS patching, it can only be used in Wii mode on Wii games. Dolphin's Riivolution support does not have this limitation. It is possible to create Riivolution mods for GameCube games in the same manner as Wii games and run them directly in Dolphin. You don't need to worry about complicated patching instructions that users will stumble over or potentially running amiss of copyright holders by trying to distribute pre-patched files. Combined with features like CPU Clockrate Override and Extended MEM1, there are a lot of possibilities for powerful GameCube mods using an infrastructure that modders are have been using for years. We've already seen some modders embrace this feature with Shadow the Hedgehog 2p working directly in GC Riivolution in Dolphin.

As one final note, Riivolution patches are not supported on WiiWare titles, as they do not use disc reads.

Riivolution Support and Android¶

A lot of times, new features sometimes lag behind in the Android version because of GUI issues. Thankfully, Android users won't have to wait for Riivolution support. JosJuice jumped on porting over the Riivolution launching/loading interface so that you can run your favorite Riivolution mods on your preferred mobile device.

Macsimum¶

A new machine has entered the Dolphin family - a 14in MacBook Pro with an M1 Max. Naturally, we promptly ran it through the same benchmarks we put the M1 MacBook Air through in our prior tests. How did it fare?

Some of you may view the above and be surprised. Sure it's better but the M1 Max is not trouncing the original M1 - it's only a notch above. That's simply because of Dolphin's workload. The M1 Pro and M1 Max have more multithreaded CPU power thanks to many more performance cores, but those are the exact same performance cores that are in the M1, running at the exact same clockspeed. As an application that depends on single thread CPU performance, the CPU power available to Dolphin is basically the same for both SoCs and the performance is similar. The improvements we're seeing here are from removing every bottleneck that constrained the M1, thanks to the M1 Max's cache, memory bandwidth, and significant GPU improvements.

What isn't shown on that chart is the absolutely monsterous GPU the M1 Max delivers. Native res for the display (5x native for the 14in) is trivial, and many games can run fullspeed at 8k (12x native) in our tests. The original M1 choked on 4x native, hence picking 3x for the original testing.

Now that we have direct access to M1 hardware, we took the opportunity to revisit our framepacing tests that previously revealed framepacing issues on Macs with Intel graphics, and confirmed that it is not an issue on M1. Macs with Intel graphics STILL suffer from this problem. For you are not familiar with frame timing and frame pacing, we briefly explained it previously.

Expect to see more of this MacBook Pro in tests going forward.

Last Month's Contributors...¶

Special thanks to all of the contributors that incremented Dolphin from 5.0-15107 through to 5.0-15445!