It feels like it's been some time since we've had actually had a monthly Progress Report. This is because there haven't been as many major changes landing, making it harder to fill out a substantial article. That isn't to say that things have slowed down, these smaller changes increase the quality of life for users and add up, especially when jumping from older builds to the latest. However, these changes are a lot harder to show and feature in a Progress Report compared to things that actually affect the core emulation and games. This time around, we had more than enough on our plate to write about, including support in the latest builds for a very interesting game: The Metroid Prime 3's E3 2006 Beta.

But before we get to the new changes, we need to cover something we missed last month. So, without further delay, please enjoy the mostly April Progress Report!

In the chaos of the input changes last month, we managed to miss a notable change regarding custom textures. Whoops. So here's a little something from March!

GameIDs are the unique codes that Nintendo used to catalog and keep track of games, and they are very important to the GameCube and Wii. For instance, when a Wii console is loading the North American version of Twilight Princess Wii, the console doesn't know or care about the game's name, the only thing it is aware of is that it is loading RZDE01. Since Nintendo went out of their way to create a unique identifier code for each version of each game, Dolphin heavily relies on GameIDs throughout its code. This includes our custom texture loader especially. Within our Load > Texture folder, textures to be loaded must be sorted into folders with either the first three or all six characters of the GameID, otherwise Dolphin will ignore them. This way we know exactly what files belong to which game and everything works as expected.

While this worked well for many years, there was room for improvement. One or two texture packs in the Load > Texture folder are very easy to indentify, but that clarity is very quickly lost as more packs are added. They all just start looking the same after a while. Can you remember WPJEJW from WCKJWN, or SOBD7K from SO3EE9? Even our long term developers and testers would have to look those up!

This is a fairly tame example of a custom texture folder. How many games can you recognize?

Annoyed with the sea of GameIDs, iwubcode has changed our custom texture loading to allow for a descriptor file. Simply by placing a text file with its name set to the GameID of the game within the texture pack's folder, Dolphin can now identify the contents of the folder regardless of the folder's name! With this, you can name and organize your Load > Texture directory so all of your custom texture packs are nice and neat.

Now it is much easier to read!

For those wondering, if you want to use two texture packs for one game, you can. For any textures that they both try to change, the last one loaded will override the previous versions of that texture. The folders are loaded in alphabetical order.

Homebrew on Netplay may sound like an incredibly niche use of Dolphin, but it's actually one of netplay's most popular usecases! Why? Well, it's because many Super Smash Bros. Brawl mods use homebrew, such as Gecko OS, paired with SD cards packed with codes and other assets to transform the base game without needing to modify the original dump! With some of these mods having competitive scenes, Dolphin Netplay can be a useful tool for training and practice.

Super Smash Bros. Brawl is a major hub of both Wii Game Modding and Dolphin Netplay

Unfortunately, an oversight in Dolphin's Wii USB emulation caused a hang when booting Gecko OS and other Wii Homebrew in Dolphin. The cause of this is that most of Dolphin's USB emulation is disabled in Netplay (and TASing) in order to keep things deterministic, and Dolphin would attempt to initialize it anyway! Thankfully, once the issue was properly bisected, Techjar quickly rectified the issue and now these mods can once again boot in netplay.

Dolphin is a project that sees use from a wide variety of users. We want to make sure everyone has a good experience, but many of those users desires may not only not overlap, but may even conflict with one another. A casual user looking to plug and play their favorite game will want a very simple, easy to use emulator, while an advanced user looking to exploit their powerful hardware for all it can do will want a wide breath of features that allow them to enhance and fine tune their experience. To handle this, we carefully balance our different user needs to apply to as many users as possible, then have more advanced features hidden for those that need them. Our internal resolution selection is a perfect example of this. Right now, our UI only exposes up to 8x Native (5120x4224). According to the Steam Hardware Survey as of this writing, that will cover more than 98% of users. This minimizes our exposed options, prevents people who may not know what the option does from potentially crashing their graphics drivers, and allows basically everyone to meet or exceed the maximum resolution of their display.

But of course, there is still the small percentage of users with incredibly insane setups that go well beyond the bulk of our userbase. For that tiny group of users, we allow our INIs to set the internal resolution to go as high as they want. The only limiting factor is the hard limits of your graphics card!

WARNING, the fullsize image is 23164x18480 (35x native) and can easily overload browers. If you dare, click here to view it in full size.

Unfortunately, as a very advanced feature for very very few users, time was not kind to this feature. Previously, in WX, if a custom resolution is configured in the GameINI, it appears as "Custom" in the GUI. When we moved to Qt this was never recreated, so if the user configured a greater than 8x native internal resolution via INI and then looked at the Graphics > Enhancement tab, internal resolution would just appear blank. To make this worse, upon loading that blank value, Qt thinks its a new value and writes -1 into GFX.INI for internal resolution. That is not an accepted Internal Resolution, so as long as -1 remains within the INI, Dolphin will crash any time a game is launched. This created a situation where if a user wants to regularly use a resolution higher than 8x native, they had to NEVER look at the Enhancements tab. If they did, they would have to go back into the INIs and reconfigure everything. This is terrible UX. However, this feature is so niche we didn't even notice the issue for years, and we never traced this bug to the Qt move until doing testing for this very article.

