We've got a lot to get through the past two months. Headlining it all is that we're happy to announce support for a new compressed disc format developed specifically for Dolphin: RVZ. This lossless format allows for near top of the line game compression without compromising the integrity of ISOs, while also maintaining performance and stability. But what good is compression if emulation isn't up to snuff? The past two months have been chock-full of emulation and usability fixes for both Android and Desktop Dolphin! There's a little bit of everything, from graphics emulation fixes, memory card and savestate compatibility changes, to obscure features like being able to report thermal data to games and homebrew!
Rather than delaying any longer, let's just dive in now! Please please enjoy the May and June Dolphin Progress Report!
When using Dolphin's OpenGLES backend on most Android devices, a lot of games behave poorly when trying to read the screen with EFB peeks. By checking what is on the screen, games can accomplish all kinds of visual effects or even use the data for gameplay! Wind Waker uses EFB Access in order to tell when the sun is or is not visible in order to do a shine effect and darken everything else on the screen. Super Mario Galaxy goes a step further, with similar sun effects and gameplay features like Pullstars and collecting Starbits that rely on knowing what's on screen. All of this was broken in Dolphin's OpenGL backend in GLES mode! After doing some debugging, we discovered that glReadPixels() with depth formats is not supported in GLES, meaning that these reads were being completely skipped. While this meant there was no performance hit to enabling EFB Access from CPU on OpenGLES, it also meant these effects would completely fail.
In order to fix this, Stenzek created a fallback for this situation that copies into color formats instead of depth formats. This allows EFB Access from CPU to finally work correctly on GLES devices.
NOTE: Because EFB Access from CPU is working correctly in some games, that means there is now a performance impact to enabling the feature in those games. Users that were used to Super Mario Galaxy running faster on OpenGL than Vulkan will now see that performance should be much closer between the two backends. This loss in performance is not a bug! A crucial part of emulation that is required for these games to run correctly was being completely skipped! Do not report performance losses in games that require this feature. Thank you.
The name of Stenzek's branch should say everything about how we got to this point: "adreno-more-like-brokenreno". A work-around for another adreno bug has caused us to run into more issues. The problem was that attempting to create savestates in Vulkan would crash Dolphin due to an assert in the driver when reading back D24S8 depth. In order to work around this, Dolphin now uses R32F on afflicted devices instead. This allows savestates to function on Vulkan on Adreno devices.
Stenzek strikes yet again, this time fixing up an unfortunate regression that turned up a couple months ago. Changes to Dolphin's window creation procedure was causing Dolphin to use the wrong window surface when trying to handle a user's mouse cursor for infrared. Instead of using the game window, Dolphin was instead using the gamelist! Whoops.
Super Smash Bros. Brawl users commonly use SD card data to load up total game conversion mods. However, for netplay to succeed, the users' SD cards needed to perfectly match. Unfortunately, the Wii was not designed at all to maintain SD Card determinism; if a game so much as reads the SD card, the contents would be ever so slightly altered. Even these tiny changes are enough to cause desyncs in games on netplay, requiring resharing and resyncing of SD cards. This can cause a lot of headaches, especially when some Brawl mods use 2GB SD cards! Fortunately, there is now a solution. In order to prevent small SD card changes like this, you can now lock your SD card in Dolphin's Wii Settings page. This should make syncing up and playing games that rely on SD cards much more predictable in the future. If you're unsure if your SD cards match, make sure to compare the hashes in the netplay window before playing!
The reason that this is two commits is that Ebola16 implemented this into Dolphin's Android GUI. They've also been implementing tons of other missing features from the desktop version of Dolphin into the Android touch and TV. Individually, each change is rather minor, but they've slowly been making the Android version of Dolphin easier to use and more powerful all at the same time. Also 5.0-12090 failed to build, hence the missing link.
It came to our attention that the latest version of Swiss-GC was hanging on Dolphin. Considering the popularity of Swiss-GC among our users, it was of the highest priority to get this fixed. You didn't buy that, huh? Well, actually, the reason that this got fixed so quickly is that Swiss-GC is an open source app for the GameCube with developers that are close to our community. They not only provided us data on what registers they were newly using, but we could directly look at their code to see what it was doing. After dealing with so many games that are black boxes, it's refreshing to work on something where we actually know what the software is trying to do.
Preservation is one of the core benefits of emulation. There will come a day when the last of the Wii's online services are a distant memory, there isn't a working Wii disc drive to be found, and Wii discs are most useful as coasters. All that will be left of these games and their experiences will be the digital backups made in this era, when Wii hardware and discs are still functional and available. Unfortunately, many users turn to mangling their dumps in an effort to conserve limited hard drive space. These dumps may work in the short-term, but lack important files like Wii Update data and IOSes that may be necessary in the future to use various features of the game when NUS no longer functions.
That's why we're happy to introduce a new high compression storage format designed for Dolphin. Built off of Wiimm's WIA format, RVZ is an evolution of that format designed specifically for realtime performance and complete preservation of all disc data while maintaining as high of compression as possible. Unlike WIA and NKit files, which each have their own issues when used directly, RVZ circumvents almost every issue that plague high compression formats. It's designed to have no performance impact when used in Dolphin as long as you have a CPU with more than two cores, which is a huge bonus when other compressed formats result in frustrating stutters during loads that don't happen on uncompressed ISOs. RVZ discs are also directly compatible with ISOs even in situations that require perfect determinism like netplay and movie recordings.
Why Lossless Matters¶
You might be wondering why lossless matters so much. Why does preserving things such as update data and garbage data actually matter? There are multiple reasons that we can quickly go through.
- Online services like NUS for Wii will not exist forever. Update files on discs may be the only way to access certain features on games that rely on various IOS features.
- Inaccurate dumps can cause all kinds of unintended issues. RVZ can be directly verified against ISOs in Dolphin.
- Some games may accidentally read data that they do not intend to, meaning that garbage data can actually come into play.
- Losslessly compressed discs can be converted back into clean, verifiable ISO files.
- Verifiable, Lossless dumps make it so our support staff knows that the disc image is not the problem when providing assistance.
By storing Wii data partitions unencrypted, RVZ is able to compress and preserve every data partition without a huge penalty to space. RVZ can even compress garbage data down to almost nothing!
Because RVZ is a brand new format, it isn't well supported in other programs. Thus, to ease the process, we've added support directly to Dolphin to convert to RVZ. Unfortunately, RVZ files are not compatible with Dolphin builds older than 5.0-12188, so going back to prior versions will require converting games back to ISOs beforehand. However, you can do that directly in Dolphin's gamelist, so it isn't too terribly painful.
|Can Compress Encrypted Wii Data
|Can Compress Garbage Data
|Correctly Emulated Load Times
|Good Real-time Performance
When comparing a bunch of formats, inevitably you get to the point where you just have to crunch the raw numbers. There are a few caveats we have to get to before going over what these numbers mean and why. The ratio of garbage data to real game data varies greatly per game, and because garbage data compresses much better than real data, the exact savings is highly variable. It's completely normal to see a game drop from 4GB to 300MB, but it's also normal to see a game nearly unaffected by compression. A famous example of this is Twilight Princess Wii - as a title originally developed for the GameCube and its smaller discs, the Wii version is mostly empty, allowing it compress at a very good 3.8:1 ratio.
We also must note what settings we used with each of these formats. We could easily make RVZ look fantastic by simply comparing all of these formats in a lossless test. However, that's not how many users used these formats and it would be incredibly misleading. As such, we used the typical settings for GCZ and WIA that users would use in order to save space. If anything, this shows how little is actually sacrificed to use RVZ over a lossy format.
|ISO - Lossless
|GCZ - Scrubbed
|WIA - Scrubbed
|RVZ - Lossless
|Twilight Princess Wii
|Metroid Prime Trilogy
|Rogue Squadron 3
|Smurfs Dance Party
About the NKit format¶
One format we didn't compare to in those charts is NKit. It's just a very hard format to compare against thanks to crazy features and how it will happily split update data and reuse one copy among many games. When doing initial testing, it was very hard to get a grasp of exactly how much it saved. While on an individual basis, it appeared that RVZ was superior to NKit in terms of compression, as you compress more games, because of its ability to reuse update partitions it would actually gain an advantage. This makes it a fantastic choice for the long-term storage of large collections even if it appears as though it loses out on a game by game basis.
|RVZ (128 KiB, 22)
|.nkit.gcz (NKit defaults, 16KiB)
|Four Sword Adventures
|New Super Mario Bros. Wii
All games are PAL. Update partitions not removed.
Unfortunately, as great as NKit is for long-term storage, it tends to be just as problematic for emulation. NKit actually shifts file locations around on the disc, moving them to earlier in the file, which would be toward the inside of a disc. This normally wouldn't seem like a problem, but Dolphins emulates CAV, and moving files toward the inside of the disc means that less data is read per rotation. The end result is that loadtimes are sometimes increased by 10 to even 20%! Different loadtimes means that features like netplay won't work between NKit discs and dumps that don't modify file locations.
But, beyond those minor gripes, NKit has another problem that makes it much more problematic: some games just really hate it. We are aware of at least two games that simply crash in the NKit format. One unavoidable crash is present in Super Paper Mario and we've already seen dozens of users confused as to what is going wrong. Namco Museum (specifically the Galaga Arrangement) also crashes, but that crash can be prevented by converting to Nkit with safer settings.
Regardless of these problems, when used as a long-term storage format that isn't going to be used with Dolphin, NKit is fantastic. However, if you want a compressed format to use in Dolphin, use RVZ. When used on a game by game basis, both NKit and RVZ will result in very similar file sizes for losslessly compressed discs.
The advent of the GCI folder option brought convenient save management for large GameCube game collections. It allowed users to bypass annoying file limits present in standard memory card blobs while giving instant access to copy, delete, or modify saves directly in your favorite file manager. Everything seemed fine, but upon promoting and recommending GCI Folders, we started to see a prominent, but confusing issue. Sometimes games would simply start refusing to save. While we didn't know exactly what was causing the issue, it became clear early on that savestates had something to do with it. And, once the game refused to save on that savestate, you were essentially permanently stuck and could no longer use in-game saves unless you restarted from your most recent in-game save.
After cutting his teeth on the Memory Card Manager, AdmiralCurtiss had some idea of what was going on and even provided an earlier attempt. One of the important things he provided were steps and information for why this was happening.
- Create a savestate.
- End Emulation.
- Open the original game.
- Load savestate.
- Attempt to save and watch it fail.
However, despite having concrete steps to reproduce the issue, and even a potential fix, we were alarmed that all known solutions created the possibility that savestates could overwrite saves of other games, causing users to lose tons of progress. Fortunately, we now have a proper, safe solution. Dolphin now stores the memory card header in EXI_Channel to ensure the same game session is preserved across savestates. This means the game won't think that you're saving to a different memory card, even if you've stopped Dolphin, modified the memcard, and reloaded your savestate. And of course, this has a number of protections so there is no chance that savestates will overwrite the save data of other games.
Note: These fixes do not affect Pokemon Colosseum and Pokemon XD's save issues regarding savestates. They have purposeful memory card checks to prevent the duping of Pokemon. Unlike the previous problem, which was more of an emulation oversight, this one is something that should be solved through a game patch. Currently no one is investigating this issue and you should be wary of using savestates with these games. If someone does write a patch or a cheat for this issue, we will be happy to include it with the game's INI file for easy access to users.
Free Look is a longstanding Dolphin feature that allows the user to reposition the camera in a game however they so please, with abilities far far beyond what game cameras can provide. This allows for exploring blocked off areas, advanced game photography, and more.
For the past couple of months iwubcode has been working on an ambitious personal project to improve and expand the Free Look feature set. Over the past two months they added new experimental camera modes and fixed several Free Look bugs, and this is only the beginning. The biggest of the changes so far is a new option to allow adjusting the field of view of the Free Look camera. With this new option, all manner of new shots and perspectives that was impossible to do before are now within our grasps!
In addition to game photography, this can also serve a gameplay purpose as well. If you don't like the field of view a game uses and want to go wider or tighter, this new option will allow you to change it!
This option can be found in Graphics > Advanced tab, or field of view can be adjusted via hotkeys (default is shift+mousewheel). This is only the beginning of the crazy things iwubcode has planned, so hopefully Free Look will continue to get new features in the coming months.
This feature comes directly from the XLink Kai developer CrunchBite. If you aren't familiar with it, XLink Kai is a service designed to allow tunneling of LAN games across many consoles from old to new. In this case, they've implemented a BBA backend for Dolphin that allows users to play BBA games locally and online through their service. You can even play with other players so long as you're within as ping tolerance for the selected game. For Mario Kart: Double Dash!! it can actually be stable with two players up to around ~60ms of ping, which does give it some range. Other games have their own ping tolerances and they will perform best over LAN.
The biggest benefit to XLink Kai support is that you don't need to go through the setup and downsides of using a TAP adapter on Windows. On Windows, not only is setting up TAP adapters and getting Dolphin to connect to them a rather treacherous task, latency limitations would often cause games to lag and disconnect even when both instances of Dolphin are running from the same machine. There wasn't really anything that could be done, the few people that did rely on BBA support in Dolphin would avoid Windows for Linux just to make things playable. Windows users no longer need to feel like third class citizens in the world of BBA, as this problem is completely non-existent with XLink-Kai. It does not rely on TAP adapters and instead manually injects cleaner ethernet frames than the game could have ever imagined.
Using the XLink Kai service can be fairly daunting at first, so we suggest carefully following their guides on their website to ensure that things are setup correctly and you know the limitations of the service. Also please contact them directly for any support issues regarding the service; our forum helpers are ill equipped to help with XLink Kai.