True Crime New York City Gamecube Cheats

[Beatrix Gerke]

Its 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.

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!

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.

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.

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.

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.

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.

3a8082e126