In WX, at higher than 8x the Internal Resolution would appear as "Custom" and be stable.But Qt would display it as blank and write -1 to GFX.ini.

With Internal Resolution set to -1, attempting to start a game will crash Dolphin.

8k (7680x4320) requires a 12x native internal resolution to fill, so when MayImilae got a shiny used 8k display, she ran headfirst into this issue. Fixing this without over complicating the GUI or exposing potentially dangerous settings to general users was a problem, so a plan was devised with Stenzek to build a new, better way to handle this scenario. Now, any internal resolution set in GFX.ini (positive values only) will be exposed within the GUI, so there is no longer any blank slots and no writing -1 to the INI. Problem solved! But their plan went a step further, and added a new, INI only setting called MaxInternalResolution. This "meta-setting" controls the maximum exposed internal resolution in our UI. So for the few users with 6k or 8k displays, you can now make your display resolution appear in the GUI and switch between them as conveniently as any other setting!

8k users rejoice! All three of you.

Combined with the bug fix, this makes using Dolphin with an unusually high resolution display MUCH more pleasant to use!

Note: Please remember that internal resolution does not equal SSAA. Dolphin does not have the filtering that SSAA has, so setting the internal resolution well beyond your display's resolution will create more aliasing, not less. For best results, please set the internal resolution to the maximum resolution of your display and then add MSAA or SSAA. You should only go beyond the maximum internal resolution of your display for specific situations, such as reducing fullscreen blur in certain games.

This is a relatively minor hack meant to suppress warnings in particular games. Normally, XF (Transform Stage, handles vertex transformations) and BP (Blend Processor/TEV, handles blending) are configured to use the same number of channels. However, it's possible that a game could accidentally set a different number of channels in each stage, resulting in some wonky behaviors. Imagine the game configuring the transform stage to say vertices have 2 color channels associated with them, and then configuring the Blend Processor to say that they actually have three! In hardware tests, situations like this result in mostly broken rendering.

The case we were hitting turned up in Super Paper Mario and SSX Tricky, where they would have extra channels in the transform stage compared to the blending stage. This would cause Dolphin to throw a nearly infinite number asserts rendering the game unplayable. While users could bypass and play the game normally by disabling panic handlers, this was still a rather awkward behavior. Stenzek did significant hardware testing on these cases, though it did not have complete coverage. In order to prevent needlessly deadlocking people's games, we've chosen to skip rendering objects with mismatched XF/BP stages and disable the assert. In early testing, there appears to be no change in rendering, meaning that it's possible that these objects don't render on console as well. More testing will be needed, but this should be a suitable solution for the time being.

There is no visual difference, it just doesn't crash anymore, so... here's a screenshot of Super Paper Mario!

In order to keep proper tabs on this issue and gather more information for testing, if you've turned on Usage Statistics Reporting, Dolphin will now automatically report to us any games that use mismatched XF/BP configurations so that we can better test fixes down the road when this issue is looked at in greater detail. If we do find a game that has a rendering difference from this change, it could lead to better emulation of these edge cases.

While most Wii games have had their online services shutdown by this point, there are still a few games that can connect online and still play. However, even in games that have had their servers shutdown, correct emulation of how the Wii would act is still important. Games such as DJ Hero, Rock Band 3, the Just Dance Series, some of the Wii Call of Duty games, among others have issues when connecting to online services, whether the servers are still up or not.

Sepalani has been investigating these issues for many months while writing hardware tests to verify the Wii's online behavior. This particular set of patches allows the Call of Duty games to connect to their servers without crashing. While the servers are actually still up, we weren't able to play on them in Dolphin. We were unfortunately missing the update files, and with the Wii Shop gone, there doesn't appear to be any method to update the game so that they can connect. If someone has played any of the Wii Call of Duty games online, it may be worth doing a NAND backup and trying them out in Dolphin before the remaining servers are gone, in case there are more problems beyond the ones that we've fixed.

While this does improve the situation overall, by fixing one set of hangs, we've simply progressed to another set. As such, the other games in the list will simply progress further, but hang at a later point in the process. Those behaviors are currently being investigated, and we're hopeful that these games will behave correctly in the near future.

A feature like this has been long in the works, with varying implementations and ideas for it floating around for years. The initial reason that Dolphin has had compile time support for configuring MEM1, which is the GameCube's RAM, is that the GameCube/Wii Dev units have increased memory for debugging and testing. Developers and power users could modify Dolphin's source code in order to increase memory for running the Metroid Prime 3 Beta, which ran on a development unit with 48MB of MEM1 compared to the 24MB that Dolphin, GameCube and Wii have for MEM1. With Minty-Meeo's changes, you can now change MEM1 and MEM2 size directly in Dolphin's GUI, without the need for recompiling Dolphin.

