June was a month where a lot of important features were merged, but few of them had to do with actual emulation. Every emulator has its own philosophy and goals. While the primary goal is usually to emulate the console at hand, many emulators place secondary goals on various features and ideas. One of Dolphin's secondary goals is to make using the emulator as simple of a process as possible. There are lots of features that try to simplify things, like the Game INI system, support for real controllers, and more.
Many of the features that dropped this month have made Dolphin a little easier to use without affecting much of the emulation underneath. They provide an important role in making the time before and during an emulation session more enjoyable. We hope you enjoy reading about these features and more in June's Dolphin Progress Report!
5.0-4050 - Emulate Socket File Descriptor Table by sepalani¶
Emulate Socket File Descriptor Table may sound pretty important, but emulation of it is only needed for two channels. But boy are those two channels ones we've been chasing. This fixes both the Netflix Channel and Crunchyroll Channel!
Emulating a socket file descriptor table was necessary because the Netflix Channel and friends would check and see if the fd value was greater than 23. If it was, it would return an error. This was likely some kind of sanity check against a predefined limit, and properly emulating this feature allows both titles to work! While a lot of the Wii's network stack is already emulated, Dolphin was just using the host's fd table without translating it. This caused the values to sometimes be much higher than they could possibly be on the Wii, and in the end did in titles like the Netflix Channel. sepalani rectified this by reverse engineering how the Wii's fd table works to properly emulate the fd table.
Due to a bottleneck in IOS emulation, the Netflix Channel runs VERY slow currently and is not ready for conventional use.
It took a loooong time to get even this! Even as we inch ever closer, the wizards of Factor 5 continue to torment us.
Why is it so slow? IOS is threaded, while Dolphin emulates it on a single thread. Actions that shouldn't block other actions currently are, resulting in very, very low performance. While threading IOS's 40+ threads properly isn't plausible, it's still possible to do some operations asynchronously. This would fix the random, non-shader lagging in games like Guitar Hero and Rockband as well, which lag due to IOS blocking on some online functionality. But more importantly, Netflix would probably run at full speed.
5.0-4127 - Update free DSP ROM to support GBA ucode by ligfx¶
Last month one of the bigger changes was DSP-HLE getting improved GBA microcode support. This allowed users to get a good experience with GBA <-> GCN games without needing to dump the DSP-ROM from a GameCube or Wii. After looking into it further, ligfx implemented the necessary features for GBA in the DSP-LLE ROM that is shipped in Dolphin!
This is a big win for usability; users will no longer accidentally have the DSP set to a mode in which GBA <-> GCN will fail. This is one of the most common issues we've seen when helping users through configuring GBA <-> GCN on the forums.
5.0-4171 - VideoConfig: Port to Layered Configuration System by MerryMage¶
One of the most common complaints on the forum we see regarding performance is this: "The game runs like crap, but then I open the graphics menu and I get smooth 60 FPS, 4K, 3D Vision, with advanced CRT shaders and 16x AA on my AMD Phenom II @ 1.125 GHz." Then, a few hours later, "Help! A feature in this game no longer works after I open the graphics menu."
What happened here?
For our example, we're going to focus on one game. Super Mario Sunshine is unique in the series in that one of the main gameplay elements is vandalizing Delfino Island's new paint job with a pressure washer. In accomplishing this incredible style of gameplay, Nintendo had to use some of the GameCube's more unique features. For actually clearing the paint, storing EFB copies to RAM is required. This is a significant performance hit - by switching to Store EFB Copies to Texture performance usually doubles! At first glance, you'd probably think that you've discovered a super amazing performance hack, but once you start playing the game things go wrong. While it appears as though you cleared the paint, the actual paintmap the game uses won't be modified. This means the paint is still there, just invisible.
But this is a global problem that has been plaguing many games in Dolphin for years. Don't believe us?
I'm playing SMG2 and whenever I start the game it runs at a way lower FPS than it should, like 40-50FPS, then as soon as I open the graphics tab it goes back to 60FPS and it's fine, but opening the graphics tab causes the Wiimote to not work until I reset the game, thus making it 40-50FPS again until I open graphics. Why the [redacted] does it run so poorly until I open the graphics tab? Makes no [redacted] sense.
To fix it, i open the graphics window and close it by no changing anything. And, miracle ! i have constant 100% on 3D environnement and all the game. But i have a serious problem: The texture of the map is messed up, like a big square filled of purples things... so i can't use the map.. but the game is still fluid and i can play
I was tweaking my settings in dolphin to see if I could make wind waker faster and I found this strange thing happening. Running the game normally during the intro once it zooms into the island I get about 23 fps until it moves away from it. But if I open the graphics config while it's running it shoots up to 30 fps.
While the game was running (on title sequence), I clicked the toolbar in Dolphin to open the graphics panel - to see if there was something I could do to speed things up. As soon as the panel opened, the framerate jumped to 100%, and the game ran perfectly, and stayed there until I closed the emulation and restarted it. This only seems to work with the graphics panel. Note, I don't change anything - it happens as soon as the panel opens, and as I said everything is stock settings.
Each of these users has unknowningly broken some feature of the game by opening the graphics setting. This is due to how Dolphin's configuration system worked. For as long as Dolphin had existed, Dolphin's config system only had one "layer" - the current user settings. While this was super simple, having to manually change every setting to what each game needed was awful, so a plan to use INI files with game settings (GameINIs) was devised. With only one settings layer available to Dolphin, the GameINIs had to hack their way in and overwrite the user's settings during loading. This worked fine, buuuut inevitably we wanted to do more with it, and it didn't exactly scale. Add in User INIs, netplay settings, DTM settings, command line settings, on and on! With only one settings layer being hacked multiple times, Dolphin had no way to know what the hell was going on. With all of this mess, and no way to keep track of it all, what if users want to change a setting the GameINI has overwritten? The only solution was to have the user settings overwrite the current settings entirely. It worked, but when even Dolphin doesn't know what's going on, there is no way to help users understand what's happening, leading to a great deal of confusion.
Enter MerryMage's (based on existing groundwork by Sonicadvance1, mathieui and leoetlino) start to the new layered configuration system. It's an overlay configuration system with multiple layers - like an onion - and each layer lays over the one beneath it. Even though Dolphin only acts on the final result of all of the layers, each layer exists at all times in the config system, allowing Dolphin to know what settings layer is affecting what and why!
The result of all of this work finally alleviates our graphics configuration problems. When users open up the graphics menu now, the settings will not immediately be overwritten. Instead, any settings that Dolphin has changed itself will be bolded. If users wish to override Dolphin's settings for that session, they still can, but now it has to be a conscious effort.
This should lead to a reduction in confusion among users trying to figure out why performance varies so much despite seemingly running with the same settings.
5.0-4416 - Rewrite SysConf handling by leoetlino¶
One of the most annoying things about importing your real Wii NAND into Dolphin is that most users would have to delete their sysconf file in order to avoid some annoying popups complaining about missing sections. This is because Dolphin couldn't handle missing sections in the sysconf file. NTSC and NTSC-J sysconf files are missing PAL60, and doing a factory reset can remove much, much more. Anything outside of a fully decked out sysconf file would cause a plethora of annoying popups whenever a Wii game was launched and when Dolphin was started/closed.
While this may sound like an easily fixable problem because most of the sysconf handling was hardcoded, leoetlino was forced to do a significant rewrite to sysconf handling in order to rectify the issue. The payoff was well worth it though - Dolphin can now import a NAND image from your Wii and run it correctly without modification, regardless of the region.
5.0-4353 - Gamelist Loading Improvements by shuffle2¶
If you've been keeping up with the latest development builds, you may have noticed that Dolphin doesn't take quite as long to load, especially if you have a large gamelist. While flacs chiseled in some optimization to the gamelist last month, shuffle2 has taken a sledgehammer to it and has cut loading times down by up to 99%!
On a gamelist with over 1200 items spread across several folders, the initial launch has dropped from 3+ minutes to a mere 27 seconds. With a cache, it's dropped from 30+ seconds to instant. This makes testing a large volume of games painless, even when bouncing between multiple builds. If you hate the wait for Dolphin to launch, this is the build for you.
We're getting a lot of mileage out of last month's images. This is not because work has been diverted to a huge feature article.
5.0-4441 - Don't Allocate 100MB of RAM for the Fifoplayer at Startup by lioncash¶
Late Addition: If you read the progress report earlier and didn't see this entry, that's because it wasn't here. Sometimes we miss important changes when scanning through the merges for a month, especially when it's a bit busy with lots of smaller changes.
There's an argument that the most important debugging tool in Dolphin is the Fifoplayer, but, odds are most users don't need to use it all that often. So, why exactly was Dolphin allocating 100MB in RAM for the fifoplayer? While most computers may have more than enough RAM to run Dolphin, this kind of waste is unnecessary and could prove costly on lower-end systems. Even Android builds were affected by this bug!
With this change, starting up a release build of Dolphin goes from roughly 101MB to a mere 5.7MB of memory usage on average.
Note: This memory is now allocated when starting up the Fifoplayer and never unallocated until Dolphin shuts down. So if you're extremely conservative on your memory usage, keep that in mind.
5.0-4575 - Improved Gecko Code Handler by gamemasterplc¶
For people that love to cheat, this is a huge one for you. Dolphin's notorious inability to work with many Gecko codes is frustrating. This is due to a ton of Gecko codes relying on icache behavior that is incredibly expensive to emulate. It's simply not reasonable for us to fix them, and we mostly relied on users making codes that didn't rely on that behavior.
gamemasterplc came up with a different solution that should make everyone happy. Dolphin gets support for the previous broken codes without sacrificing performance by modifying the Gecko code handler to automatically handle the situations that were previously breaking Dolphin.
This enhanced Gecko code handler also brings some extra bonuses to the table, including more code space to allow for bigger codes! If you were having trouble with button-triggered Gecko codes, this is the change you've been waiting to drop!
NOTE: Dolphin's Gecko code handling is still not perfect. Most Wiiware/VC titles and some disc-based titles (such as Arc Rise Fantasia) are not compatible with Dolphin's Gecko code handling for a variety of reasons. This is separate from the code handler change, but, we just wanted to specify that this is not a magic bullet for all issues. Action Replay codes that do not work are unaffected by this change.
5.0-4588 - Ability to Update Wii NAND from Dolphin GUI by leoetlino¶
Dolphin is finally becoming a proper Wii emulator, and part of becoming a proper Wii emulator is removing a lot of the hacks of old. This has unfortunately put us in a place where users who weren't using a dumped Wii NAND were losing out on features that they once were able to use. In order to rectify things, leoetlino has added the ability to update your Wii NAND without a system menu installed. This online update will install all necessary IOSes, default channels, and extract the necessary files from IOSes to access various online services, such as the third-party game servers!
Do note, that on some third-party servers, Dolphin's default ID is banned thanks to people abusing cheats, so not all online services are guaranteed to work without using a privately dumped NAND.
Performing a system update through Dolphin's GUI is much
simpler pinker than doing it through the Wii Menu.
Last Month's Contributors...¶
Special thanks to all of the contributors that incremented Dolphin from 5.0-3977 through to 5.0-4602!