As most of you know, Dolphin was born a GameCube emulator. A lot of its core design and concepts are based around assumptions made that it would only be a GameCube emulator. And, as a GameCube emulator, Dolphin performs admirably, with the ability to boot every single title and a large portion of the library having no major issues.
But, Dolphin isn't just a GameCube emulator. One of the more incredible things about its history is that it was modified into a Wii emulator around the time it went open source in 2008. While the core of the Wii is a supercharged GameCube, and things like CPU and GPU emulation were fairly easy to modify into working with only some minor details changing, there are a lot of quirks around it that have been problematic. Not only are there emulation challenges associated with the Wii that Dolphin side-stepped with some dirty hacks, it also struggled to add on all of the new features of the Wii. For many years, the Wii Remote, GameCube controllers configuration, and GameCube controller settings were completely split apart because Dolphin's UI was not designed with more than one primary input method in mind!
UI Design 101: More menus = better.
Putting all of the options in one place looks better and is easier to use.
In terms of actual emulation, the problems mostly come from the Wii's Starlet ARM coprocessor and everything it brings to the table. To give you an idea of how important Starlet and IOS (Internal Operating System) are on Dolphin, it controls features such as disc access, savegames, networking, USB, ES_Launch (aka, booting games,) and other features necessary for the Wii to function.
Last month, we saw a lot of IOS-HLE improvements, resulting in a big uptick in compatibility. But with these accuracy improvements have come some hiccups and regressions as well. When we fixed The Legend of Zelda: Majora's Mask by using proper, reverse-engineered values for some important IOS-related things, it brought out some regressions too.
Fortsæt med at læse