However, Minty-Meeo wasn't doing this for something so obscure like this. His motivation was actually centered around game modding and randomizers. Randomizers are a way to bring a fresh experience to some of your favorite games. By randomizing what enemies spawn, where items spawn, and in some cases, how areas are constructed, and much, much more, randomizers can push your game knowledge and skills to the extreme while presenting unique challenges. Popular game series such as The Legend of Zelda, Metroid, Pokemon and many more are home to randomizers. There are already several randomizers of GameCube games, including The Legend of Zelda: The Wind Waker and Metroid Prime 1/2 featuring sizable randomizer communities. These randomizers run on both Console and Dolphin without any modification!

Randomizers breathe new life and challenges into some of your favorite games.

While we do believe that targeting original hardware should be the goal when possible, using additional memory during development can allow for easier debugging and can allow for doing things that simply aren't possible on original hardware. Take for instance the Colossal Cavern mod for Pikmin 2, which takes every enemy and treasure and loads it into a single, gigantic cave floor. Memory limitations make a single concurrent level of this size unreasonable on actual hardware, but with expanded RAM, suddenly the improbable becomes possible.

As soon as this feature was merged, people were asking about turning up memory as a performance hack for games. However, most games do not even query for how much memory is available and will not take advantage of additional memory for features. In fact, some games like Super Mario Galaxy 2 will outright crash when run with increased memory. There can be benefits, though! The infamous crash in Fire Emblem: Radiant Dawn where the game runs out of memory in Dolphin for unknown reasons can be avoided by increasing MEM1 by even a slight amount.

This change is part of an ongoing effort for Dolphin to better preserve your emulated Wii's ID. This ID is useful for connecting to things like Wiimm's WiFi servers, which have a seven day lockout for new users in order to help with cheater and hacker problems. While they allow Dolphin users, you're required to have a real Wii ID, which hasn't been handled all that well. Recent efforts by JosJuice and Leseratte10 are at the forefront of better handling these situations so that people that use Dolphin on Wiimm's servers aren't randomly mistaken for new users.

This most recent change has to do with the encryption of Settings.txt, which stores a lot of important Wii information. While encrypting this file, Dolphin wasn't handling things quite right, which allowed for Null Bytes to end up in the middle of encrypted data. The Wii would treat the Null Byte as end of the line, resulting in data being incorrectly read and users being unable to be verified on their server. With this corrected and other changes over the last few months, users should no longer run into issues where they are suddenly unrecognized by Wiimm's servers.

It's been quite a while since we've had enough Android changes that we've felt the need to dedicate a full section to them. But with a smattering of new contributors and gigantic fixes, it was a nobrainer to specifically highlight these changes.

When it comes to finicky platforms like macOS or Android TV, we have always warned users to be wary when upgrading to a new OS version. Not only are they the platforms most likely to randomly break something in an update, they also have our smallest userbase and no regular developers to address when something goes wrong. Case in point, Android TV 9 has not been able to launch Dolphin since it was released in August of 2018. That's a lot longer than we'd like for the latest version of a platform we support to be broken, but honestly, it couldn't be helped. Our audience of up to date Android TV players is incredibly small, and none of our developers use Android TV for Dolphin on a regular basis. Fortunately, we have a great community that we can lean on for situations like this. After reporting the issue to us, webgeek1234 turned around and started investigating it themselves. They determined the entire incompatibility was because Dolphin was bringing up a popup in a deprecated way. Yes, the entire application was crashing because of one old popup. Android. They updated the way Dolphin brought the popup, a one line change, and suddenly everything is working once more!

While this particular setting may not make much sense to people on the outside, we weren't surprised to see Ebola16's interest in adding it to Dolphin Android. For many years, they have been one of our most dedicated bug reporters when it comes to various Super Smash Bros. Brawl mods. One of the biggest things you need to boost Brawl mods is SD card support. While you could manually enable SD cards via INI files, Ebola16 decided to streamline the process by allowing users to enable, disable, and select SD cards directly in the Dolphin Android Interface.

Enabling SD cards is simple and painless, just like on desktop builds.

Note: Dolphin will automatically create a 128MB blob file that acts as a virtual SD card, much like it does on desktop builds. Dolphin cannot use an actual SD card.

Configuring Wii Remote settings on Android is a pain for multiple reasons, one of which is that Dolphin Android required a full restart in order for changes to take effect. This meant that making simple changes was sometimes a multistep process. Ebola16 had enough of the problem and restructured how Wii Remote settings were saved in order for them to immediately take effect, much like how it is handled on the desktop version.

Installing WADs is an important feature for Dolphin, which wasn't easy to do on Android. The original intent behind this Pull Request is to make installing IOS files easier for mod loaders. Unlike the desktop version, accessing updates and the system menu isn't quite as easy right now. Plus, when space is a concern, simply lugging around a single IOS wad is a lot cheaper than transferring a Wii game or installing a full System Menu, Default Channels, and a full set of IOS files from a system update.

In the end, this is a nice feature to have and makes the Android GUI more powerful and closer to the the desktop GUI.