Dolphin-emu

It's time for us to again delve into the latest changes hitting the newest release of Dolphin Emulator. If you've been keeping tabs on development channels, you'll know there are some exciting bombshell features waiting for us just over the ... [More] horizon. Unfortunately, given the close proximity to this release, we've decided to hold a lot of them off so they can get more widespread testing in the development builds before hitting a release. Think of the March 2025 release as an iterative improvement that focuses on user experience and stacking many small iterative improvements instead of swinging for every homerun. Having said all of that? We do have a few major changes that made the cut. Probably the most requested of the features in this progress report is the ability to finally set custom graphical settings on a per game basis. Our advanced users may be thinking, "Wait, couldn't we already do that?" and they'd be right. The major change here is that per-game graphical settings has been added directly to the game properties page, allowing for a very easy, visual way to change settings and see what settings are force enabled. For our achievement hunters out there, RetroAchievements has seen its first major upgrade that will bring a huge amount of quality of life to many games. And if you're into weird old game behaviors? A developer dove into Summoner: A Goddess Reborn to determine why it crashes so much. The catch with this one? Some of these crashes have been confirmed to happen on official hardware! Additionally, there are a plethora of small, but tangible, changes that are the hallmark of an Open Source project. The desktop versions of Dolphin also saw a lot of improvements to input configuration and a few extra upgrades that might make people who want to track their time spent in games very happy. But, let's not spoil everything and get into the notable changes of the March 2025 release! Notable Changes¶ Cheat Code Whitelist for Hardcore RetroAchievements - 2412-8 and 2412-173 by LillyJadeKatrin¶ RetroAchievements in Dolphin has received its first major update, and it's... cheat support in hardcore?! What gives? Up until around the 7th generation, video game consoles did not have operating systems, and software had complete control over the hardware. While "running on the metal" is simple and efficient, the only security on such systems was the proprietary interfaces needed to load code onto the machine. If someone could fashion a device that could access the memory of one of these consoles, they could do effectively anything. What did gamers do with this incredible power? Cheat at video games of course! An entire cottage industry developed around cheating, with dedicated hardware, companies, jobs, and entire communities, all built on cheats! By the time the GameCube arrived, a cheat device video game enhancer was guaranteed to come out shortly after a console launched, a customer could buy one in the same retail store where they bought the console and buy games, and they could find tens of thousands of codes readily available for free on the internet! For a moment, cheating was mainstream (within the niche market that was video gaming at that time). During this era, the kind of player who would buy a device to cheat at video games was also the kind of player who would dump their games to emulate them on PC. In fact, many game enhancers had the ability to dump games! This overlap made cheat support an essential feature for emulators. Because Dolphin's development began in this era, Dolphin supported Action Replay codes before it supported Wii games. However, cheat systems are still just a way to edit memory. It didn't take long for emulator users to figure out that they could use cheat systems for far more than just cheating at video games. They could use cheats to change the game itself. Widescreen aspect ratio codes, anti-invert stick codes, bloom removal codes - most of the "cheats" being developed today aren't for cheating at all, but to adjust games to better fit modern sensibilities, add quality of life changes, or improve accessibility. When RetroAchievement support in Dolphin launched late last year, cheats and many other features were disabled whenever RetroAchievements' hardcore mode was active. The leaderboard is for those that take achievements seriously and want a record of their accomplishments, so cheats could trivialize their efforts. But once RetroAchievement support was merged, those same overachievers pleaded with RA staff for limited cheat support in hardcore mode. Cheats remain the primary way to patch unfortunate game behaviors and add quality of life improvements, and the hardcore community wanted to be able to utilize those kinds of cheats while climbing the leaderboard. After some deliberation within the RetroAchievements staff, the conclusion was an allowlist. Select and specific cheat codes are now able to be used in RetroAchievements' hardcore mode. Most of them are widescreen aspect ratio codes, but there are other changes as well, such as unlocking the C-Stick to smash feature in single player Super Smash Bros. Melee modes, or codes to fix game issues like freezes and bugs. Now overachievers can enjoy the thrills of Gotta Get 'Em All in the comfort of 16:9. As part of this effort, LillyJadeKatrin went through our wiki looking for cheat codes, then spent hours adding hundreds of new cheats to Dolphin's built in cheat code database. Everyone benefits from this, whether achievement hunting or not! Qt Input Mapping Lightning Round by Billiard¶ For the past couple of months, Billiard has been going through Dolphin's input mapping systems like a storm, cleaning up and improving dozens of things! There are too many for us to even show, but here are some highlights. Note that most of these changes only apply to desktop builds of Dolphin; Android is not affected. — 2412-105 - Make input mapping and output testing non-blocking¶ Input entry is now non-blocking, and multiple input mappings can be queued/un-queued/cleared without locking the UI. Input mapping now feels much more responsive. — 2412-183 - DolphinQt: Replace MappingButton bold text with graphical indicators¶ For years, Dolphin's mapping windows have had some sort of indicator that would light up when the user presses a button that is mapped to an emulated button. This is a quick and easy way to confirm to the user that they have successfully mapped a button and that it is working correctly. However, how that indicator looks and works has changed dramatically. When the mapping indicators were first introduced, they were red graphical indicators that were detached from their associated buttons. When we moved from the WX interface to the Qt interface we now use on desktop, this was changed to lighting up the input within the mapped button itself simply by bolding it. It was never a great solution, but it was good enough and was simple to implement in the storm that was our move to Qt. It left us a little wanting though. Billiard, thinking back to the original design, realized that with Qt, we could do something MUCH better. Dolphin's input indicators are once again graphical! But this time near their associated buttons for high clarity. — 2412-289 - Add setting to enable waiting for alternate mappings¶ Dolphin's advanced mapping window is incredibly powerful, with all of our mapping complexity laid bare and ready for all the input shenanigans a power user could dream of. However, most users don't want to interact with all of our mapping complexity, but they may want to do some basics such as AND and OR. AND was possible simply by pressing two buttons at once, and then it would require the player to press both buttons to send the emulated input, simple. But OR required going into the advanced input mapping window. Given how often users want to be able to press either of two physical buttons to engage single emulated button, Billiard wanted some way to accomodate that without requiring users to plunge into the depths of our mapping system. To achieve that goal, there is now a new option - Wait for Alternate Input Mappings. When this feature is enabled, there is a small delay added after each input, allowing users to make multiple individual inputs. For example, to map two physical buttons to one emulated button, with this feature all a user needs to do is press one button on their controller, then quickly press the next button. Now either input will trigger the emulated button. Simple as that! Wait for Alternate Input Mappings allows for simple OR mapping without confronting the complexity of Dolphin's advanced mapping window. To access this feature, click the arrow beside Refresh. — 2412-292 - Add setting to enable iterative input mappings¶ Iterative input is a nice feature that can take some of the tedium away from configuring a controller. Having to look down, figure out what button you want to push, then use your mouse to go to the next input over and over again can be annoying, especially if you're just trying to set things up as a couch gamer. That's where iterative can really shine. But, unfortunately, its history with Dolphin has been rocky at best. The upside is clear - with just a single click, iterative input allows a user to go through every input on the screen one by one without needing to return to your mouse or keyboard. This feature took so long to return because it's hard to do right, especially with controllers as complicated as the Wii Remote. Last time, problems were revealed and it was easier to remove it outright than to fix it. Billiard has given it another go, with a brand new implementation that doesn't suffer any of the issues of the original. Plus, with the non-blocking changes above, it now is a much smoother experience simply from being implemented now. Iterative input is currently disabled by default, but can be enabled in the controller mapping window. You can now find iterative input by clicking the arrow beside Refresh. — Input mapping expression improvements - 2412-211, 2412-231, 2412-266 and more¶ For our advanced input mapping extraordinaires, Dolphin's input expression parser saw many improvements. Conditional Operator Added Dolphin's mapping expressions have long provided an "if" function for creating conditional expressions: if(`A`, 1.0, 0.6) But this syntax can be cumbersome and unfamiliar, so the ternary conditional operator syntax that's present in many other programming languages has finally been added: `A` ? 1.0 : 0.6 Assignment Operator Fixed Probably unknown to most users, mapping expressions support user-defined variables. These can be used to share state across frames, with other mappings, or just in as a means of organization. This can allow for very customizable and dynamic control schemes. Variables are created with the $ symbol and can be given a value using the familiar assignment operator = . For instance: $x = `A` ? 1.0 : 0.6 Sometimes writers of complex mapping expressions like to describe their calculations as a multiple step process. The comma operator was already provided for this, and functions like it does in other programming languages. This contrived example below effectively does the same thing as the previous example, but in two steps, which can sometimes create more-readable or maintainable code when the calculations get overly long winded. For example: $a = `A`, $x = $a ? 1.0 : 0.6 For technical reasons that we won't get into, the previously mentioned assignment operator was implemented in a manner that did not play nice with the comma operator. It also didn't play nice with other assignment operators. While the operators worked fine in simple use-cases, power users could observe these two operators doing wrong or unexpected things when paired together. All of these *should* evaluate as 1. Comma and assignment operators can now be used together like intended and should do what someone familiar with them would expect them to do, even in complex cases. Compound Assignment Operators Added One final nice-to-have was added to the mapping expressions - compound assignment operators. When altering a user-defined variable based on its current value, the variable name previously always had to be mentioned twice, once on either side of the assignment-operator. Here is an example that reduces the current value of a variable: $x = $x - 0.6 So-called compound assignment operators are now provided to allow this previously verbose syntax to be much more succinct: $x -= 0.6 This syntax can be used with all of the binary operators for which it makes sense: &|^+-*/% 2412-51 - Add ability to edit game-specific GFX settings from game properties tab by TryTwo¶ One thing that many users have been requesting for a very long time is a visual interface for editing per-game settings. While Dolphin has provided a single page with a few key settings, the majority of the settings had to be added via the text editor. The game properties page had limited usefulness, with a lot of the settings available not being useful in the modern era. To address this, we added a built-in text UI that could access just about every feature. Unfortunately, it ended up only useful for advanced users using our wiki as reference. While this change doesn't add everything, now users can set most graphics settings directly in the game properties page. While this functionality already existed by using the text interface, the visual interface makes it easy to see what settings are force enabled, and allows users an easy way to set them without having to memorize the names of the settings. Say hello to the new graphical interface for setting graphics settings. Note that this feature should be considered a work in progress, and the current design may not reflect a more complete solution in the future. 2412-82 - AdvancedWidget: Replace FFV1 codec with Ut Video as Default by TryTwo¶ For those of you who do video dumping in Dolphin, you may have noticed that a lot of modern video editors didn't play nice with the lossless codec in Dolphin. That's because Dolphin used to default to the rather old FFV1 video codec. For TASers or people just wanting extremely high quality footage of the games, it frequently got in their way. Fortunately, an alternative was added a few years ago - the Ut Video codec. This codec is what OBS chose for their lossless recording, granting it extremely widespread compatibility. Despite requiring an INI edit to use in Dolphin, the codec's popularity has compelled us to make the switch. By default Dolphin's lossless frame dumping feature will now use the Ut Video codec for greater compatibility. For those that want to still use FFV1, you still can do that through changing the config file manually. 2412-147 - Fix Summoner: Goddess Reborn sound system crash during transitions by Charlese2¶ Summoner: A Goddess Reborn has been a problematic title in Dolphin since the very beginning. While there were reports that some builds work better than others, the game has never been stable. In fact, playing through it from beginning to end in Dolphin was an arduous experience that meant dealing with crashes and constantly swapping between different CPU clock values in different parts of the game to just for a chance to get to the next section. And now, we finally know why. This game is just broken and you can even cause the same crashes on console! Even here on console, if the user tries to return to the main menu during a transition, Summoner will hang.Click to Play. File has audio. To be completely fair, the game isn't nearly as bad on console. While we did find some consistent crashes that helped us track down this bug, playing through the game isn't nearly as arduous. Still, the very same bug that causes the game to occasionally crash on console is what is causing it to crash in Dolphin, which means there isn't a great chance of us fixing it through emulation changes. Charlese2 said enough was enough and decided to figure out what was going on with this mysterious crash. And within a few days, we had an answer. Summoner: A Goddess Reborn reinitializes its sound system buffers during transitions even if sounds are still being played. If there are still pointers in the sound list to sounds in the buffers when the buffers get cleared, the game crashes with a null pointer dereference. This is a serious bug that should be affecting console at the same rate as Dolphin, but it doesn't. Our best guess is that the Audio Interface DMA interrupt timings are slightly different on console, which causes things to happen in a slightly different order most of the time. However, the bug is there - even in a perfect, cycle accurate emulator, Summoner would occasionally crash if it is not modified. To address this, Charlese2 dove into the game and decided to fix the bug themselves! A lengthy patch (that is enabled by default in the latest builds of Dolphin) cleans up the pending sound list during sound system reinitialization before continuing to the sound system initialization call. With this patch, even known crashes when playing on console are fixed. Now that same scenario will no longer hang in Dolphin, and Summoner successfully reaches the main menu.Click to Play. File has audio. 2412-305 - Track Time Played (Core and Qt) by aminoa¶ Tracking time played is something we almost take for granted these days. Whether you play on a Nintendo Switch, PlayStation, or Steam, all of these platforms track your playtime for all of their titles. It's just expected behavior now. If you were wondering why this report was late, the answer lies in this image. Dolphin however emulates the GameCube and Wii, consoles that came out long before this trend. Unlike modern systems, the GameCube didn't have a clue how many hours you've rolled around at the speed of sound, and the Wii would only show it on a day-by-day basis. But what if Dolphin could track your total play times? And now it can! As of this change, Dolphin can now track the time played for all of its titles and display it in the game list. You can even sort the game list by playtime! Play time tracking is enabled by default, so all it takes to track your time played is a quick update to the latest Dolphin version! If you'd rather not, you can disable it by going to Config > Interface and unchecking Enable Time Tracking. You can also remove the time played column from the game list if you wish without impacting whether or not your play time is tracked. Currently only our Qt graphical interface can display play time. NOTE: Time played can only be tracked in 2412-305 and newer. 2412-321 - TAS: Use Improved Wii Remote Data Format by Billiard¶ For our TASers that need to use Wii Remotes, this is a long overdue change. For a basic rundown, when a person makes a Tool-Assisted Speedrun (TAS), they're essentially creating a long string of controller inputs that, when played back, completes a game quickly or accomplishes some other impressive feat. These controller inputs have to be stored in some way so they can be played back later. Like most emulators, Dolphin has a custom file format for this, and it's called DTM (Dolphin TAS Movie). It's a relatively simple format: 256 bytes of metadata and settings, followed by all the controller inputs and nothing else. Depending on how optimized you intend your TAS to be, you might use Dolphin's input recordings alongside slowdown, frame-by-frame, savestates, or even rely on scripts (using specialized TASing forks) that generate inputs through bruteforcing across hundreds of hours! This video shows just what's possible with a Tool-Assisted Speedrun/Superplay. Can you figure out how they beat the entirety of Wind Waker (no barrier skip) only pausing twice the entire game? Dolphin's DTM format was originally designed for GameCube controllers and works fairly well for them. For Wii Remotes, the format has been quite a bit more cumbersome. Wii Remotes are a nightmare for emulation on a level that no controller before them can match. The Bluetooth connectivity is annoying, you can swap attachments, it has an infrared receiver, a small amount of EEPROM, battery levels, and of course, its signature motion controls. In fact, a Wii Remote collects so much data that it can't be sent all at once! Games that support Wii Remotes have to tell them what reporting mode to use, with different reporting modes sending different data and using different levels of precision. And to make things even tricker, Nintendo decided to encrypt data from extension controllers. We don't know if this was to make things harder for third-party controller manufacturers or for some other reason, but we do know that it has made things harder both for TASers and Dolphin developers! How do you bolt all of this into a format that was designed for GameCube controllers? Dolphin's solution was to store data in the same format a Wii Remote would send it, using whatever reporting mode the game specified. This did work, but came with a lot of consequences. At the start of a recording, you'd be locked into your Wii Remote configuration. You couldn't change attachments during a recording, and manually editing DTM files in a hex editor was almost impossible. The reason for this was that the game could change reporting modes throughout a playthrough, and if the wrong sort of data was provided at the wrong time, the game would refuse to accept it. This is how hard DTM files with GameCube controller inputs are to read. Now imagine what it would be like to have encrypted data in the mix too! But it didn't have to be this way. When Wii Remotes were added to netplay, they suffered from all of these problems (and more!) which made Wii netplay into a nightmare. But, eventually AdmiralCurtiss addressed a lot of these issues to make Wii Remote netplay slightly more tolerable. The new system, rather than naively copying the Wii Remote data as-is, used an intermediary structure that can then be translated into the game-requested format on the fly. This elegant solution allows the input data to be manipulated without fear of breakage from the ever-changing game state. On top of significantly improving stability, it gave support for more games by allowing users to change attachments mid-session. While it may not seem like it at first glance, a lot of what netplay does overlaps with "movie" support which is used for TASing. They both require absolute determinism, recording inputs, and playing back inputs. When looking for ways to improve things for TASers, Billiard realized that AdmiralCurtiss's netplay improvements were never ported over to movies! He decided to replace the old way of storing Wii Remote data in DTM files with netplay's intermediary format, bringing many of the improvements over. We're hoping that this new format makes creating optimized Wii TASes easier and more stable. On the Dolphin side of things, it was also a maintenance win. A bunch of ugly code related to reporting modes and extension data encryption became unnecessary and was removed. As per usual, if you've started a TAS on an older build of Dolphin, you're more-or-less stuck there. Not only is the new DTM format incompatible with the old one, any minor change to Dolphin could break the syncing of a TAS. When creating a new TAS, please ensure that the build of Dolphin you're using supports the feature set you need to accomplish your goals. This goes for whether you're using an official build of Dolphin or a scripting fork. And for the TASers out there doing crazy things in Dolphin, we're always looking forward to seeing what you do next. This Release's Contributors...¶ Special thanks to all of the contributors that incremented Dolphin by 341 commits after Release 2412! [Less]

It's time for us to again delve into the latest changes hitting the newest release of Dolphin Emulator. If you've been keeping tabs on development channels, you'll know there are some exciting bombshell features waiting for us just over the ... [More] horizon. Unfortunately, given the close proximity to this release, we've decided to hold a lot of them off so they can get more widespread testing in the development builds before hitting a release. Think of the March 2025 release as an iterative improvement that focuses on user experience and stacking many small iterative improvements instead of swinging for every homerun. Having said all of that? We do have a few major changes that made the cut. Probably the most requested of the features in this progress report is the ability to finally set custom graphical settings on a per game basis. Our advanced users may be thinking, "Wait, couldn't we already do that?" and they'd be right. The major change here is that per-game graphical settings has been added directly to the game properties page, allowing for a very easy, visual way to change settings and see what settings are force enabled. For our achievement hunters out there, RetroAchievements has seen its first major upgrade that will bring a huge amount of quality of life to many games. And if you're into weird old game behaviors? A developer dove into Summoner: A Goddess Reborn to determine why it crashes so much. The catch with this one? Some of these crashes have been confirmed to happen on official hardware! Additionally, there are a plethora of small, but tangible, changes that are the hallmark of an Open Source project. The desktop versions of Dolphin also saw a lot of improvements to input configuration and a few extra upgrades that might make people who want to track their time spent in games very happy. But, let's not spoil everything and get into the notable changes of the March 2025 release! Release 2503a¶ On April 21 2025, we created Hotfix Release 2503a to fix some problems that snuck into Release 2503: Fixed a bug that caused GBA connectivity in some games to not work properly. Fixed a bug where Dolphin would crash with a memory error on some older macOS versions. Fixed an problem with our build system which caused Release 2503 to be mislabeled as a 2412 development build on some platforms. Notable Changes¶ Cheat Code Whitelist for Hardcore RetroAchievements - 2412-8 and 2412-173 by LillyJadeKatrin¶ RetroAchievements in Dolphin has received its first major update, and it's... cheat support in hardcore?! What gives? Up until around the 7th generation, video game consoles did not have operating systems, and software had complete control over the hardware. While "running on the metal" is simple and efficient, the only security on such systems was the proprietary interfaces needed to load code onto the machine. If someone could fashion a device that could access the memory of one of these consoles, they could do effectively anything. What did gamers do with this incredible power? Cheat at video games of course! An entire cottage industry developed around cheating, with dedicated hardware, companies, jobs, and entire communities, all built on cheats! By the time the GameCube arrived, a cheat device video game enhancer was guaranteed to come out shortly after a console launched, a customer could buy one in the same retail store where they bought the console and buy games, and they could find tens of thousands of codes readily available for free on the internet! For a moment, cheating was mainstream (within the niche market that was video gaming at that time). During this era, the kind of player who would buy a device to cheat at video games was also the kind of player who would dump their games to emulate them on PC. In fact, many game enhancers had the ability to dump games! This overlap made cheat support an essential feature for emulators. Because Dolphin's development began in this era, Dolphin supported Action Replay codes before it supported Wii games. However, cheat systems are still just a way to edit memory. It didn't take long for emulator users to figure out that they could use cheat systems for far more than just cheating at video games. They could use cheats to change the game itself. Widescreen aspect ratio codes, anti-invert stick codes, bloom removal codes - most of the "cheats" being developed today aren't for cheating at all, but to adjust games to better fit modern sensibilities, add quality of life changes, or improve accessibility. When RetroAchievement support in Dolphin launched late last year, cheats and many other features were disabled whenever RetroAchievements' hardcore mode was active. The leaderboard is for those that take achievements seriously and want a record of their accomplishments, so cheats could trivialize their efforts. But once RetroAchievement support was merged, those same overachievers pleaded with RA staff for limited cheat support in hardcore mode. Cheats remain the primary way to patch unfortunate game behaviors and add quality of life improvements, and the hardcore community wanted to be able to utilize those kinds of cheats while climbing the leaderboard. After some deliberation within the RetroAchievements staff, the conclusion was an allowlist. Select and specific cheat codes are now able to be used in RetroAchievements' hardcore mode. Most of them are widescreen aspect ratio codes, but there are other changes as well, such as unlocking the C-Stick to smash feature in single player Super Smash Bros. Melee modes, or codes to fix game issues like freezes and bugs. Now overachievers can enjoy the thrills of Gotta Get 'Em All in the comfort of 16:9. As part of this effort, LillyJadeKatrin went through our wiki looking for cheat codes, then spent hours adding hundreds of new cheats to Dolphin's built in cheat code database. Everyone benefits from this, whether achievement hunting or not! Qt Input Mapping Lightning Round by Billiard¶ For the past couple of months, Billiard has been going through Dolphin's input mapping systems like a storm, cleaning up and improving dozens of things! There are too many for us to even show, but here are some highlights. Note that most of these changes only apply to desktop builds of Dolphin; Android is not affected. — 2412-105 - Make input mapping and output testing non-blocking¶ Input entry is now non-blocking, and multiple input mappings can be queued/un-queued/cleared without locking the UI. Input mapping now feels much more responsive. — 2412-183 - DolphinQt: Replace MappingButton bold text with graphical indicators¶ For years, Dolphin's mapping windows have had some sort of indicator that would light up when the user presses a button that is mapped to an emulated button. This is a quick and easy way to confirm to the user that they have successfully mapped a button and that it is working correctly. However, how that indicator looks and works has changed dramatically. When the mapping indicators were first introduced, they were red graphical indicators that were detached from their associated buttons. When we moved from the WX interface to the Qt interface we now use on desktop, this was changed to lighting up the input within the mapped button itself simply by bolding it. It was never a great solution, but it was good enough and was simple to implement in the storm that was our move to Qt. It left us a little wanting though. Billiard, thinking back to the original design, realized that with Qt, we could do something MUCH better. Dolphin's input indicators are once again graphical! But this time near their associated buttons for high clarity. — 2412-289 - Add setting to enable waiting for alternate mappings¶ Dolphin's advanced mapping window is incredibly powerful, with all of our mapping complexity laid bare and ready for all the input shenanigans a power user could dream of. However, most users don't want to interact with all of our mapping complexity, but they may want to do some basics such as AND and OR. AND was possible simply by pressing two buttons at once, and then it would require the player to press both buttons to send the emulated input, simple. But OR required going into the advanced input mapping window. Given how often users want to be able to press either of two physical buttons to engage single emulated button, Billiard wanted some way to accomodate that without requiring users to plunge into the depths of our mapping system. To achieve that goal, there is now a new option - Wait for Alternate Input Mappings. When this feature is enabled, there is a small delay added after each input, allowing users to make multiple individual inputs. For example, to map two physical buttons to one emulated button, with this feature all a user needs to do is press one button on their controller, then quickly press the next button. Now either input will trigger the emulated button. Simple as that! Wait for Alternate Input Mappings allows for simple OR mapping without confronting the complexity of Dolphin's advanced mapping window. To access this feature, click the arrow beside Refresh. — 2412-292 - Add setting to enable iterative input mappings¶ Iterative input is a nice feature that can take some of the tedium away from configuring a controller. Having to look down, figure out what button you want to push, then use your mouse to go to the next input over and over again can be annoying, especially if you're just trying to set things up as a couch gamer. That's where iterative can really shine. But, unfortunately, its history with Dolphin has been rocky at best. The upside is clear - with just a single click, iterative input allows a user to go through every input on the screen one by one without needing to return to your mouse or keyboard. This feature took so long to return because it's hard to do right, especially with controllers as complicated as the Wii Remote. Last time, problems were revealed and it was easier to remove it outright than to fix it. Billiard has given it another go, with a brand new implementation that doesn't suffer any of the issues of the original. Plus, with the non-blocking changes above, it now is a much smoother experience simply from being implemented now. Iterative input is currently disabled by default, but can be enabled in the controller mapping window. You can now find iterative input by clicking the arrow beside Refresh. — Input mapping expression improvements - 2412-211, 2412-231, 2412-266 and more¶ For our advanced input mapping extraordinaires, Dolphin's input expression parser saw many improvements. Conditional Operator Added Dolphin's mapping expressions have long provided an "if" function for creating conditional expressions: if(`A`, 1.0, 0.6) But this syntax can be cumbersome and unfamiliar, so the ternary conditional operator syntax that's present in many other programming languages has finally been added: `A` ? 1.0 : 0.6 Assignment Operator Fixed Probably unknown to most users, mapping expressions support user-defined variables. These can be used to share state across frames, with other mappings, or just in as a means of organization. This can allow for very customizable and dynamic control schemes. Variables are created with the $ symbol and can be given a value using the familiar assignment operator = . For instance: $x = `A` ? 1.0 : 0.6 Sometimes writers of complex mapping expressions like to describe their calculations as a multiple step process. The comma operator was already provided for this, and functions like it does in other programming languages. This contrived example below effectively does the same thing as the previous example, but in two steps, which can sometimes create more-readable or maintainable code when the calculations get overly long winded. For example: $a = `A`, $x = $a ? 1.0 : 0.6 For technical reasons that we won't get into, the previously mentioned assignment operator was implemented in a manner that did not play nice with the comma operator. It also didn't play nice with other assignment operators. While the operators worked fine in simple use-cases, power users could observe these two operators doing wrong or unexpected things when paired together. All of these *should* evaluate as 1. Comma and assignment operators can now be used together like intended and should do what someone familiar with them would expect them to do, even in complex cases. Compound Assignment Operators Added One final nice-to-have was added to the mapping expressions - compound assignment operators. When altering a user-defined variable based on its current value, the variable name previously always had to be mentioned twice, once on either side of the assignment-operator. Here is an example that reduces the current value of a variable: $x = $x - 0.6 So-called compound assignment operators are now provided to allow this previously verbose syntax to be much more succinct: $x -= 0.6 This syntax can be used with all of the binary operators for which it makes sense: &|^+-*/% 2412-51 - Add ability to edit game-specific GFX settings from game properties tab by TryTwo¶ One thing that many users have been requesting for a very long time is a visual interface for editing per-game settings. While Dolphin has provided a single page with a few key settings, the majority of the settings had to be added via the text editor. The game properties page had limited usefulness, with a lot of the settings available not being useful in the modern era. To address this, we added a built-in text UI that could access just about every feature. Unfortunately, it ended up only useful for advanced users using our wiki as reference. While this change doesn't add everything, now users can set most graphics settings directly in the game properties page. While this functionality already existed by using the text interface, the visual interface makes it easy to see what settings are force enabled, and allows users an easy way to set them without having to memorize the names of the settings. Say hello to the new graphical interface for setting graphics settings. Note that this feature should be considered a work in progress, and the current design may not reflect a more complete solution in the future. 2412-82 - AdvancedWidget: Replace FFV1 codec with Ut Video as Default by TryTwo¶ For those of you who do video dumping in Dolphin, you may have noticed that a lot of modern video editors didn't play nice with the lossless codec in Dolphin. That's because Dolphin used to default to the rather old FFV1 video codec. For TASers or people just wanting extremely high quality footage of the games, it frequently got in their way. Fortunately, an alternative was added a few years ago - the Ut Video codec. This codec is what OBS chose for their lossless recording, granting it extremely widespread compatibility. Despite requiring an INI edit to use in Dolphin, the codec's popularity has compelled us to make the switch. By default Dolphin's lossless frame dumping feature will now use the Ut Video codec for greater compatibility. For those that want to still use FFV1, you still can do that through changing the config file manually. 2412-147 - Fix Summoner: Goddess Reborn sound system crash during transitions by Charlese2¶ Summoner: A Goddess Reborn has been a problematic title in Dolphin since the very beginning. While there were reports that some builds work better than others, the game has never been stable. In fact, playing through it from beginning to end in Dolphin was an arduous experience that meant dealing with crashes and constantly swapping between different CPU clock values in different parts of the game to just for a chance to get to the next section. And now, we finally know why. This game is just broken and you can even cause the same crashes on console! Even here on console, if the user tries to return to the main menu during a transition, Summoner will hang.Click to Play. File has audio. To be completely fair, the game isn't nearly as bad on console. While we did find some consistent crashes that helped us track down this bug, playing through the game isn't nearly as arduous. Still, the very same bug that causes the game to occasionally crash on console is what is causing it to crash in Dolphin, which means there isn't a great chance of us fixing it through emulation changes. Charlese2 said enough was enough and decided to figure out what was going on with this mysterious crash. And within a few days, we had an answer. Summoner: A Goddess Reborn reinitializes its sound system buffers during transitions even if sounds are still being played. If there are still pointers in the sound list to sounds in the buffers when the buffers get cleared, the game crashes with a null pointer dereference. This is a serious bug that should be affecting console at the same rate as Dolphin, but it doesn't. Our best guess is that the Audio Interface DMA interrupt timings are slightly different on console, which causes things to happen in a slightly different order most of the time. However, the bug is there - even in a perfect, cycle accurate emulator, Summoner would occasionally crash if it is not modified. To address this, Charlese2 dove into the game and decided to fix the bug themselves! A lengthy patch (that is enabled by default in the latest builds of Dolphin) cleans up the pending sound list during sound system reinitialization before continuing to the sound system initialization call. With this patch, even known crashes when playing on console are fixed. Now that same scenario will no longer hang in Dolphin, and Summoner successfully reaches the main menu.Click to Play. File has audio. 2412-305 - Track Time Played (Core and Qt) by aminoa¶ Tracking time played is something we almost take for granted these days. Whether you play on a Nintendo Switch, PlayStation, or Steam, all of these platforms track your playtime for all of their titles. It's just expected behavior now. If you were wondering why this report was late, the answer lies in this image. Dolphin however emulates the GameCube and Wii, consoles that came out long before this trend. Unlike modern systems, the GameCube didn't have a clue how many hours you've rolled around at the speed of sound, and the Wii would only show it on a day-by-day basis. But what if Dolphin could track your total play times? And now it can! As of this change, Dolphin can now track the time played for all of its titles and display it in the game list. You can even sort the game list by playtime! Play time tracking is enabled by default, so all it takes to track your time played is a quick update to the latest Dolphin version! If you'd rather not, you can disable it by going to Config > Interface and unchecking Enable Time Tracking. You can also remove the time played column from the game list if you wish without impacting whether or not your play time is tracked. Currently only our Qt graphical interface can display play time. NOTE: Time played can only be tracked in 2412-305 and newer. 2412-321 - TAS: Use Improved Wii Remote Data Format by Billiard¶ For our TASers that need to use Wii Remotes, this is a long overdue change. For a basic rundown, when a person makes a Tool-Assisted Speedrun (TAS), they're essentially creating a long string of controller inputs that, when played back, completes a game quickly or accomplishes some other impressive feat. These controller inputs have to be stored in some way so they can be played back later. Like most emulators, Dolphin has a custom file format for this, and it's called DTM (Dolphin TAS Movie). It's a relatively simple format: 256 bytes of metadata and settings, followed by all the controller inputs and nothing else. Depending on how optimized you intend your TAS to be, you might use Dolphin's input recordings alongside slowdown, frame-by-frame, savestates, or even rely on scripts (using specialized TASing forks) that generate inputs through bruteforcing across hundreds of hours! This video shows just what's possible with a Tool-Assisted Speedrun/Superplay. Can you figure out how they beat the entirety of Wind Waker (no barrier skip) only pausing twice the entire game? Dolphin's DTM format was originally designed for GameCube controllers and works fairly well for them. For Wii Remotes, the format has been quite a bit more cumbersome. Wii Remotes are a nightmare for emulation on a level that no controller before them can match. The Bluetooth connectivity is annoying, you can swap attachments, it has an infrared receiver, a small amount of EEPROM, battery levels, and of course, its signature motion controls. In fact, a Wii Remote collects so much data that it can't be sent all at once! Games that support Wii Remotes have to tell them what reporting mode to use, with different reporting modes sending different data and using different levels of precision. And to make things even tricker, Nintendo decided to encrypt data from extension controllers. We don't know if this was to make things harder for third-party controller manufacturers or for some other reason, but we do know that it has made things harder both for TASers and Dolphin developers! How do you bolt all of this into a format that was designed for GameCube controllers? Dolphin's solution was to store data in the same format a Wii Remote would send it, using whatever reporting mode the game specified. This did work, but came with a lot of consequences. At the start of a recording, you'd be locked into your Wii Remote configuration. You couldn't change attachments during a recording, and manually editing DTM files in a hex editor was almost impossible. The reason for this was that the game could change reporting modes throughout a playthrough, and if the wrong sort of data was provided at the wrong time, the game would refuse to accept it. This is how hard DTM files with GameCube controller inputs are to read. Now imagine what it would be like to have encrypted data in the mix too! But it didn't have to be this way. When Wii Remotes were added to netplay, they suffered from all of these problems (and more!) which made Wii netplay into a nightmare. But, eventually AdmiralCurtiss addressed a lot of these issues to make Wii Remote netplay slightly more tolerable. The new system, rather than naively copying the Wii Remote data as-is, used an intermediary structure that can then be translated into the game-requested format on the fly. This elegant solution allows the input data to be manipulated without fear of breakage from the ever-changing game state. On top of significantly improving stability, it gave support for more games by allowing users to change attachments mid-session. While it may not seem like it at first glance, a lot of what netplay does overlaps with "movie" support which is used for TASing. They both require absolute determinism, recording inputs, and playing back inputs. When looking for ways to improve things for TASers, Billiard realized that AdmiralCurtiss's netplay improvements were never ported over to movies! He decided to replace the old way of storing Wii Remote data in DTM files with netplay's intermediary format, bringing many of the improvements over. We're hoping that this new format makes creating optimized Wii TASes easier and more stable. On the Dolphin side of things, it was also a maintenance win. A bunch of ugly code related to reporting modes and extension data encryption became unnecessary and was removed. As per usual, if you've started a TAS on an older build of Dolphin, you're more-or-less stuck there. Not only is the new DTM format incompatible with the old one, any minor change to Dolphin could break the syncing of a TAS. When creating a new TAS, please ensure that the build of Dolphin you're using supports the feature set you need to accomplish your goals. This goes for whether you're using an official build of Dolphin or a scripting fork. And for the TASers out there doing crazy things in Dolphin, we're always looking forward to seeing what you do next. This Release's Contributors...¶ Special thanks to all of the contributors that incremented Dolphin by 341 commits after Release 2412! [Less]

Dolphin 2412 is here and we've got the details for what's new in the latest release. The biggest thing to note is that there's a lot of polishing to help make playing games a little more pleasant. Several key fixes to Dolphin's HLE audio ... [More] helps bring a few more games toward audio perfection, and adjustments to Dolphin's CPU <-> GPU syncing reduces the number of harmless, but annoying, popup errors that happen in certain games. That isn't to say there aren't any titles seeing significant improvements. LIT (School of Darkness) had a unique problem that exposed yet another unemulated hardware behavior. And if you're looking for a deep dive into problematic behavior in a game? We have one of those as well. Eternal Darkness has been a thorn in our side the past couple of months and required some special attention to get working again in time for this release. For details on all that and more, join us for Release 2412's Notable Changes! Notable Changes¶ All of the changes below are available in Release 2412. 2409-17 - DSP-HLE: Fix Low Pass/Biquad Clipping by Tilka¶ Tilka has been perfecting DSP-HLE over the last few years. A majority of their changes have been minor and fix subtle effects that most users won't notice unless they've recently played the game on console with a high-end sound system. In the last progress report, we covered their implementation of the Zelda microcode's low-pass and biquad filters, but we didn't mention that Tilka also took the time to implement the biquad filter in the AX microcode! Doing so fixed an issue in I SPY: Spooky Mansion where the wind was too loud. Unfortunately, it also started causing issues in Need for Speed: Nitro's audio. Your browser does not support the audio element. Whenever the player activated nitro, the engine noise would be really loud with occasional crackling. Your browser does not support the audio element. This is how it should sound. Thankfully, the issue was found relatively quickly after it was reported. The implementation of the filters didn't take into account that the real AX microcode was using the DSP's set40 (40-bit sign extension) mode, which caused some calculations to be incorrect. After fixing an off-by-one error and adding some clamping, Need for Speed: Nitro's issues were resolved. 2409-71 - Auto IR Size - Fix Bounding Box Corruption by TellowKrinkle¶ Since the epic battle against Bounding Box that lasted throughout a good chunk of 2021, our foe has remained mostly subdued. But much like Bowser inevitably returns again and again after being defeated by Mario Luigi, a Bounding Box issue has risen from the ashes. Unlike previous Bounding Box issues, this one wasn't as simple to reproduce. Users have been reporting it for a better part of the year, but upon actually trying to investigate it, the issue would often disappear. We did know that it wasn't specific to any particular bounding box title. It could happen in Disney's Magical Mirror: Starring Mickey Mouse all the way to the most complicated of Bounding Box games, Paper Mario: The Thousand Year Door. The only constant was that resetting the user's graphics settings would permanently fix the issue. Something was interacting poorly with Bounding Box, but we didn't know what. Paper Mario: The Thousand-Year Door behaves very strangely if there's a problem with Bounding Box. On the issue tracker, ZephyrSurfer eventually managed to figure out that the issue centered around Dolphin's Auto IR (Internal Resolution) setting. Auto IR lets Dolphin automatically set the internal resolution based on the size of the window or full-screen monitor (rounded to the closest whole multiple). Users who don't want to mess with their settings can just set this and forget it. The key discovery that had us realize it was the problem was that changing the window size while the game was running was all it took for the affected users to reproduce. In order to get this fixed, TellowKrinkle jumped in and analyzed the issue. He figured out that Dolphin was forgetting to mark the pixel shader manager as dirty when changing the window size with Auto IR. Essentially, Dolphin is letting the GPU driver know that scaling values used for the bounding box calculation in the pixel shader have changed in RAM, so that the GPU driver will send the data to VRAM again. Because Dolphin wasn't doing that, all bounding box calculations were using the old internal resolution even after the window size changed. Oops. A simple one line change later and Bounding Box works correctly when using Auto IR. 2409-84 - Linux + NVIDIA + Vulkan - Fix Deadlock by TellowKrinkle¶ Around March of this year, several of Dolphin's developers on Linux began noticing that they shared a rather inconvenient issue. When using the Vulkan video backend with proprietary Nvidia drivers, attempting to resize the game window while emulation was running would often completely lock up Dolphin's UI. The deadlock was quickly traced to a call to the vkWaitForFences function in the Vulkan backend's command buffer manager. Seeing this, Pokechu22 joined the conversation and dug deeper to figure out what sequence of events was causing the blockage. Eventually, it was discovered that a call to the vkAcquireNextImageKHR function was failing in a way that was not being handled entirely correctly, leaving a semaphore unsignaled forever. With a cause found, it was time to bisect recent changes to figure out which one was to blame for it. What happened next was unexpected. Every build that could be tested, going as far back as The Great VideoCommon Unification of 2019, was exhibiting this deadlock. But hang on, wasn't this a relatively recent issue? Something wasn't adding up, and without an obvious mistake to fix, the case went cold. As JMC47 was reviewing TellowKrinkle's fix for auto IR size, he naturally needed to test resizing the game window. However, as a developer on Linux using the Vulkan backend, he had to pause emulation before doing so in order to prevent the deadlock from occuring. It became such a nuisance that he brought it up in conversation on the official Dolphin Discord server. This time, the issue caught the attention of CasualPokePlayer, who joined the conversation after independently discovering the problem that Pokechu22 found earlier. Already knee-deep in graphics backend work and aided by CasualPokePlayer's insight, TellowKrinkle decided he should remedy this issue once and for all. Amazingly, he was able to put together a working solution all while being unaffected by the issue himself! Once it was confirmed to work by other developers who were affected by the issue, the fix was in. The exact source of the Linux + NVIDIA + Vulkan deadlock was still a mystery even though it was already fixed. However, after a bit of digging, we found the smoking gun. In the changelog for Nvidia's Linux x64 (AMD64/EM64T) Display Driver 550.54.14 from February 23, 2024, it says this: Fixed a bug where vkAcquireNextImageKHR() was not returning VK_ERROR_OUT_OF_DATE_KHR when it should with WSI X11 swapchains. This error code being returned by the vkAcquireNextImageKHR function was one of the symptoms that was observed while debugging this deadlock! Does that mean that this version of the proprietary Nvidia driver broke Dolphin? We installed an older version of Dolphin and various proprietary Nvidia driver versions onto a fresh copy of Debian Linux to find out. ✅ 550.54.14 from February 23, 2024, the aforementioned version, would deadlock. ❌ 550.40.07 from January 24, 2024, the preceding version and the first beta of the 550 series, would not deadlock. ✅ 565.57.01 from October 22, 2024, the latest beta version, would deadlock. ❌ 535.216.01 from October 22, 2024, the latest long-term support version at the time of writing, would not deadlock. It's also worth noting that the vkAcquireNextImageKHR function in driver versions without the deadlock would always return VK_SUCCESS, even while aggressively resizing the game window. So, in conclusion, every proprietary Nvidia driver from the 550 series and onward (excluding the first 550 beta version) exhibits this new behavior has to be accounted for by Dolphin. 2409-150 - Cache Normals in Addition to Binormals and Tangents by pokechu22¶ Nowadays, it's rare that Dolphin sees an actual core emulation change to fix a game, but it still happens occasionally! We recently received an issue report that the WiiWare title LIT (known as School of Darkness in Japan) had severe graphical issues in Dolphin involving the text on its map and menu screens. Sure, it's the school of darkness, but it isn't supposed to be this dark! When pokechu22 looked into the issue, they found that the devs at WayForward accidentally enabled lighting when rendering the text. The geometry which made up the text also didn't include any normals, which are used when calculating lighting. If a normal vector isn't specified and lighting is enabled, Dolphin uses a default value of (0, 0, 0) in lighting calculations. This is what results in the text showing up as all black. But why doesn't the bug appear on real hardware? To figure out why, pokechu22 used the fifoplayer to reproduce the problem on an actual Wii and wrote some hardware tests. They found that when lighting is enabled without any corresponding normals, a real Wii GPU instead reuses the last normal it received. In LIT, the last valid normal vector sent to the GPU is (0, 0, 1), which comes from rendering the map's background. Using this value in the lighting calculations allows the text to show up with its intended color. After normal vector caching was implemented in Dolphin, the text was fixed! Ah, that's better. This GPU quirk is actually similar to one that was abused by Factor 5 in the Rogue Squadron series for bump mapping. In those games, Factor 5 sends a single dummy triangle containing common bi-normal and tangent vectors to the GPU, and then sends the actual geometry which relies on the vectors but doesn't include them. As the GPU reuses the bi-normal and tangent vectors from the dummy triangle when rendering the real geometry, the game doesn't need to send them multiple times. This saves memory and improves performance. 2409-161 - Fix Some Common Opcode Decoding Errors by Tilka¶ One of the highest levels of accuracy in emulation is when an emulator is deemed "cycle accurate." Assuming all things are handled properly, a cycle accurate emulator will, in theory, allow a game to run exactly the same as it would on original console. This would include things like framerate lag, timing issues, race conditions, and everything else you'd expect. Given identical start states, an input recording from a cycle accurate emulator would play back exactly the same on the original console. This is how we have console verified Tool Assisted Speedruns on many older consoles. Dolphin isn't cycle accurate and doesn't try particularly hard to reach cycle accuracy. Why is that? Obtaining cycle accuracy is a ton of work and a lot slower than just using estimations. Just emulating a few pieces of cycle accuracy (such as the CPU instruction pipeline, cycle timings, and various cache hits/misses) is arduous and would massively reduce performance. And that's only just part of what we'd need for one component. Cycle accurate GameCube/Wii emulation is a long ways off for the purpose of actually playing games. Dolphin is a general use emulator that wants to be as accurate and compatible as it reasonably can while maintaining good performance. All throughout Dolphin you'll find tons of tradeoffs between accuracy, performance, and compatibility. Many of the most accurate options in Dolphin are disabled by default to keep performance at an acceptable level. For something like cycle timings, Dolphin just tries to get close enough. On the GameCube/Wii CPU, how many cycles an instruction can take varies greatly. Sometimes the code might hit the L1/L2 cache, sometimes it won't. Sometimes the instructions around an instruction can reduce the number of cycles it takes to execute that instruction! And that's just what we as blog writers can understand about it. The actual details are frightening, but what you need to know is that Dolphin just fudges the numbers to get reasonably close and most games are fine with this. The amusing thing about Dolphin's estimations is that it will sometimes be a little faster than console, and sometimes a little slower. A good example of a scenario where Dolphin is slower is the video player in Tales of Symphonia. The video decoding logic is super optimized for the GameCube's CPU, and Dolphin's estimations on how many cycles can be used per frame is off by enough to cause stuttering during playback. Note that Tales of Symphonia is only being used as an example of the problems that can happen with a non-cycle accurate emulator, and this particular problem is not being addressed at this time. By default, the FMVs will be a bit rough in Dolphin. By increasing the emulated CPU clock, you can make them silky smooth. For the GameCube/Wii, there are also other complications, with one of them being CPU <-> GPU communication. How fast each runs and how often they are allowed communicate can greatly affect both compatibility and performance. Too little communication and interrupts can get missed or fired at the wrong time, and the state that each component is in might not match what they are expecting! Warning: Dual Core Rant Dual core is a performance hack that allows Dolphin to separate the CPU and GPU emulation into their own threads and let them run independently of one another (with occasional synchronization points). Because they are running at the same time and synchronization has to be kept at a minimum in order to gain performance, it is entirely possible that performance hiccups can cause one thread to fall too far behind the other. And because the actual state of the component can be affected, these are slowdowns that the emulated software can actually feel! Depending on how sensitive a game is to these problems, they may be perfectly stable in dual core, or entirely unusable to the point where it has to be force disabled. There are also interesting cases where some games are perfectly fine as long as the host computer is fast enough. Fire Emblem: Path of Radiance is perfectly stable when using dual core on most devices, but becomes unstable on the extremely low-end hardware that needs dual core the most. Developers have tried to fix dual core in the past, however all of the attempts have either greatly reduced dual core's performance advantage while still not matching single core's compatibility, or further reduced its compatibility in exchange for determinism. Dual Core as it is has proven hard to replace despite the downsides. Single core does not have these problems at the expense of running both the CPU and GPU threads on the same core. Performance hiccups cannot leak through to the emulated software and stability is essentially guaranteed, or at least guaranteed to be consistent in cases where something is broken. The following explanation describes single core's deterministic way of syncing the CPU and GPU works. Dolphin switches between emulating the CPU and emulating the GPU in set intervals. As a balance between accuracy and performance, Dolphin doesn't swap every emulated cycle. Instead, Dolphin emulates the CPU and GPU in time slices. Essentially, Dolphin will let GPU commands accumulate in memory for 1000 cycles, and then make the GPU catch up. However, when Dolphin is emulating the GPU, there is a possibility that the data at the end of that command stream doesn't form a complete command yet. If that happens, and the game reconfigures the location in memory from where the GPU reads the command stream, then that incomplete command can be combined with a new unrelated command! When this happens, there's a chance that this new command could become an unknown opcode that causes an annoying popup for users. In order to fix this, Tilka changed it so Dolphin now forcibly processes all pending GPU commands if the game reconfigures the location in memory that it is reading from. Doing this fixes unknown opcode popups in over 20 games! Bass Pro Shops games (The Hunt, The Strike, etc) Captain America: Super Soldier Country Dance 2 Def Jam Rapstar Disney Guilty Party Food Network: Cook or Be Cooked! Ghostbusters: The Video Game Metroid Prime Mushroom Men: The Spore Wars Nickelodeon Dance Nickelodeon Dance 2 PDC World Championship Darts 2009 PDC World Championship Darts: Pro Tour Pékin Express Resident Evil Zero Rogue Trooper: Quartz Zone Massacre Roogoo: Twisted Towers Star Wars: The Force Unleashed II Super Monkey Ball: Banana Blitz The Baseball 2003 - Battle Ball Park Sengen Perfect Play Pro Yakyuu Thor: God of Thunder Victorious: Taking the Lead Wipeout: The Game and many more... Note that almost all of these unknown opcodes were non-fatal and mostly just an annoyance for users. Still, the fact they were popping up showed that emulation was problematic to some degree in these titles. Overall, we expected this change to boost our accuracy without introducing any regressions. As an added bonus, the changes to the command processing allows Harvest Moon: Tree of Tranquility to finally boot without green flashes in single core mode. 2409-268 - GamePatch: Fix Opcode Decoding Regression in Eternal Darkness by Tilka¶ The previous change tightened up Dolphin's CPU/GPU synchronization to prevent unknown opcodes. There's no way that could cause a regression, right? ... Whelp. One of the potential issues with making timings more accurate is that sometimes you break things that shouldn't have been working, but were working for the wrong reasons. In this case, Eternal Darkness started hanging on boot. Dual core always got stuck when booting Eternal Darkness, but after years of jealousy, single core decided it wanted to hang even earlier on start up. The previous opcode decoding fixes were an improvement to overall accuracy, so Tilka didn't want to revert them because of one game. That meant diving into Eternal Darkness in a way no one else ever had. As with many of the remaining broken games, Dolphin was only half of the problem. The other half was actually an issue in the game itself. Make no mistake - with the opcode decoding fixes, Dolphin was now emulating the game closer to how it would run on console. However, by being closer, it was now triggering a race condition that would never happen on real hardware. In order to explain this issue, we have to get a bit messy with an in-depth explanation. If you're not interested in the internal behavior of this game's FIFO, feel free to skip the next two paragraphs. In essence, Eternal Darkness has a race condition within its graphics rendering code. It uses the GXSetDrawDone function to add a draw done command to the command stream, which makes the GPU raise an interrupt when executed. Some time after adding the command, it then reconfigures the GPU command stream. As previously mentioned, Dolphin wouldn't properly execute commands at the end of the stream. This meant that the draw done command was never executed and the interrupt was never raised. Because of that, the game didn't hang in Dolphin! Wait, what? The difference between Dolphin and real hardware is that an actual GameCube GPU would always raise the draw done interrupt before Eternal Darkness has a chance to change the command stream address. Without the opcode decoding fixes, the draw done interrupt would never be raised due to its command being ignored, avoiding the race condition altogether. However, with the opcode decoding fixes, we now get interesting behavior that's closer to console but still not quite correct. This time, all the GPU commands are processed as per normal and the draw done command is executed. However, because our cycle timings are inaccurate, Dolphin has a hack that delays raising the draw done interrupt by a minimum of 500 cycles. This hack gives games some time to finish any necessary setup that may not be finished if the interrupt is raised immediately. Eternal Darkness is able to change the GPU command stream address during the delay. When the interrupt is finally raised 500+ cycles later, the game promptly hangs because the code that handles the interrupt doesn't expect a different command stream address at that point in time. This hang is technically a game bug, albeit one that never manifests on real hardware. We could change the 500 cycle delay until we found a number that won the race, but we ultimately decided not to make an arbitrary decision like that based on the results of one game. Instead, Tilka made a patch for Eternal Darkness to replace the problematic GXSetDrawDone function with the safer GXDrawDone, which forces the game to wait for the interrupt to be raised before it can proceed. This is an incredibly efficient fix, as it comes with no performance cost, doesn't require any change to Dolphin itself, and means we won't break any other games while trying to find a delay that works for Eternal Darkness. Correct emulation would require incredibly small GPU slices which would drag down performance of the emulator in general. To prevent any confusion surrounding this regression, the patch has automatically been enabled in the latest release for all regional variants of the game. If you wish to disable the patch or view what patches are available for other games, simply access the game properties page and go to the "Patches" tab. 2409-181 - DSP-HLE: Fix Wii Remote Audio in Multiple Games by Tilka¶ The Wii Remote is a rather complex controller to emulate. It has attachments, a weird layout, motion controls, a small amount of savedata, infrared, and even a speaker! The speaker part of the Wii Remote is one of its more forgotten features simply because most games used it for entirely optional sound flourishes (the Wii allows the player to turn the speaker off), and the speaker itself was rather puny. When using an emulated Wii Remote, Dolphin pumps the Wii Remote speaker data to the standard audio output device. However, when using Real Wii Remotes or Bluetooth Passthrough, Wii Remote audio can work in Dolphin just as it does on console. In fact, with Bluetooth Passthrough and a strong enough adapter, you can enjoy the same mediocre sound quality as console! The fact this feature has been so maligned is why very few people noticed or cared that Wii Remote audio was very broken in some games. For a revision of the AX microcode used early in the Wii's lifecycle, there were some serious bugs in our DSP-HLE implementation: The size difference between the high-pass and biquad filter was not accounted for, causing adjacent memory to become corrupted. The Wiimote sample buffer pointers were advanced by 32 samples per millisecond instead of 6 samples. Any audio corruption caused by this was usually hidden by the first bug. PB updates on Wii were being byte-swapped twice. However, no games that use this feature were found. While we don't know if the third bug affected any games, the first two affect a lot of games released between 2006 and 2007. Tilka gave us an example list of games that they noted are fixed by their changes: Excite Truck Ice Age 2: The Meltdown Kororinpa: Marble Mania Rapala Tournament Fishing Shrek the Third Super Monkey Ball: Banana Blitz Tiger Woods PGA Tour 07 WarioWare: Smooth Moves Wing Island maybe more? Fun fact - WarioWare: Smooth Moves was the only one of these titles with an active issue report saying that Wii Remote audio was broken. Also, games that use the Zelda microcode were not affected by these bugs. For example, The Legend of Zelda: Twilight Princess was not affected despite being released in 2006. 2409-260 - Add manifest for building as a Flatpak by cpba¶ Unlike Windows and macOS, there isn't a single OS that you can point to and call "Linux". Instead, when a user wants to run Linux on their system, they are able to choose between many different "flavours" of Linux known as distributions. Each distribution bundles the Linux kernel together with a set of packages containing various drivers, software, libraries, frameworks, and more. There are many benefits to this system. For example, a user can choose a distribution that is tailored to their own needs. Newbies might gravitate towards beginner-friendly distributions like Ubuntu, while more advanced users may prefer distributions that offer lots of customizability, like Arch Linux or NixOS. However, this system also comes with several disadvantages. The biggest issue relevant to us at Dolphin is that each distribution tends to have its own vision for how software should be packaged and installed on the system. They also update their packages independently of each other, meaning that one distribution could have the most up to date version of a specific framework, while another distribution is stuck on an out of date version. Unfortunately for app developers, all these factors make it difficult to create a single build of an app that can run across every possible Linux distribution. As a result, creating desktop apps on Linux has historically been a bit of a mess. While Dolphin has offered official builds for Ubuntu in the past, those builds wouldn't install on other non-Ubuntu distributions, and would only be guaranteed to work correctly on the specific Ubuntu version that it was built for. After we stopped offering official Ubuntu builds, our policy has been to just let each distribution be responsible for producing their own Dolphin builds. If a Linux user wanted to install Dolphin, they would either need to compile it themselves or use the package from their distribution. Linus Torvalds, the creator of Linux, once described the process of making Linux app builds as "a major #$@&ing pain in the %@$". In an attempt to solve the problem, several competing solutions for packaging Linux apps with cross-distribution compatibility have emerged over the past decade. One of these solutions is known as Flatpak. Flatpak allows a developer to build their app against a common base "runtime", which contains all of the libraries and frameworks that an app may need. When an app is installed, its corresponding runtime is also downloaded and installed along with it. Since all of the dependencies are found in the runtime or bundled with the app itself, a Flatpak build of an app doesn't rely on the packages provided by the installed distribution! The distribution just has to support the Flatpak system itself. But why are we choosing to make Flatpak builds over all of the other competing solutions? The answer lies in the Steam Deck. Valve has adopted Flatpak as the official way to install non-Steam apps on SteamOS. When a user wants to install something that isn't available on the Steam Store, all they have to do is switch to Desktop Mode and open the Discover Software Center. There, they can find a plethora of software available for download in the Flatpak format, including many emulators! Apps in Flatpak format are most commonly distributed by repositories, and the largest Flatpak repository is known as Flathub. The Steam Deck has Flathub installed by default, which is what allows users to instantly get access to a large library of Flatpak software. Surprisingly, Dolphin is actually one of the oldest apps that was added to Flathub. Ever since Flathub launched in 2017, a group of dedicated individuals has been maintaining an unofficial Flatpak version of Dolphin! When we heard about this, it only made sense that we ask them for assistance in making our own Flatpak builds. With the help of cpba and ColinKinloch, all of the necessary files to create Flatpak builds have now been merged into the upstream Dolphin repository. OatmealDome completed the necessary infrastructure work to allow our Buildbot CI to create Flatpak builds. You can now add one of the following repositories to install our Flatpak builds: Release builds: https://flatpak.dolphin-emu.org/releases.flatpakrepo Development builds: https://flatpak.dolphin-emu.org/dev.flatpakrepo Alternatively, you can also download single-file bundles for specific builds on our downloads page. While we're launching our Flatpak builds with this report, we should note that there's a slight catch. The builds found on Flathub are still unofficial due to some pending changes to our infrastructure and various important people being away on vacation. (Yes, eagle-eyed readers, this is also why Dolphin isn't verified on Flathub yet.) We hope to have this fixed soon! And to all of our AppImage fans: we're aware of the demand. We want to work on getting Flatpak up and running first. 2409-303 - Sync GPU just before PI_FIFO_RESET by Tilka¶ Noooooo! Just when we thought we were done, we were pulled back in. After all of the work Tilka did to reduce the number of unknown opcode errors that games would spew, we started seeing the worrying trend of new unknown opcode errors popping up across more games. Fortunately, none of these were fatal and almost every one centered around closing games. New Super Mario Bros. Wii was the first culprit reported, so Tilka conducted an investigation to figure out what was going on. If you've been reading the rest of the progress report, then you'll remember that in single core, Dolphin lets GPU commands accumulate in memory for 1000 cycles. There's something we didn't mention earlier, though: every now and then we also copy these commands from the game's memory into a Dolphin-internal buffer, partially to hide from the game that we're letting many commands accumulate. When processing these commands, we look at the Dolphin buffer first, and then whatever is in the game's memory. If the console is asked to shut down, New Super Mario Bros. Wii calls GXAbortFrame to stop rendering the current frame and reset the GPU. When this happens, Dolphin empties its internal buffer but doesn't empty the game's memory as well. The last bytes seen by the opcode decoder could be a partial command in the internal buffer followed by bytes from commands in memory that were not cleared! In order to prevent command buffer execution from resuming in the middle of a command, Dolphin now allows the GPU to catch up to the CPU's reality and then resets the internal buffer. That means if there are only a few commands left to process, they will go through fine and there will be no problems. Because the target of this fix was New Super Mario Bros. Wii's regression, we weren't expecting to fix any previously broken games. To our surprise, it turns out this flaw was causing problems across several games, even under the old GPU syncing behavior! Deadliest Catch - Sea of Chaos G.I. Joe - The Rise of Cobra Monster 4x4 - World Circuit The Oregon Trail If you're keeping count, this means that Tilka has improved compatibility across at least thirty-four games for this release! Unfortunately, this solution is a stop gap. The core issue of the internal buffers being cleared without clearing the game's buffer still exists. If a lot of GPU commands have been accumulated, problems can still occur. This is what causes SpongeBob SquarePants featuring Nicktoons: Globs of Doom to be broken in the latest release version. Tilka also conducted additional hardware testing and found some additional behavior that needs to be implemented. We'll hopefully have all these improvements in a future release. 2409-313 - Fix Kirby's Adventure Wii MetaFortress Bypass Patch by vaguerant¶ The name MetaFortress should ring a bell to long-time readers. For the unfamiliar, MetaFortress was an anti-piracy system used by a handful of games on the Wii. We previously covered MetaFortress's presence in the all-time classic game The Smurfs: Dance Party back in 2017: Defeating Anti-Piracy with The Smurfs: Dance Party While modern versions of Dolphin are able to handle MetaFortress's anti-piracy checks, we still include patches for bypassing MetaFortress entirely in some games. While MetaFortress's primary purpose is to check for piracy, it also does some trickery to detect if the game itself has been modified, just in case any of its anti-piracy checks were patched out. This can cause problems when making cheats and mods for MetaFortress-protected titles, as modifying the game's code could trip MetaFortress. One of the games that we ship a MetaFortress bypass patch for is Kirby's Return to Dream Land (also known as Kirby's Adventure Wii in Europe). Unfortunately, when the patch was ported from the North American version to the European version, some mistakes were made in the porting process. If a user enabled the MetaFortress bypass patch and tried starting the game, it would hang on a black screen due to some patch addresses being incorrect. A lone user did report on the forums that the patch was broken earlier this year, but their post unfortunately fell through the cracks. vaguerant independently discovered that the European version of the MetaFortress bypass patch was broken and took it upon themselves to fix it. With this change, we hope that the scourge of MetaFortress has now been defeated once and for all. Casual readers beware!¶ The following two sections cover changes to Dolphin's debugging interface, a normally hidden suite of tools used for deep-dives into the workings of emulated software. If this does not interest you, then that concludes today's Progress Report! Feel free to skip ahead for this release's contributors and a special message regarding the Stop Killing Games campaign. ... Are you still here? Well then, let's get technical! 5.0-21724 - Branch Watch Tool: Add Set Breakpoints Submenu and 2409-15 - Branch Watch Tool: Refactors, Fixes, and Features by mitaclaw¶ Dolphin 5.0? What is a feature from that era doing in this progress report? Well, you may remember the Branch Watch Tool from its showing in the progress report for February, March, and April. Determined to make it feature-complete, mitaclaw continued building upon this reverse-engineering tool in the months following its release. The goal was to finish both of these improvements in time for the September progress report, but unfortunately the second pull request just barely missed the deadline. Thus, we're covering them both now! As with the existing features of the Branch Watch Tool, a tutorial on the operation of these new features can be found in the Branch Watch Tool's menu bar, under Tool > Help. The first new addition to the Branch Watch Tool is the ability to set instruction breakpoints en masse from a row selection. This is potentially useful when a number of branch candidates are found, but the order in which they are hit is in question. Additionally, the context menu shows if the locations selected already have breakpoints set; the large circle icon indicates every location already does, while the small square icon indicates only some locations do. The second new addition to the Branch Watch Tool is more ways to inspect conditional branch candidates. Before, all one could do was replace a conditional branch with a no-operation instruction (nop). This is equivalent to forcing a conditional branch to always take its false path, but now one can also force a conditional branch to always take its true path by making it unconditional. But that's not all! For any conditional branch, one can now invert the branch's condition (turning beq into bne, ble into bgt, and so on) or invert the branch's decrement check (turning bdnz into bdz, and vice versa). We hope these new features are helpful to anyone who uses the Branch Watch Tool for research and development. 2409-216 - DolphinQt: JIT Widget Refresh by mitaclaw¶ Among the likes of the code widget or the memory widget, there is the lesser-known JIT widget. Made to assist Dolphin's developers in understanding the output of its just-in-time recompiler, the JIT widget has an incredibly niche userbase. After all, only a fraction of Dolphin's developers are interested in working on the JITs! Thus, it should not be surprising that the JIT widget has not evolved much since its conception. Dolphin 2.0 (released 2010) Dolphin 2409 (released 2024) Apart from surviving the migration from DolphinWX to DolphinQt, the JIT widget's design and features have remained in 2008*. In its current form, the JIT widget does not display the far-code cache—a memory region where lesser-used recompiled code is sent to—as it predates the concept by nearly six years! What's more, using the JIT widget with the Cached Interpreter results in nonsense, as it predates that CPU emulation engine by nearly seven years! The large table consuming a great deal of space in the JIT widget is, and always has been, a placeholder! It would take a developer seriously interested in Dolphin's JITs and in writing Qt widgets for the JIT widget to get the update it deserves. Luckily, that developer has arrived. While mitaclaw was working on his software JIT profiling restoration, which was featured in a previous progress report, he was simultaneously overhauling the JIT widget to make this profiling data easier to view while also fleshing out this skeleton of a widget. So, what does the JIT widget look like now? Pro-tip: click on the status bar to show JIT memory stats if they are currently hidden by instruction count stats. Packed with new features, it's a huge improvement! For the first time, a list of every cached block of recompiled code is displayed by the JIT widget. It is also now possible to erase selected blocks of recompiled code from the JIT's cache, forcing them to be recompiled again for debugging purposes. The "PPC vs Host" action available from the code widget's context menu, which in the past was the only route to the functionality of the JIT widget, has been generalized as a filter option in the JIT widget (the "Recompiles Physical Address" input field). Finally, the missing support for the far-code cache and the Cached Interpreter has been addressed. Our hope is that, for the few people this drastic overhaul matters to, it can greatly benefit their work. This Release's Contributors...¶ Special thanks to all of the contributors that incremented Dolphin by 323 commits after Release 2409! What's Up with the Blue Banner?¶ You might have noticed that we've added a banner for the Stop Killing Games movement at the top of this website. If you're curious why, we'd like to take the opportunity to explain in a format less cramped than a small banner. 2024 has been a year of bad news for the emulation scene. Nintendo not only forced Switch emulator Yuzu and Switch emulator Ryujinx to shut down, but also hit 3DS emulator Citra as collateral damage. The US Copyright Office refused to let researchers remotely access emulated versions of out-of-print copy-protected video games even though it's already allowed for other forms of media. And Sega will delist SEGA Mega Drive & Genesis Classics from Steam on December 6, one of the few ways to legally get direct downloads of ROM files. All of this goes to show that corporations in general don't really care if people can still play old games. Sure, the big classics like Super Mario Bros. will probably keep getting rereleases in perpetuity, but a lack of financial incentive for rereleasing less popular games has led an estimated 87 percent of older games to go out of print. The community is eager to help preserve video games, but they're held back by the current state of copyright law, and if you ask the Entertainment Software Association (the video game industry's lobbying organization in the United States), they'd very much like to keep the law as it is. But still - at least for older consoles - the emulation scene is alive and kicking. For newer consoles, even if emulators aren't being developed right now, that time can come in the future. And even though old games can be hard to legally get hold of for the average person, the history of the console space so far has shown that few video games are at risk of being completely lost to time. With one big exception: online-only games. In the year the GameCube launched, console games that let you connect to the internet were a rarity, and popular PC games like Counter-Strike expected you to host your own server if you wanted to play online. Today, fueled by the rise of live service games, many multiplayer games can only be played by going online and connecting to the publisher's servers. There are now even single-player games that require a connection to a server! The mobile market is even worse, as games that can be played offline are the exception to the rule there. This is inconvenient if you don't have a reliable internet connection or if there are server outages, but the insidious part is what happens once the publisher loses interest in the game. Not only do they stop selling the game, but because they also shut down the servers, every copy of the game becomes unplayable in one fell swoop. Emulators aren't of much help when a game doesn't even work on the original hardware! This is what the Stop Killing Games movement wants to stop. Their position is that when you buy a game as a one-time purchase, the company behind the game shouldn't be allowed to later render it unplayable. They're presenting the problem not only as a matter of game preservation but a matter of consumer rights, and through that angle, they're trying to get through to lawmakers and consumer protection agencies. Depending on the laws of your country, when you buy a product, it usually comes with some kind of warranty where if the product breaks within a certain timespan due to a defect that's the manufacturer's fault, they have to repair the product or refund you. But what about when you buy a live service game? The game's servers might shut down at any time, and you usually won't know the date until the shutdown is already imminent. So far, games companies haven't gotten any real pushback from consumer protection agencies for this. In more concrete terms, the movement is trying to create change in two ways right now, both of which are detailed on the Stop Killing Games website. The first is asking consumers who bought the recently shut down Ubisoft game The Crew to complain to their consumer protection agency. The second is petitioning legislators in various countries. In particular, their European Citizens' Initiative is currently ongoing, and the petition of theirs is the most likely to end up making a change. But it has a tough goal to meet: one million signatures. The outcome of Stop Killing Games won't directly affect Dolphin, since GameCube and Wii games aren't being made anymore. But as a project that would like to see video games both from the past and the future preserved, we recommend that you sign their European Citizens' Initiative if you can! Note that you must be an EU citizen to sign. Does it matter if I sign?¶ Yes! This isn't some change.org petition where nothing in particular is guaranteed to happen. If a European Citizens' Initiative hits one million signatures, it will be taken to the European Commission. The Commission isn't guaranteed to turn the proposal into law - they'll first thoroughly evaluate the proposal, and then decide what they think is best to do - but other European Citizens' Initiatives have led to real change before. And the EU is no stranger to taking a stand against big tech companies to improve things for consumers and fight planned obsolescence. But if the one million mark isn't reached, nothing will happen... Except maybe video game companies looking at the hundred thousands strong signature count and ceding some ground? How would this even work? Would publishers have to keep servers online forever?¶ No, they wouldn't be required to keep servers online forever. The proposal by Stop Killing Games would still allow selling games that require a connection to the publisher's servers, and would still allow the publisher to shut down those servers whenever they want to end support for the game. But before they would be allowed to shut down the servers, they would have to take steps to make the game playable without any connection to the publisher. There's various ways to accomplish this, and they're free to choose whichever one suits a given game best. For instance, for a single-player game, they could release a patch that makes the game playable offline. Or for a multiplayer game, they could release the server software, or create a patch that lets the game host matches peer-to-peer. The requirement would be to keep the major functionality of the game working, with the company having an option to leave out less critical parts like matchmaking or leaderboards. It would mean extra work for companies that make live service games, that's true. But it would take much less work if the game is designed with the requirement in mind to begin with, and the requirement isn't much more onerous than some other regulations live service game developers have had to deal with for the benefit of users, like the GDPR. And in the end: do we want a world where consumers buy games that might stop working at any time, where people making games are spending their time and effort on something the publisher will erase from existence as soon as it's no longer profitable, and where old games won't be available for the next generation of players? If we don't, then that extra bit of work is necessary. [Less]

After an exciting round of feature articles, it's Progress Report time once again! However, a lot has changed. Dolphin has finally left the 5.0 era behind, and has entered the Release Era. Not only did we get our first release in eight years ... [More] , but we also established a commitment to continuous releases going forward. For the Reports, things will be more or less the same, but with a few changes. Progress Reports are now also release changelogs. We'll be going over the notable additions and changes between each release in every Progress Report going forward, rather than within a range of dates. As such, the name of the Reports will reflect the release accompanying it - if you want the new features, just update to the version at the top or higher and you'll have them! (However, since 2407 had a release article without a changelog, this Report will be covering the changes in both Release 2407 and Release 2409.) That also means that the next release is happening right now! Accompanying this report is Dolphin 2409. It is now rolling out via our updater, and is available for download here on our website. But there was also another feature article since our last Report. Dolphin now has RetroAchievements support! For those waiting for it to show up in a release build, the wait is now over. Throughout the past couple of months, we've ironed out one major issue alongside many smaller issues with RetroAchievements. The first iteration of RetroAchievements in a release build is stable, but not all that flashy. The groundwork is there for future improvements, but many features and options are yet to be finished. As well, Android support is still deadlocked with a few issues. Please pardon our progress! We have a bunch of cool statistics from the RetroAchievements team regarding the launch, however, we need to get on with the Report! So just click this handy link to be taken to the bottom of the Report if you'd like to read more! But before we get to the Notable Changes, we have a couple of things to cover. Google Play Update Delay¶ Last month, we got a surprise email from Google Play saying that Dolphin doesn't comply with their policies because it "installs, but doesn't load". We have gotten emails like this before regarding Android TV, presumably because someone at Google tried to install Dolphin on one out of the vast majority of Android TV devices that don't meet Dolphin's hardware requirements, but this is the first time we've gotten a rejection for Android as a whole. Seeing as Dolphin generally does load correctly on devices that are able to install it, we're not quite sure what happened here. What does this mean for Dolphin? Dolphin is still available on Google Play, but the next update we release has to be manually checked by Google before it becomes available to users. Because of this, it will take longer than normal for the 2409 release to show up on Google Play, but any updates after that should be smooth sailing again. If you're impatient and want the latest version of Dolphin right now, it's available on this website as always! Visual Studio Twenty-Twenty-Woes¶ During the rollout of the latest release, a lot of people updated Dolphin for the first time in a while! But for some of our Windows users, when they fired up Dolphin 2407 for the first time they were met with a silent crash. They reached out to us, and the support vanguards on our Discord quickly found a solution - reinstalling the 64-bit Microsoft Visual C++ redistributable for Visual Studio 2022 got Dolphin working for them once again. We're not entirely sure why exactly this happened. But we have a theory. The Visual C++ 2022 Redistributable is a runtime library that contains everything needed to run programs compiled with Microsoft Visual Studio 2022. However, Visual Studio 2022 is not static: there are many subversions, and it gets regular updates. These updates should be backwards compatible with any other version of Visual Studio 2022. It would be madness to make a change to Visual Studio 2022 that breaks compatibility with Visual Studio 2022's own runtime libraries. However, Microsoft did exactly that. In Visual Studio 2022 v17.10.0, Microsoft made a non-backwards compatible change to std::mutex::lock. This was reported to Microsoft, however, the issue report was marked as "Closed - Not a Bug". Apparently this was intended! This puts us, as an application that uses Visual Studio, into a weird place. We set up an automated process to update our Visual Studio builder to new subversions as they come out, confident that it will never break anything. It's just subversions. So we have told our Windows users that all they need to run Dolphin is the Visual C++ 2022 Redistributable, confident that it would work. However, Visual Studio automatically utilized the new version of std::mutex::lock when compiling our Windows builds. If a user is running an older version of the Visual C++ 2022 Redistributable before that new version of std::mutex::lock was implemented, they may download and run our program and see a silent crash. And of course, if we ask them if they are using the Visual C++ 2022 runtime, they'll say yes, because they have it installed. According to Microsoft, this is our problem. Their expectation is for applications to be distributed with installers that will include the redistributable and install it with the app if required. However, they hand out the redistributable to users precisely for applications like us that ship without an installer. It's not like what we're doing is novel. And perhaps Microsoft should have made it fail in a way that communicates to the user that they need to update the redistributable, instead of just crashing silently? Or perhaps just include the Visual C++ 2022 runtime libraries in Windows Update so every user is guaranteed to have the latest version and applications don't even need to worry about it? ...Anyway, unfortunately, we don't have a great solution for this issue. We could disable our automated update process for our Visual Studio builder, but there are security benefits to keeping it, so this is something we'd rather not do. For now, all we can tell our Windows users is that if you run a new version of Dolphin and encounter a crash, redownload and reinstall Visual C++ 2022 Redistributable. As always, we have a link to the redistributable on our download page. On a happier note, it's time for our Notable Changes! Notable Changes¶ All of the changes below are available in Release 2409. 5.0-21462 - Windows: Remove rounded corners on emulation render window by Filoppi¶ When Windows 11 released in late 2021, it brought the first major visual overhaul to Windows since Windows Phone from 2010. Gone were the sharp edges, bold colours, and dense squares of the Live Tile era, and in their place were soft tones, spacious design, and friendly round edges. However, as part of this new aesthetic, Windows 11 applies round edges everywhere, even to game windows! Pixels that your computer spent your hard-earned money rendering are now hidden in windowed mode by default. At 200% UI scale, Windows 11's rounded corners obscure 112 pixels! With an 8x native window, 0.0005% of your pixels cannot be viewed! What?! This was unacceptable! Recognizing this travesty, Filoppi came to the rescue and saved our pixels. By configuring DWM_WINDOW_CORNER_PREFERENCE in our Windows builds, all pixels that Dolphin renders (on Windows 11 and in windowed mode) are now once again free to be seen by our illustrious eyeballs. Now Windows 11 users in windowed mode can savour every single pixel of this beloved masterpiece. If only such relief could be bestowed upon our macOS users as well... Balloon Tooltip Quality of Life Updates - 5.0-21123, 5.0-21635, and 2407-130 by Dentomologist¶ A few years ago we introduced our custom balloon tooltips. Rather than have a large description area permanently taking up space or a terrible native tooltip defined by the OS, we created our own custom tooltips that gave us the best of both worlds. Rather than taking up all this space all the time... Modern tooltips let us only display it when required! They have been serving us well since. However, after they were rolled out for the graphics area of our config, they haven't really been touched since then. Now that's changing, and our Balloon Tooltips are finally getting some much needed love and a wider rollout! First is 5.0-21123, which reworked how they are drawn to resolve many longstanding quibbles with the tooltips. The corners on the tooltips have always been a bit.. off. Now they are much improved! Next is 5.0-21635, which added tooltips to the Interface tab of Config. And finally 2407-130, which rolls out our tooltips to the General tab of Config! Dentomologist is still chipping away at the tooltips, so expect them to continue to improve and be applied to more windows over time! 2407-103 - Cached Interpreter 2.0 by mitaclaw¶ After the merge of "Cached Interpreter 2.0", we've seen some misinformation floating around emulation communities regarding what the cached interpreter is and what this change has brought. So for the Progress Report, we felt it was prudent to take a deep dive, and properly explain a bunch of concepts we've been putting off for years now. Strap in everyone, we're going deep! The primary task of CPU emulation is translation: we take code that was originally designed for a specific type of CPU and translate it into something that a different type of CPU can understand. This is not free. Even ignoring the work involved in the act of translating in and of itself (more on that later), having to account for hardware differences means that the resulting translated code will usually be many times larger and more complex than the original code was on the original hardware. As such, there are many different approaches to CPU emulation. Interpretation is the most basic and literal CPU translation method. An interpreter decodes each individual instruction from the emulated architecture (guest), then translates that into the instructions (plural) that allow the host to perform the same work. And yes, it translates one instruction at a time. This is extremely accurate (able to preserve all nuance) and very straightforward, making interpreters the perfect entry point for most emulators and a fallback for other translation methods. However, interpreters are so straightforward that they have barely any wiggle-room for optimization. Interpreters will always be costly. Recompilation gives us that wiggle-room. By translating the code in blocks rather than per instruction, recompilers can peek into what the code is doing and reimplement troublesome code in ways that are faster for the host hardware. However, reimplementation often causes inaccuracy, and correcting for that without sacrificing speed leads to ballooning complexity. Making a recompiler both fast and accurate can easily take thousands of hours from passionate engineers. There are many different types of recompilers, but we're just going to focus on the primary recompiler type that Dolphin uses: JITs. Just-In-Time Recompilation (JIT) recompiles small blocks of code while the program is running. A JIT will fetch blocks of code from the program, analyze and reimplement as much as it can, then pass the JITed code to the host system to be processed and ready just before the program needs to consume those blocks. "Just-In-Time" is literal. This is an accurate representation of how JITs work. The live analysis that JITs perform is overhead. While modern JITs will mitigate this somewhat by caching JITed code blocks, the analysis is still work, which some other recompilation techniques avoid. However, JITs have many benefits. By recompiling blocks of code while the program is running, JITs are able to adapt to whatever the program is doing and don't need to rely on assumptions. This allows for maximum optimization potential, even in self-modifying programs! With that, we've covered the two most common CPU emulation techniques. Generally, there is nothing inbetween these two options. Emulator authors make an interpreter first, and use it as a reference for building a recompiler. And that's it. Recompilers are so much faster than interpreters that making an interpreter faster is largely irrelevant. There are several reasons for this. For example, interpreters can't place guest registers into the host registers, so any time the emulated CPU wants to read its registers, an interpreter has to fetch the registers' contents from host system memory, which is two orders of magnitude slower. Also, for Dolphin, our interpreter has the MMU enabled at all times, and the constant memory manipulation is even slower in the interpreter than it is for a JIT! However, what slows down interpreters the most is branching. In computer science, a branch is the act of diverging from the current flow of instructions. If a CPU is executing instructions sequentially, it can process them very very fast. But if an unpredictable branch occurs, the CPU will need to stop everything, flush all its pipelines, and spend the next 10-20 cycles building them back up again before it can resume processing. Branching is one of the most expensive low level operations in computing! As such, modern CPUs do everything they possibly can to improve branch performance, with branch prediction and speculative branch execution trying to get ahead of any branches and keep the pipelines flowing. These features are so important that improved branch prediction is one of the primary reasons why a 2024 CPU core at 4ghz is faster than a 2004 CPU core at 4ghz. It's that significant. By operating on each instruction from the guest, one at a time, an interpreter will need to branch very frequently - several times for even a single instruction. And these branches are usually unpredictable, directly hurting what makes modern CPUs fast. With all factors combined and in a worst case scenario, a single instruction from the guest could take over a hundred cycles for our interpreter to decode! This occurs millions of times per second, thrashing our host CPU. Interpreters are simple, straightforward, and readable, but they are fundamentally inefficient. A recompiler will always be faster, so there is little incentive to make an interpreter faster. Except, perhaps, for fun. Nine years ago, degasus had a fun idea. How fast could an interpreter be made (while still being an interpreter) if we applied a bunch of ideas from JITs? The result of this little experiment was the Cached Interpreter. With a JIT, code is collected into blocks and recompiled into host-specific machine code all together. This allows the JIT to reimplement some of the code to be faster for the host, but also allows the JIT to cache these JITed code blocks, so that any time code is reused, the JIT will just jump to the cache and skip the analysis for a speedup. Dolphin's Cached Interpreter borrows this idea. Code is collected into blocks exactly like a JIT. However, rather than recompile it into JITed machine code, which is specific to the host and may be reimplemented, the code block is instead translated into an intermediate representation - code which stores the decoded instructions as "commands" that can be compiled into machine code that the host CPU can run. This benefits our Cached Interpreter in many ways. Just like a JIT, the code blocks can be cached. Any time code reappears, the Cached Interpreter can just reuse the already decoded version in the cache, skipping the decode and all its associated branching. The act of interpreting in blocks rather than per instruction also reduces branching outright, down to roughly one branch per command, and makes branches more predictable too. This also reduces the cost of fetching instructions through the MMU, and brings several other benefits from the JIT, such as Idle Skipping. * All combined, the Cached Interpreter was over twice as fast as our interpreter when it released! However, it was still an order of magnitude slower than our JITs. For most users, it was more or less irrelevant. However, the Cached Interpreter has found its niches. As it is still an interpreter, it retains the impeccable accuracy that interpreters provide, as well as the ability to run on any architecture - it's our interpreter, but faster. As such, it has become a useful tool for testing and JIT development. Plus, in situations where JIT recompilers are unavailable, the substantial speedup versus the standard interpreter is always welcome. But what if the Cached Interpreter could be taken further? Fast forward to 2024, and mitaclaw and Sam-Belliveau got into a competition to see just how optimized the Cached Interpreter could be. Eventually they merged their efforts, in what mitaclaw dubbed Cached Interpreter 2.0. This change brought many optimizations to the Cached Interpreter, but the biggest change by far was variable sized commands. Previously, the commands inside the Cached Interpreter's intermediate representation had a fixed size, but mitaclaw and Sam-Belliveau realized that by allowing the commands to be any size, the most common bookkeeping commands could be bundled together into a single command. This significantly reduces the number of bookkeeping commands in total, further reducing the amount of branching in our Cached Interpreter. Just how big of an impact could these optimizations have? Let's get to the numbers! With a 10 to 25% uplift, the Cached Interpreter is better than ever! It's also now 3 to 4 times faster than the interpreter, and in games with lots of idle loops to skip, such as Cave Story, Cached Interpreter leaves our interpreter in the dust. However, our JITs are still MUCH faster in every scenario, so its role in Dolphin is unchanged. The Cached Interpreter still cannot serve as a JIT alternative. And according to mitaclaw, further optimizations had a negligible impact on its performance. Dolphin's Cached Interpreter will likely not see another significant performance bump again. Nevertheless, for the niches where the Cached Interpreter thrives, it is now faster than it has ever been. 2407-165 - macOS: Embed the Updater into DolphinQt's app bundle by OatmealDome¶ One of the best things about macOS is application bundles. On Windows, programs are largely intended to bring their own dependencies. However, each program will need many different files in many different and bizarre places, so much so that it is standard to ship a dedicated program whose only purpose is to place or remove all of the disparate files an application needs to function. If something goes wrong with this process, good luck. Linux, on the other hand, works more like code - dependencies are separate from the program and should be linked, not duplicated. However, dependencies will need to be installed along with the application, so Linux has package managers to install applications and any dependencies that are needed. While this is certainly better than the backwards-compatibility mess that is Windows, installing a single application in Linux still results in installing lots of things in lots of places. macOS is different. It has something called application bundles. All apps on macOS (with the exception of command-line tools and scripts) are distributed in the bundle format. Application bundles are really just regular folders that follow a very specific structure with their contents. They allow all of an application's files and dependencies to be grouped together in a single folder, nice and neat. To the user, however, the bundle is shown as a single icon and they never see or know about all of the files inside. This allows for one of the best things about bundles - the process of installing or uninstalling an app is just... drag and drop. That's it. And to run the application, just double-click the bundle as if it were the application itself. This is the best! However, for the past several years Dolphin on macOS has shipped not one, but two bundles - Dolphin, and Dolphin Updater. The updater didn't do anything if you double-clicked it, and would just give an error; it was intended to be used only by Dolphin itself. Unfortunately, this has occasionally caused confusion with users. After all, the majority of macOS apps are distributed as a single bundle. Why does Dolphin have two? It's just not the same. Fortunately, this has now been fixed. When creating the main Dolphin bundle during a build, we now insert the updater bundle inside of it! Whenever we need to perform a Dolphin update, we just load the updater bundle from within the main Dolphin bundle, create a copy of it in a separate temporary location, and run that. With this change, the user only ever sees one bundle when installing Dolphin for the first time. Glorious single drag and drop installation has been achieved! Hurray! 2407-173 removes all remnants of the separate updater bundle if any are present. If you have previously installed both Dolphin and the updater to your Applications folder, by the time you are reading this the separate Dolphin Updater will likely already be gone. If not, update and it will be removed. Note: A bug was fixed in 2407-111 which caused the updater to crash on startup on some Macs. If you are using an older build of Dolphin, you may need to update your copy of Dolphin manually first. Zelda HLE Pikmin Fixes - 2407-177 and 2407-225 by flacs¶ Audio emulation has gone through an interesting transformation throughout the many eras of Dolphin. In the release era, HLE (High Level Emulation) audio is pretty much universally used for almost everything. Over the course of time, almost every gap in accuracy between HLE and the more in-depth LLE (Low-Level Emulation) has been closed up. Infamous HLE audio bugs like the screeching in Star Wars: Rogue Squadron games? Solved. The Grand Star hang in Super Mario Galaxy? Long gone. It has been a massive struggle to get HLE audio to this point. Back in the old days, you had a choice to make - potentially broken audio (or even no audio in some games!) with HLE, or deal with the massive performance demand that came with getting proper audio using LLE. This all started to change back in the 3.5 era, when massive rewrites hit Dolphin's audio code. Why does this all matter? Well, users didn't like LLE audio, and these massive rewrites to HLE audio had tons of benefits. The problem with HLE audio is that Dolphin has to correctly handle the functions of every revision of every microcode in order for things to work. Pikmin and Pikmin 2 use what we call the "Zelda Microcode". This microcode is used in games like the Zelda games (except Skyward Sword), the Super Mario games and Luigi's Mansion. The problem with this is that pretty much every game uses a different version of the microcode. This meant that in order to emulate each game, you had to figure out what functions they supported, and how to emulate them correctly. For example, all of the microcode revisions will have functions to control volume, but earlier microcodes might have bugs that need to be emulated, later microcodes might have additional features, like controlling volume individually for different things. Apply this to everything, and it becomes apparent how much of a pain in the rear this can be. In order to get these massive rewrites merged, support for each individual microcode wasn't necessarily perfect. Upon testing, the games sounded mostly correct, and the various problems of old-HLE audio were fixed. However, there were minor issues spread across the various games. Originally, New-Zelda-HLE had issues with the volume of echoes in Mario Kart: Double Dash. This was a known issue when it was merged, but was deemed acceptable due to all the other improvements. The only difference between that and Pikmin and Pikmin 2 is that their small issues seemed like they were never going to be addressed. In fact, most users didn't even realize there was a problem. They were by and large playable, and unless you played the game recently on console, you wouldn't know that some menu sounds were the wrong pitch, or there were missing sounds for puffs of smoke in the opening cutscene. Thankfully, when New-Zelda-HLE was merged, the issues we did discover were archived, and flacs saw them and investigated them while looking for more audio issues to fix. Your browser does not support the audio element. The incorrect pitch on the save sound has bothered musically-inclined users for years! Your browser does not support the audio element. Oh sweet relief. Your browser does not support the audio element. The explosions here are too quiet, getting lost in the engine rumble. Your browser does not support the audio element. Emulated properly, they pop and snap as explosions should. These may seem minor, but back in the day there were hundreds of issues like these due to HLE audio's imperfect emulation of the microcode. It seems almost surreal that, in most cases, HLE audio and LLE audio are now indistinguishable. 2407-228 - VideoCommon: Force Display List Alignment by flacs¶ Once upon a time, Dolphin bugs were obvious: a simple screenshot was all it took to convey just how broken Dolphin was in a particular title. Grey Zelda, Spider-man as a flying box, uwu Kirby, Batman as a flying crotch, on and on. However, once Dolphin's fundamental inaccuracies were resolved in the 3.5 and 4.0 eras, that largely became a thing of the past. Today, we have to use fifologs and automation to catch changes, and carefully pixel-peep against console to verify that something is in fact actually incorrect. Wallace and Gromit in Project Zoo bucks this trend. The game's shadows looked fairly good on console, but in Dolphin? They could ƒ^&%ing explode. Well, this is a fine how do you do, isn't it, Gromit?PHOTOSENSITIVITY WARNING. Click to play. We had no idea why the shadows in this fairly obscure game would sometimes fail so catastrophically, but something was clearly very wrong, so in 2013 we added a patch to remove these shadows from the game. It was an extreme solution, but the game had an extreme problem, so we did what we could to at least make the game playable. It was certainly better than the video above. But as time passed, the developers who investigated the problem moved on, and these troublesome shadows slowly faded from memory... Ten years later, flacs happened to notice that Project Zoo's shadows were still broken, and looked into the issue. They soon spotted something suspicious: the game's display list (a group of GPU commands stored for later execution) wasn't aligned. Rather than prevaricate about the bush, flacs went straight to hardware testing and quickly adapted the triangle test homebrew to use display lists. Turns out that hunch was spot on target! Wallace and Gromit in Project Zoo submits display lists unaligned, and Dolphin was erroneously processing them exactly as they were submitted. The hardware aligns the memory address by dropping its lower bits. So for example, the game would point toward 0x80fc9b04, and Dolphin would start executing from there (getting bad opcodes) when hardware would drop the lowest 5 bits as it was 32-byte aligned and start at 0x80fc9b00. By not forcing alignment, Dolphin thought the game wanted to render random garbage and told the GPU driver to render it, which the GPU driver would try its best to do. Sometimes this only resulted in minor visual bugs, other times it would utterly explode as shown above. With a very small change to Dolphin, we can now render these shadows just fine, and yet another hardware quirk is being emulated correctly. While it didn't come in the 4.0 or 5.0 eras, Wallace and Gromit in Project Zoo is finally free from emulation issues. We hope. 2407-236 - Android: Fix and enable input device sensor input by JosJuice¶ Last year, JosJuice rewrote our Android controller input handling from scratch. This rewrite replaced the old Java input handler with a brand new one written in C++ that more closely matched how Dolphin's PC input handlers work. Not only did this clean up some crusty old code with known problems, but it also unlocked dozens of "new" features for our Android users that were previously only in our desktop builds! However, one very significant feature that was a part for that overhaul last year was disabled when the overhaul eventually landed - sensor input (accelerometers and gyroscopes) from external controllers, a feature available in Android 12 and up. During the final testing of the input rewrite, JosJuice received reports that using controller sensors could make Dolphin crash when navigating between screens. Because their phone was stuck on Android 11, they couldn't test the feature themselves, and decided that rather than hold off the rewrite to address the issue, it was best to just disable external sensors for the time being and continue the rollout without it. With over a year passed since then, dreamsyntax showed up with not only willingness to investigate the crash, but also the needed hardware. The first step: Finding out why the crash is happening. The reports from a year prior included a stack trace showing where in the code the crash occurred, and JosJuice had used this information to theorize that when Dolphin turned off unused sensors to save battery, Android would start notifying Dolphin about a sensor that Dolphin never had asked to be notified about. dreamsyntax was able to replicate the crash and get a match stack trace, and then managed to take a step beyond the old investigation by figuring out the root cause of the crash. The sensor that Dolphin didn't recognize wasn't actually a new sensor - it was a new object representing the same sensor as before. The cause of the bug was that Dolphin checked if two sensor objects were literally the same object (referential equality) rather than checking if the objects had the same content (structural equality). With that, it was time for the second step: Properly fixing the issue. dreamsyntax began by making a quick solution to check that their approach was correct, but alas, Dolphin was still crashing! It turned out there was a second crash that nobody had discovered until now because the other crash always happened first! Somewhere within the code of Android itself, a ConcurrentModificationException was being thrown when Dolphin turned sensors off. dreamsyntax couldn't quite make sense of why this was happening, but with all the information he had gathered, JosJuice once again stepped into the picture. They discovered that the cause of the crash was a simple coding mistake in the operating system itself - removing objects from a list while looping through the list - and implemented a workaround for this crash and a proper solution for the earlier crash. Finally, dreamsyntax tested the change to make sure motion controls were now working properly. With the issues now solved, sensors from external controllers are available for mapping in Dolphin on Android! The sensors in controllers such as the DualShock 4 can now be used to better emulate motion in Dolphin. Keep in mind that the feature only works for controllers your version of Android has sensor support for. If you're using Android 11 or older, sensors aren't supported for any controllers at all. Last Month's Contributors...¶ Special thanks to all of the contributors that incremented Dolphin 349 commits in the final days of the 5.0 era, and 279 commits after Release 2407! The First Month of Dolphin RetroAchievements¶ The RetroAchievements team has shared with us a bunch of statistics for the first month of RetroAchievement support in Dolphin! And there's a lot of interesting bits in here. Enjoy! General Statistics¶ Total Unlocks: 860,290 Total Hardcore Unlocks: 815,944 Total Points Earned: 5,864,862 Total Hardcore Points Earned: 5,558,151 Total Sessions: 284,432 Top Ten Games with the Most Players¶ Game Players Super Mario Sunshine 2532 Super Smash Bros. Melee 2230 Mario Kart: Double Dash!! 1908 Luigi's Mansion 1148 Legend of Zelda, The: The Wind Waker 1084 WarioWare, Inc.: Mega Party Games! 946 Kirby Air Ride 893 Legend of Zelda, The: Twilight Princess 888 Animal Crossing 847 Pikmin 758 Top Ten Most Mastered Games¶ Game Masteries Super Mario Sunshine 284 Piglet's Big Game 195 Magical Mirror Starring Mickey Mouse 172 Pokemon Channel 163 ~Hack~ Samus Goes to the Fridge to Get a Glass of Milk 3D 152 Winnie the Pooh's Rumbly Tumbly Adventure 144 ~Hack~ Luigi's Mansion Beta Restoration 140 Legend of Zelda, The: The Wind Waker 120 Wario World 112 WarioWare, Inc.: Mega Party Games! 101 Top Ten Most Beaten Games¶ Game Times Beaten Super Mario Sunshine 626 WarioWare, Inc.: Mega Party Games! 551 Luigi's Mansion 505 Super Smash Bros. Melee 339 Dance Dance Revolution: Mario Mix 305 Pokemon Channel 297 Mario Kart: Double Dash!! 297 Pikmin 273 Legend of Zelda, The: The Wind Waker 243 Naruto: Clash of Ninja 232 [Less]

Dolphin's users are always looking for new ways to play their favorite games. And when a project called "RetroAchievements" started gaining popularity for adding achievements into retro games, users started wondering if Dolphin would ever ... [More] add support for the project. Unfortunately for them, Dolphin isn't a retro game emulator. We're a modern emulator that emulates two recent Nintendo consoles! RetroAchievements wouldn't make sense- Ah shi- RetroAchievements Dolphin Launch Announcement!¶ That's right, it's finally here. RetroAchievements integration has come to Dolphin. Now you can play some of your favorite GameCube games with full achievement sets that are automatically recorded to your RetroAchievements account. Much like modern "achievements" or "trophies", RetroAchievements sets essentially amount to a list of tasks and goals that may go above and beyond simply beating the game. For their GameCube launch day, they've gone all out, with over 100 different titles on launch. This ranges from some of the most popular GameCube games, to obscure gems, terrible games, and even a few game mods! The Legend of Zelda: The Wind Waker Final Fantasy Crystal Chronicles Super Mario Sunshine Harvest Moon: A Wonderful Life Super Smash Bros. Melee Baten Kaitos Origins Kirby Air Ride Star Fox Assault Metal Gear Solid: The Twin Snakes Mario Golf: Toadstool Tour Luigi's Mansion Metroid Prime Star Wars: Rogue Squadron II: Rogue Leader For a full list of games, check out the RetroAchievements GameCube Library with more on their way soon! Want to get hunting right away? RetroAchievements integration is available in Dolphin 2407-68 and newer, which can be found on our downloads page. This will give us a chance to work out some of the kinks before it reaches most of our users in the next release update. Activating RetroAchievements¶ By default, RetroAchievements are disabled in Dolphin. To activate integration, you have to log into your RetroAchievements.org account in Dolphin's new "Achievements" window that's located under the "Tools" dropdown. If you don't have one, you can create a free account on their website. Logging in, tracking, and settings are all contained within one window! Once you're logged in and RetroAchievements Integration is enabled, the next time you load a game with RetroAchievements support, you'll get access to achievements and much more. And that's basically everything you need to know. But, if you're interested in what RetroAchievements can do and how it works, continue reading as we go into more detail. Achievement Lifestyle¶ No matter how you play, RetroAchievements can fit into your style. You can passively gather achievements just by playing through the game, with every set guaranteed to have progression achievements that follow along with the main story or goals of the game. If you do beat the game, the game will be marked as beaten on your RetroAchievements account. On the other hand, you could also take a more active style of Achievement hunting. At any time, you can visit the gamepage on retroachievements.org or through the Achievements menu in Dolphin on the Progress Tab. There you can see what achievements you have, which ones you're missing, and how to obtain any of the achievements. This can be an excellent way to find new challenges in a game you've played through many times before. Some achievement sets might be daunting. Note that in order to get all of the achievements in some games, you might need to start over with a fresh savefile. Some games, like Luigi's Mansion have multiple save slots so this isn't really a problem. But games like 1080 Avalanche and Super Smash Bros. Melee require starting from a fresh save for many achievements. Don't worry, though! You can always create a new savefolder for Dolphin, backup saves, or use a new memory card file if you want to start fresh without losing savedata. Finding the Right Challenge¶ Each RetroAchievement has a score assigned to it. When you collect that achievement, the score of that achievement gets added to your account. Achievements score anywhere from 1 point to 100 points. Single point achievements tend to be easy, sometimes are things that you can't skip, or they might be some kind of funny easter egg. On the other hand, 100 point achievements are some of the most daunting tasks imaginable within that game and can take serious dedication and practice to accomplish. Make sure to pay attention to how many points an Achievement is when picking one to hunt down. You might bite off more than you can chew! The game you play also shapes the kinds of achievements you get. Games like Harvest Moon: A Wonderful Life will challenge your time management and min/maxxing skills. Meanwhile, F-Zero GX will be mostly about going fast. F-Zero GX is home to a lot of high octane achievements, and getting them will be no easy feat. Some achievements will actively let you know when they're available. These kinds of achievements are called "Challenge Achievements" and are often achievements that can be failed without actually losing in the game. When you've fulfilled the necessary conditions to trigger a challenge, a small challenge icon will show up in the bottom right. For more information, check the Progress tab of the Achievements window to get a full rundown on the challenge. Active challenges jump to the top of the achievements window and show a small icon in the lower right of the game window to denote it is active. Sometimes there might be multiple challenges going at once. Old School Mentality¶ Dolphin provides a ton of convenience features that can help with getting some tricky achievements. Using savestates and slowdown can turn the greatest of challenges into a cakewalk. But what if you really wanted a grand challenge, and wanted show your friends that you beat it legitimately without any extra assistance? That's where Hardcore mode comes in. In the RetroAchievements menu, you can enable Hardcore mode and it will lock out those features while you're hunting achievements. This gives a more console-authentic experience that can put you to the ultimate test. You can achieve any achievement in softcore mode. But, hardcore mode gives fancy gold borders. Hardcore mode also enables another RetroAchievements feature: Leaderboards. Leaderboards will automatically record your best times and high scores across various games. What each game measures is up to the developer of the achievement set, but the game will let you know when a leaderboard attempt is active. If you think you're better than all of your friends at Mario Golf: Toadstool Tour, prove it! Are you a time trial demon in Mario Kart: Double Dash!!? Show it. RetroAchievements will automatically record your times in compatible games! There are a variety of leaderboards across the plethora of launch titles. No matter what kind of player you are, there's likely a leaderboard or two that'll fit your style. You can take a look at the game pages at retroachievements.org to see the various leaderboards. A Cooperative Experience¶ With Discord presence support, RetroAchievements can also give live updates of your current position in a game directly to discord. Use this to race friends, or just to show off where you're at in your game. These live updates are context dependant. For instance, in The Legend of Zelda: Twilight Princess RetroAchievements tracks things like chests opened, heart pieces, bugs collected, etc, while in Super Mario Sunshine it keeps track of things like shine count and blue coins. See your current progress directly in Dolphin through the RetroAchievements window. Or, show off your progress on discord with Rich Presence support. If you're a more private gamer or hiding from work, as per usual, the Discord Rich Presence features can be disabled. Multi-Sets¶ Some achievement sets are designed to be played together! Whether the achievement set itself marks certain achievement lines as multiplayer compatible, or sometimes you'll have an entire set designed around multiplayer. In those cases, you can have multiple people on the same computer work toward the goal, or you can use Dolphin's netplay! Netplay with GBAs and RetroAchievements? Yep! Final Fantasy Crystal Chronicles has a separate "Multi" set full of multiplayer achievements. Multiplayer achievement sets test your ability to communicate and cooperate with friends. If you're a solo gamer worried about multiplayer achievements preventing you from getting a game's "Mastery", don't! Any achievements that require multiplayer are moved to a subset that isn't required for game mastery. Achievement Unlocked - Marrying Two Massive Projects¶ Integrating RetroAchievements with Dolphin was not the smoothest of projects. Given the ancient codebases of these two projects (dating back to 2003 for Dolphin, 2013 for RetroAchievements,) there were a lot of growing pains to get everything to play together nicely. And even through it's functional at this point, there's still a lot of cleanup and maintenance that will have to be done post launch. One of the things that helped was the PCSX2 implementation of RetroAchievements, which acted as a base for the developers who worked on the Dolphin version of the implementation. As well, their own achievement creation library had to be ported over to work with Dolphin's memory handling. From there, it's been a massive 18 month journey implementing things to get it ready. Without pushing from those passionate about RetroAchievements support (and them also putting the work in,) this could not have happened. There were a lot of roadblocks and close calls with the implementation, and a lot of concessions in order to make things work. This generated a lot of pull requests that needed review, and there were a lot of difficult decisions to make over what to allow and what needed to be done. Code review stages actually took a significant amount of time, due to some of the difficult problems that had to be tackled with memory access and management. During this process, a secondary build of Dolphin was being developed that worked with their integrated achievement creation system. That way, while RetroAchievements was implemented into Dolphin builds, teams of achievement creators could get to work on developing the achievement sets you see today. Developing these achievement sets was no easy task - depending on the game, an achievement set could take dozens, if not hundreds of hours of work. GameCube games can dynamically allocate memory, use pointers, swap memory between RAM and ARAM, and in some cases like Star Wars: The Clone Wars, change the Block Address Tables whenever it wants. It all makes for a difficult job that takes a lot of testing. Your favorite game missing an achievement set? Complete the Jr. dev program for RetroAchievements and become an achievement developer! Without these builds, developing achievements would have been nearly impossible, and even with these special additions to Dolphin, there were still a lot of headaches. One headache that they learned to avoid very quickly was of Dualcore. While it may lure you in with its promises of performance, the workload for creating achievements made it even more unstable than normal. Thankfully, this only affected the development of achievements; users will be able to utilize Dualcore mode and its speedups without additional worry. As such, achievements don't cause much of a performance overhead. While there is always a cost to checking memory, we haven't observed any noticeable performance impacts. The biggest limitation with RetroAchievements in Dolphin actually comes from how we display them. In order to display achievements, the notification system had to be adapted to ImGUI, which is not the ideal solution for their GUI, but it's the solution that we had. Worse yet, because Dolphin doesn't support asynchronous presentation, the framerate that in-game overlays/notifications show up at depends on the actual game's current framerate. This is normally fine in typical gameplay, but if an achievement shows up during as loading screen that has few or no rendered frames, you won't be able to see it in the game window. It's just a case of Dolphin not being designed for this use-case. Issues like these can be addressed in the future, and we don't think of them as game breaking. As is another omission from this initial launch. Specifically, we didn't target Dolphin on Android. While Dolphin on Android is the same core emulator as its desktop counterpart, there is significant work that would be needed to adapt the RetroAchievements dialogues and settings to Android. Additionally, we ran into some networking issues on Android that are going to require specific attention, and with the desktop release already taking so much effort, we decided it'd be best to hold off. If you're an Android user looking forward to RetroAchievements, don't worry - it will happen. We just can't promise when yet. Wait! What about Wii?¶ Are the teams planning to do Wii RetroAchievements? Yes, both sides are open to it, and somewhere down the line work will begin. But right now, our focus is on getting GameCube RetroAchievements working, and continuing to address various issues and limitations post launch. Eventually, efforts will shift toward Wii RetroAchievements, but it might be a while. Congratulations - You've Mastered This Article¶ And that's that! We've gone over all of the major notes for using RetroAchievements in Dolphin. For more information on RetroAchievements, across all consoles, check out their site and documentation for information on supported emulators and various issues. Starting today, there will be a GameCube launch event, and some of us within the Dolphin team will be attending. This could be your chance to compete against us on the leaderboards, while obtaining a RetroAchievements badge for completing and mastering games. Special thanks has to go to all of the developers (from both projects!) that put up with the many headaches that came up during the lengthy development process. As well, we'd like to thank the additional volunteers in the RetroAchievements community that worked on the achievement sets for this launch. Without them, there wouldn't be any achievements to, well, achieve! But now that the launch is finished, there's only one thing left to say. Happy hunting, everyone! [Less]

On the 24th of June, 2016, Dolphin 5.0 was released. The product of a long and hard transition period, the fundamental inaccuracies that plagued Dolphin for over a decade had successfully been undone, and Dolphin was now free of its burdens ... [More] to swim forward into a new era of accuracy and performance. Eight years have passed since that great release, and we have seen the dividends of that effort time and time again. Dolphin has seen constant updates, with new features and enhancements coming side by side with bug fixes and stability improvements. Users are now able to upgrade without fear, knowing that even in the unlikely event of a bug it will be fixed within hours. And of the thousands of titles that Dolphin can run, the number that do not function can now be counted on one hand! All of this was achieved without a new release. In fact, Dolphin has been in the 5.0 era longer than any other, and with almost twenty-two thousand commits over the past eight years, the 5.0 era now makes up over half of Dolphin's entire commit history! But users haven't forgotten our past releases. They have been waiting for years, patiently anticipating when our next release may arrive. That wait ends today. However, the purpose of our old stable builds is now no longer relevant to Dolphin Emulator. We no longer need a benchmark to compare against or an anchor to ground us. We have grown beyond them. So in leaving the 5.0 era behind, we are also leaving behind that release scheme and all it offered. In exchange, we're not just giving you a release today, but also a commitment to continuous releases from now on. The long drought of Dolphin releases is no more and will never happen again! Welcome to a new era of Dolphin Emulator - the Release Era! Announcement¶ We are pleased to announce that Dolphin has adopted a rolling release cycle! Building upon our highly successful "beta builds", we will have a release every few months, with a Progress Report launched alongside as a changelog. These are proper release builds however, with the full infrastructure and support that comes with them. They are tagged as releases in Git, allowing our distribution partners to properly support us and our users. Our new releases can receive hotfixes, so if any issues arises we can release small updates instead of a full on new release. And, of course, every release will advance Dolphin's version number. However, our new releases are fundamentally different from our prior releases, so we didn't want to just add a number to our last release. As such, we are abandoning the X.0 release numbering and moving to a new date-based versioning scheme! Accompanying this article is our first rolling release - Dolphin 2407! This release is available for download immediately, for Windows x86-64, Windows ARM64, macOS, and Android from our official website: dolphin-emu.org. Here are the details of the new rolling release scheme: The first two digits are the year, and the second two are the month. 2407 codifies a release from July 2024. All subsequent dev builds after a release will be numbers added on to it. For example, 144 commits after 2409 would result in dev build 2409-144. Our next release will be 240X. Yes, it will be in just a few months from now! Hotfix releases will have the addition of a suffix. For example, a single hotfix to Dolphin 2409 would be "Dolphin 2409a". Beta builds are being replaced by releases. All users in the beta update track will be moved to the new release track. A New Look!¶ To herald and symbolize this new era, we also have a new logo! MayImilae, the designer of our previous logo and long term Dolphin blog writer and contributor, has refreshed our logo for the modern day! For comparison, here's our previous logo. Here is the explanation of the design, in her own words. Dolphin's 2013 logo was designed at the start of a transition. Dolphin was leaving its buggy past behind and committing to doing it right, even if it meant ripping out tons of working code. So gone was the silly peace sign mario, and in its place I made a sharp, edgy, serious, on-trend logo to symbolize Dolphin's new future as a serious emulator. And yea, that's carried us through all this way! However, Dolphin is more mature now. It's stable, confident and comfortable in its place. So for the refresh, I wanted to return to the original design and make it timeless, but also more fun, more colorful, and make it a little gentler and thicker. And finally address all the things that were bugging me for ten years. MayImilae This new logo has already been rolled out in our system and brands Dolphin 2407! However we couldn't get every little logo replaced before the release, so the few that remain will be cleaned up soon. The new logo was designed with variation in mind! Expect to see it in many styles and colors. But why not 6.0?¶ As we leave the 5.0 era behind, we feel the need to address what might have been - 6.0. While we lightly touched on the reasons above, we know that won't be enough for those who waited so long for something that we kind of didn't deliver. However, to explain this properly we're going to need to go in depth, and tell the story of Dolphin's releases. When Dolphin was a closed source project, beginning in 2003, it benefited from being made by excellent programmers. Code from that era is of the highest quality and has stood the test of time. For example, most of our interpreter has not even been touched in over 15 years! It has been added to, but very little of the interpreter code from that period has been altered. But there was only so much that a handful of quality coders could do in their spare time. It took years for Dolphin to approach even a proof of concept, let alone become an actual working emulator with decent features and game compatibility. So in 2008, the founders of Dolphin decided to enter the wild world of open source. With the floodgates open, contributions poured in. In just a couple of years, Dolphin became a full blown emulator, with tons of new features and the ability to play most games! But the move to open source was not without its drawbacks. While Dolphin was getting the help of hundreds of new developers, the code quality of the project plummeted. The tools available at the time simply didn't allow for quality development. Back when Dolphin went open source, modern development platforms like GitHub didn't exist!* There were no pull requests. There was no way to easily review code and an accompanying forum for discussing the changes before they were checked in or merged. Instead, all development was handled through IRC and Google Code, which was more of an issue tracker with a bolted on hosting service than a development platform in the modern sense. In this era, to submit a change to Dolphin developers would show their change to a developer with commit access in IRC and ask them to merge their patch. This was a form of review, but it was slow, cumbersome, and overwhelming for maintainers. So once a developer was known to the project, a maintainer would give that developer commit access and they could just commit anything without review from that point forward. Today, this would be considered irresponsible and reckless. But at the time, we had little choice. With terrible tools, difficult to impossible review processes, and a desperate need for contributions, Dolphin flew open the doors and allowed thousands of changes without review. That decision proved to be highly effective in the short term, and Dolphin exploded in functionality and capability. But code of all quality was being let into the project, both good and bad, and the health of Dolphin's codebase slowly declined. After a few years, Dolphin began to buckle. By 2010, Dolphin was buggy and unstable, and development builds would often break for days at a time! With no access to modern tools, Dolphin needed something to ground itself in the raging sea that was open source in the late aughts. Dolphin needed an anchor. And so, Dolphin adopted the Stable Release model. In that release formula, a new Stable Release must have all regressions since the last release resolved, no matter how minor. This would allow releases to serve as a benchmark, a minimum standard that Dolphin would never fall below and would always improve upon with each new release. This meant that no matter how chaotic the development process may be, users knew that if they went from release to release, Dolphin would always be better in every way. However, Dolphin is a volunteer project, and everyone is committing their free time. To get volunteers to drop their fun projects and work on tedious regression fixes, Dolphin used feature freezes. During a feature freeze, all merges are halted except bugfixes. Once all of the regressions from the previous release are resolved, Dolphin would launch a Stable Release, and then feature merges would reopen. By holding developers' fun projects hostage, feature freezes coerced developers to contribute to the bug hunt. After all, the more developers pitched in and fixed bugs, the sooner their cool project could get merged into Dolphin! And it worked. Bugs were fixed and Stable Releases were launched. However, feature freezes were miserable and costly. During a freeze, Dolphin's development would stall for months at a time, morale would plummet, new developers were repulsed, and sometimes long-term developers would get tired of it all and just leave. Of course we hoped to find a better way, and with each Stable Release we tried some variation or alternative to feature freezes. None of them succeeded. After 5.0's feature freeze alternative failed so badly that we had to restart the release process over from scratch, we had had enough, and made a collective decision to put releases away for a while. No one wanted to deal with a feature freeze again. Fortunately, we have not needed to. The transition to stability that 5.0 crowned, combined with the advent of modern development tools, has completely changed our development process. Now, every change is reviewed and checked before it is merged. Rather than hurry through messy development and then clean up after, cleanliness and stability is our every day! We no longer need to periodically stop everything and clean up our mess! We no longer need Stable Releases! Theoretically, we could have just... not prepared a release ever again. We could have stayed in the 5.0 era forever! However, there are a lot of benefits to releases - for infrastructure, support, and distribution. We wanted to take advantage of those. But we were not going to do a Stable Release again. So after much deliberation and a lengthy development process, we have adopted a rolling release model. And to codify just how vastly different our new releases are from our previous ones, we also adopted a new versioning scheme. Gone are the X.0 numbers, and with it, 6.0. Credits¶ Approximately six hundred people contributed to Dolphin in some manner during the 5.0 era. There are far too many people to list all of them individually in this article, so we're going to call out the groups that have made Dolphin what it is today! Dolphin would never have gotten to where we are today without the hundreds of developers who have volunteered to make Dolphin better. The 5.0 era saw many long awaited features like Ubershaders, the Unification of VideoCommon, Hybrid XFB, MotionPlus Emulation, the Qt user interface, Bluetooth Passthrough, many new graphics backends, and much much MUCH more! This was only possible because of the tremendous effort of the brilliant engineers who volunteer their time to Dolphin! The great vanguards of support, our Discord moderators and support staff have been assisting users for years, even before our Discord was official! The sheer quantity of users that our Discord is able to help boggles the mind. The core pillar of support remains our forum. Filled with over a decade of history and our support veterans, our forum is where our support staff go for support. Our Wiki team maintains and curates our greatest collective of knowledge for how games perform. Thousands of games are recorded, with thousands of bugs (mostly fixed), workarounds, and game quirks, and tens of thousands of user testing reports! Dolphin is available in 29 different languages! This is entirely thanks to the members of our translation team, who volunteer their free time to regularly keep our translations up to date. And of course, this article wouldn't be possible without our blog team! We're not going to praise ourselves beyond that, it's weird. We will however take a moment to specifically call out those who made this release happen! delroth championed and planned out our new release scheme, and then reworked our infrastructure to get Dolphin ready for it. He retired before it was all complete, but this release was largely his project, and it would have never happened without him! OatmealDome picked up where delroth left off, implementing delroth's release proposal and carrying it to the finish line! Of course Android would require special attention. JosJuice sorted out all of the kinks and got our Android builder ready for Android's first ever Dolphin release! mbc07 readied our wiki for the biggest release change in its history. MayImilae commented on the new release plan, with interest. Also she designed the new logo, helped coordinate the launch, and wrote this article. [Less]

In late 2012, Dolphin moved to a brand new website - dolphin-emu.org. With complete control of our own home and infrastructure for the first time, we noticed the accessibility to users that it gave us. Not only did we get a new home, but we ... [More] also got a platform, one that allowed us to communicate directly to our users! We used it to great effect, explaining big changes to the emulator such as tev_fixes_new, getting ahead of controversy when we removed the popular D3D9 graphics backend, calling out broken drivers, and more! The Dolphin Blog was born! However, we quickly realized that while single dedicated articles were great for big changes, Dolphin was improving all the time and tons of important and/or interesting changes were being overlooked simply because they weren't "big enough" to warrant a feature article. We needed something that would let us cover the continuing development of the emulator. Something like, a periodical article filled with a collection of notable changes, so we could report on the progress of Dolphin within a set window of time. And after much experimentation, we built a format to fulfill this role, and released the first of its kind to the world on the 30th of April, 2014. Ten years ago today, the first Dolphin Progress Report was launched! Since then, our blog has exploded in popularity, and tens of thousands of people read every Report! And in that time, we've made 79 Dolphin Progress Reports, with 797 Notable Changes, 54 special sections, and 301,807 words! Thanks for reading! As the writers of the Dolphin blog, we are proud of what we have accomplished here. We've highlighted tons of cool changes, educated our users (and ourselves!) on how Dolphin works, we've helped reel in fresh talent for the emulator, we've helped people get into universities and launch their careers, and even helped a few people meet their life partners! Progress Reports have been so impactful, that they have reached far beyond Dolphin. The once novel concept of emulator Progress Reports has become a standard means of user communication throughout emulation! But of course, ten years is a long time, and we've changed along the way and will continue to change over time. The Reports may grow or shrink, become more or less frequent, structure and style may change, and writers may come and go. And truth be told, this is hard, and we nearly reached the breaking point a few times along the way. But no matter what happens, as the writers of the Dolphin Blog, it is our goal and our hope that for as long there are Notable Changes being made to Dolphin, there will be Progress Reports to feature them! Speaking of which, anniversary or not, this is a Progress Report. We have Notable Changes to cover! So without further ado, please enjoy the Tenth Anniversary Dolphin Progress Report, and the last Dolphin Progress Report of the 5.0 era. Surprise!¶ OK, a little further ado. We have prepared a little something to celebrate this Anniversary. Enjoy! Now back to our regularly scheduled Dolphin Progress Report. Notable Changes¶ 5.0-21264 - Core: Fix IPL device m_cursor overflow by JosJuice¶ In March 2024, Geotale found a crash in Dolphin and drilled it down to its root cause. GameCube software runs on the metal - it has absolute control of the hardware without any operating system whatsoever. In order to save console-wide settings, such as mono versus stereo audio, the GameCube stores 64 bytes of data in a battery-backed SRAM chip. Whenever a game boots, it will read the battery-backed SRAM and collect these settings without asking the user to set stereo sound over and over again. Normally, games don't try to read or write beyond the 64 byte mark, but if they for some reason were to do that, Geotale found that Dolphin would access memory beyond the end of the memory buffer it allocates for SRAM data. ElectrifiedStrawberry then wrote up a bug report about the issue to relay it to the Dolphin developers. Upon seeing the report, JosJuice quickly realized that the bug might be exploitable by specifically crafted software to take control of Dolphin, and fixed the problem by adding a bounds check. As far as we know, nobody has tried to exploit this bug yet, but to be on the safe side, we decided to release an out-of-schedule Beta release just a few days later to get the fix out to users. How come one missing bounds check can open up for exploits of this magnitude? If you've read about differences between different programming languages, one term you might have come across is memory safety. Even the White House talked about it recently! In a memory safe language, trying to access memory beyond the end of a buffer or trying to access memory using a pointer that doesn't even point to valid memory to begin with is either impossible or handled in an orderly way. For instance, Java raises an ArrayIndexOutOfBoundsException or NullPointerException respectively for these situations, and the programmer can either write code to handle these exceptions in whatever way they prefer, or ignore the exceptions and have the program crash. But Dolphin is written in C++, which isn't memory safe. While nowadays there are languages that target both memory safety and good performance, like Rust, back when Dolphin was started in 2003, all the available memory safe languages came with notable performance penalties. And when emulating a cutting-edge console like the GameCube, you need all the performance you can get! In C and C++, going beyond the end of a buffer or using an invalid pointer is formally undefined behavior, meaning literally anything could happen. In practice, usually one of two things happens. If you try to access memory that the operating system considers to be invalid, the program normally crashes. While that may be unpleasant for the user, it's safe in the sense that there's no way for an attacker to exploit the behavior. On the other hand, if you try to access memory that the operating system thinks your program should be allowed to access... then the program accesses that memory. This is exactly what happens in the bug Geotale found. If you go beyond the buffer allocated for SRAM data, you'll start accessing other parts of Dolphin's memory, which are valid memory regions but were never intended to be accessed by the emulated software! As mentioned before, we're not aware of anyone having created an exploit for this, but because Dolphin stores lots of important data after the SRAM buffer and because the emulated software can freely mix reads and writes and can skip over addresses it isn't interested in, it's likely that it would be possible to create an exploit that escapes out of the emulated console. While in theory a program written in C or C++ can be memory safe if carefully written to avoid bugs, writing a large program without bugs occasionally slipping in is really, really hard, bordering on impossible. So unfortunately, there's a risk of bugs like this being found lurking when someone unearths a part of Dolphin's code that hasn't been touched in a long time. But when bugs like this are found, we take them seriously and move to fix them. 5.0-21145 - Improve window presentation at native resolution by Filoppi¶ Last year, Cristian64 noticed that there were black lines always present to the right and bottom of the image whenever Dolphin was in Windowed mode. They looked into it, and found some errors in how Dolphin's aspect ratio correction interacts with our presentation. They posted their findings in our discord, Filoppi whipped up a fix, and that was merged in 5.0-20048. With that, the cursed black errant pixels were removed from the edges of the screen! Fast forward to today, and Filoppi noticed that some titles at 1x Native were softer than they should be. Four Swords Adventures was nice and crisp at 1x Native. But at some point, something was making it softer than it should be on the vertical axis. Bisecting the issue, he traced it back to 5.0-20048, his own change! It turns out that the previous presentation fixes brought our old friend floating point rounding errors into the party! There are many opportunities for small floating point rounding inaccuracies throughout Dolphin's presentation and aspect ratio correction code, and sometimes (depending on the game and its native resolution) these could add up to incorrectly make Dolphin think that scaling the image by one pixel was necessary. This was the cause of our blurring! Apparently the errant pixel borders Dolphin had previously were accidentally shielding Dolphin against this kind of error. Since realistically&ast; there should never&ast; be a case where scaling by a single pixel is correct&ast;, Filoppi fixed this with a simple exception - if Dolphin decides to scale by a single pixel, pass through the unscaled image instead. Problem solved! Now Four Swords Adventures and any other affected games are properly crisp at 1x Native once again. * Next time on the Dolphin Progress Report... 5.0-21162 - BranchWatchDialog: A Total Replacement for CodeDiffDialog by mitaclaw¶ While Dolphin's primary purposes of preservation and enhancement are focused on play, as an emulator we can grant DEEP access to GameCube and Wii hardware and software. Dolphin can be a powerful utility for GameCube and Wii modding and reverse engineering! This change adds a new debugging feature called the Branch Watch, a powerful new tool that enables better code searching than ever before! Since this is a feature by developers for developers, we're not going to hold back. Let's get technical! Back in April of 2022, the Code Diff Tool was added to the Code View widget. Created by TryTwo and dreamsyntax, the Code Diff Tool aimed to replicate a feature of the popular program Cheat Engine called "Ultimap." What if you could do cheat searches, but on program flow? Ultimap is the way for Windows applications. The way the former Code Diff Tool worked was by recycling a JIT profiling feature that had been inaccessible since the removal of DolphinWX in June of 2018. By differencing the number of times a block of recompiled code has run since the last time you checked, it was possible to track down sections of the original code that execute only when an action is performed in the emulated software. Unfortunately, the recycled JIT profiling feature was in no way built for what the Code Diff Tool was trying to do, leading to some limitations. The Code Diff Tool was not compatible with the Interpreter due to the Interpreter not being a JIT (obviously), nor was it compatible with the pseudo-JIT we call the Cached Interpreter due to that JIT lacking the profiling feature. It was also susceptible to JIT cache clears happening out of its control, interfering with progress in any ongoing diff. For semi-arbitrary design reasons, the Code Diff Tool required debugging symbols to operate. A diff would only include recompiled blocks of code associated with the starting address of a debugging symbol, which was problematic when the start of a function may never be recompiled as its own block due to branch following optimizations in the JIT(s). Additionally, the same segment of the original code could be recompiled multiple times, potentially resulting in misleading run counts. Finally, any changes to debugging symbols over the course of a diff would cause some diff results to be unrecognized when checking what has been run since the last check. Naturally, these limitations were frustrating to work with, but it was mitaclaw who finally grew frustrated enough to try to do something about it. He first set off to improve the Code Diff tool, but eventually he came to the conclusion that JIT profiling data wouldn't cut it any more; Dolphin needed a new component built for the purpose. Thus, the Branch Watch was born. The job of the Branch Watch is to receive information from the emulated CPU about every executed branch's origin, destination, and PowerPC instruction. It also receives implicit information about the current address translation mode as well as if a conditional branch is taking its true path or false path. After an optimized associative lookup, an entry added to or found in one of the BranchWatch's "Collection" containers will have its hit count incremented by one. From the user-facing Branch Watch Tool, it is then possible to direct the Branch Watch to perform some differencing (not unlike the former Code Diff Tool would) to collate references to the "Collection" containers' entries that meet a given criteria into a separate list - the BranchWatch's "Selection" container. This "Selection" container is what can be seen in the user-facing Branch Watch Tool. The whole process makes viewing the information sufficiently thread-safe, allowing for real-time updates (every 100 ms) to the Branch Watch Tool's interface. Implementing all of this was a breeze for the interpreter, and support naturally came to the Cached Interpreter as it's barely a JIT. Support for the proper JITs was not so simple. A branch might not be recompiled at all due to the aforementioned branch following optimization. The JITs also have idle loop detection, which can cause specific branches to be recompiled differently. The x86_64 JIT also supports merging PowerPC comparison instructions and PowerPC conditional branch instructions into a single x86_64 instruction that does both. The most involved JIT-ism to support was an optimization for a looping pattern commonly seen when invalidating memory with the dcbx family of instructions. After relentlessly hunting down every corner case, and with JosJuice's invaluable guidance on writing safe recompiler code, the JITs were finally able to match the Interpreter perfectly. So many buttons and boxes... where to begin? The new Branch Watch Tool comes with a robust set of options and features to empower code searching. It is possible to filter candidate branches by address and debugging symbol (both at the origin and destination), by true path or false path (for conditional branches), and even by 12 different instruction kinds. When replacing a tool with existing users, it's imperative to leave no feature behind. The authors of the former Code Diff Tool were given council to make sure features from the former Code Diff Tool were not forgotten, such as saving and loading in-progress searches (including an auto-save feature) and "inspecting" results by modifying instructions to stub functionality (previously done inspections are marked with a bold red font). All-in-all, the new Branch Watch Tool should be able to satisfy everyone by providing a superset of features previously available. If you would like to take the new Branch Watch Tool for a spin, look for the "Branch Watch" button in the Code View widget and check out the Branch Watch Tool's help message tutorial found under Tool > Help. As an aside for non-debugging users, we assure you that this new feature should have zero performance implications for recompiled code when not in use. 5.0-21164 - Corrected Custom Aspect Ratio by Filoppi¶ The previous Progress Report saw the introduction of the Custom Aspect Ratio setting, allowing users to set any arbitrary aspect ratio they want! However, we ended that section by warning that the new Custom aspect ratio option bypassed our aspect ratio corrections, and the image would be slightly distorted basically all the time. Fortunately, Filoppi wasn't through with this feature, and the custom aspect ratio setting now has Dolphin's aspect ratio corrections! If you are using an ultra-wide screen code, you can just set a Custom Aspect Ratio to match your screen and/or code and it will just work, without need to worry about or compensate for subtle aspect ratio issues! However, if you liked the old behavior, you can use the new "Custom (Stretch)" option, which still does not have any aspect ratio correction. 5.0-21194 - Implement IR passthrough for Emulated Wii Remotes by AdmiralCurtiss¶ Ever since Dolphin added its own Wii Remote driver that allowed for using the Wii Remote as a configurable controller in Dolphin, one of the biggest questions has been "When is Infrared Support coming?" Dolphin's Wii Remote driver could do just about anything with the Wii Remote, include using it to simulate almost all Wii Remote functions and even passthrough the battery level to the emulated game. But, when it came to infrared, there was no way to properly handle it on a standard Wii Remote, and you'd be forced to use the "Real Wii Remote" setting or Bluetooth Passthrough if you wanted to use a sensor bar for infrared data. "Connect Wii Remotes for Emulated Controllers" uses Dolphin's very own Wii Remote driver to give the machine a mappable controller. "Point Passthrough" is a new feature for Dolphin's Wii Remote driver that allows you to use a real sensor bar with the emulated Wii Remote option. Some of you may be scratching your head after reading that, as there is a way to get the Wii Remote pointer working with Dolphin's Wii Remote driver. However, that method of getting the pointer working doesn't use infrared at all, it simply simulates the Wii Remote's pointer direction using the MotionPlus gyro (and is compatible with non-Wii Remotes that have a gyro) and uses that to reasonably simulate the controller's position in 3D space, from which Dolphin can calculate where the Wii Remote is pointing. This is what lets players easily play games like Super Mario Galaxy on modern controllers with gyro capabilities. There are some limitations to this, and people with Wii Remote hardware have long been asking for real infrared support with our Wii Remote driver. Unlike real infrared, which has a physical reference in space, gyro infrared suffers from drifting and you have to manually recenter it (usually with a button combo on the controller) once in a while. In most games this isn't too bad, but if you're doing a lot of rapid movements, gyro aiming can fall apart fast! There are also some cases where the gyro simulation didn't produce accurate enough results. Here are some of the best examples where infrared support makes a big difference. Features¶ Netplay - In netplay, only emulated controllers can be used due to the strict requirement of absolute determinism. This means you cannot fall back to using the "Real Wii Remote" or the Bluetooth Passthrough settings. However, since 5.0-11684 physical Wii Remotes were still usable on netplay through connecting Wii Remotes for emulated controllers. A lack of infrared support meant that using a real Wii Remote on netplay had the hard requirement of having MotionPlus if you were using the pointer. This also meant any game that requires precise pointer controls would not work. We'll have some examples later. Savestates - Saving the state of the emulator is always a perilous task. Each of Dolphin's methods of handling Wii Remotes affects savestates differently. Bluetooth Passthrough makes things very difficult, because we use a real hardware Bluetooth Adapter directly - and we cannot save the state of that physical device. There is limited savestate support, but it requires the user to get the adapter to match the state it was in when the savestate was made. You could accomplish this by connecting the same Wii Remotes in the same order with the same attachments and hope that Wii Remotes are using the same reporting mode as when the savestate was made. Otherwise? It'll deadlock. Real Wii Remotes aren't as bad, but users aren't exactly thrilled by our softlock workarounds. As mentioned above, Wii Remotes have various reporting modes, and because we're dealing with a physical device outside of the emulator, we can't simply restore it to the state it was in when the savestate was made. In order to prevent potential softlocks with Wii Remotes, Dolphin will disconnect and reconnect Wii Remotes on loadstate. This resets the state of the Wii Remote to ensure they match, but results in a small delay on loadstate and the game potentially complaining that the controller was disconnected. It may sound annoying, but it is also greatly increases the stability of savestates for Wii games. Emulated Wii Remotes have none of these problems, as the thing the game is directly communicating with is within Dolphin's ecosystem. This means that Dolphin can just restore the state of the emulated Wii Remote, without the need for any workarounds or mitigations for softlocks. This is because the "physical" controller just communicating through our driver to our emulated controller. With the new Point (Passthrough) feature, you can get the full benefits of a real sensor bar and savestates all at once. Perfect for speedrun practice or getting past a difficult pointer puzzle. Game Specific¶ Super Paper Mario - This game in particular asks a lot of the Pointer, having you swap between pointing at the screen and pointing off screen. Gyro Point struggles with pointing far off screen, so oftentimes users would have to map the hotkey "hide pointer" in order to get the game to behave in a reasonable manner. With a real sensor bar, it just works. The Legend of Zelda: Skyward Sword - This is a rather funny case that really messes with our Gyro Pointer. Skyward Sword already uses the gyro for its pointer, using infrared only for a reference point and for active recalibration to combat drift during play. This means when Dolphin is using the gyro to generate the pointer position, Skyward Sword is using our emulated point in space to correct for gyro drift, yet our emulated point in space is from the same gyro that it is trying to recalibrate. Calibrating a gyro to itself results in a lot of wonky pointer behavior, but users have made it work with complex control schemes and copious recentering. Using a real sensor bar with emulated Wii Remotes gets the game behaving just as it does on the Real Wii Remote options. Trauma Center, Another Code R, WarioWare: Smooth Moves and other precision pointer games - Unlike the other situations, there wasn't an easy workaround for these games when using Gyro Point. These games have various levels where you're required to push the Wii Remote toward the screen or pull it away from the screen. While games can use the accelerometer for this, they also use the sensor bar's two clusters of lights as a reference point. When you push the Wii Remote closer, the two clusters separate more, and that's how the game can tell the Wii Remote is closer to the screen. Gyro Point has no way of handling this currently, and the only way to make this work without a real sensor bar is to map a bunch of emulated movements to the controller. While this is possible, you get a very different experience and using a real sensor bar keeps it simple and authentic. Limitations¶ With this major update to the emulated Wii Remotes, the bridge between Real Wii Remotes and Emulated Wii Remotes shrinks further. Considering that we still have three different ways of connecting Wii Remotes, one may question when it'd be time to simplify things. Unfortunately, Emulated Wii Remotes still have a few shortcomings that make Real Wii Remotes a necessary option. While things like battery life work, unfortunately physical Wii Remote Speakers aren't supported on the Emulated Wii Remote. Many users (and developers) may argue speaker data doesn't work properly even on Real Wii Remote, but one feature that is definitely missing on Emulated Wii Remotes is the Wii Remote Eeprom. This Eeprom could store a small amount of data, usually for Miis. Real Wii Remote does support this, but this might be very complicated to support within our driver. If you want to try out infrared support, it's automatically mapped correctly when loading Dolphin's default Wii Remote profile. To try it out, go to the Motion Input tab and disable the standard "Point" setting that uses the Gyro, and enable Point (Passthrough). That will allow you to use your real sensor bar. The settings may look complicated, but Dolphin will set everything up itself to work with your Wii Remote. HDR Enhancements: 5.0-19931 - Add AutoHDR post process shader by Filoppi and 5.0-21232 - Add HDR to Metal + Perceptual HDR by samb¶ HDR is currently very challenging to demonstrate in browsers. Frustrated, the blog authors resorted to old memes. We apologize in advance. Several months ago, Filoppi's 5.0-19716 - Support Accurate NTSC/PAL Color Spaces was merged, which gave Dolphin the ability to properly emulate the gamma and color space of the GameCube and Wii. The difference isn't significant, and since it results in slightly reduced brightness and saturation it could be considered undesirable, hence it being off by default. But more accuracy is more accuracy, and even subtle improvements are important for a mature emulator such as Dolphin! However, to facilitate accurate gamma and color spaces, Dolphin needed more control over the host display. Ironically, this required Dolphin to support HDR. High Dynamic Range is typically used to display a larger color space, yet this feature was using it to limit the color space to accurate levels. Regardless of the reasoning, this change added the HDR Post-Processing feature to Dolphin. What happened next was easy to see coming. In 5.0-19928, Filoppi added an HDR enhancement shader to Dolphin! A "slimmed down port" of Filoppi's prior Reshade shader, our AutoHDR shader is designed to be additive - it expands highlights into HDR luminance while leaving the rest of the image unmodified. This gives games a bit more pop while still mostly maintaining their original SDR look. AutoHDR has several options to allow users to dial in the experience. Shoulder Pow - Modulates the Auto HDR highlights curve. Low values bleed a bit into midtones to give a gentle, soft edge around the HDRified highlights, while high values only brighten the hightlights for pin sharp edges. Shoulder Start Alpha - Determines how bright the source SDR color needs to be before it can be used to generate fake HDR highlights HDR Display Max Nits - Sets the maximum brightness of the HDR highlights If you want to closely follow the original look of the game but add a little HDR pop, AutoHDR is for you! Do note however that GameCube and Wii games have very primitive lighting models, more primitive than what AutoHDR was originally designed for. More often than not, our AutoHDR shader will benefit from tweaking for each individual game's lighting quirks. For a bit more pop, samb's 5.0-21232 brings PerceptualHDR, a much more HDRy enhancement option! PerceptualHDR uses a logarithmic approach to its inverse tonemapping curve. This results in brightness and saturation scaling that looks more "natural" to the eye, though less accurate. It also has the side effect of making it very tolerant of the poor lighting models of GameCube and Wii titles, and reducing the need for customization! It also has higher saturation and brightness overall, with a more "HDR look". However, PerceptualHDR significantly changes the look of the game, and is definitely not for those pursuing accuracy. The two shaders have very different looks and goals, neither one is "better" than the other. AutoHDR is very conservative, trying to enhance but respect the original look. Plus it is very customizable, allowing it to adapt to any game's lighting. Meanwhile, PerceptualHDR throws out the original look for all the HDR pop it can offer! While it is generally more tolerant, it is also not customizable (outside of amplification), so if a game doesn't work well with it you're basically out of luck, but AutoHDR can be adjusted to match. Whichever shader you use is up to you and what you'd like out of an HDR enhancement! To demonstrate these differences, we're going to need to go into the High Dynamic Range! HDR Block¶ Click the image below to enter the HDR Block, an addendum article where we use cutting edge browser features to show you actual HDR comparisons rendered in your very own browser! You'll need an HDR display to see the differences, so if you are using an SDR display, feel free to skip. CLICK THE IMAGE BELOW TO ENTER THE WORLD OF Welcome back to the land of SDR! Take a moment to readjust your eyes if you need to. Maybe use some eyedrops. Now that we have established the differences and options, it's time for us to temper your expectations. The GameCube and Wii are entirely SDR consoles with very basic lighting models that were designed for small and dim displays. They are absolutely not designed for HDR. By dragging them kicking and screaming into high dynamic range, we are putting these games that have no idea what HDR is in charge of an absurdly powerful display technology. Our HDR enhancements are not magic. Expect quirks and problems. For example, there is no concept of "paper-white" in these games. While our HDR enhancement shaders differ in their approach and the inverse tone mapping of middle values, the extremes are the same - complete black in SDR space will be complete black in HDR space, and complete white in SDR space will be the maximum HDR output of the shader or your display. If you crank your display brightness to the max, turn on an enhancement shader and crank it to the max, and launch a game that has an entirely white screen, you could be bombarded with thousands of nits of brightness. And guess what console starts every single game with a solid white screen - the Nintendo Wii! When MayImilae first tested PerceptualHDR, she maxed out her display brightness and the amplification setting, then launched a Wii title. This was her experience. You can easily flashbang yourself with these features, so use this power responsibly. Furthermore, if you are using an HDR display without calibrating it, any time you view SDR content you are already experiencing inverse tone mapping. Most current generation displays, televisions and phones especially, don't care about accurate SDR recreation and by default boost saturation and brightness way beyond SDR spec. They are already turning SDR content into HDR content by default! As such, you may turn on AutoHDR or PerceptualHDR and see a dimmer and duller appearance than you had without any HDR enhancements. If this occurs, our HDR enhancements' inverse tone mapping is more conservative than what you are used to! The world of HDR is a varied and wild place. With "HDR" spanning everything from 300 nits peak brightness to 10,000, and from 8-bit dithered 50% DCI-P3 to 12-bit 100% Rec2020 reference monsters, HDR can be very different things depending on your display. Our HDR enhancements add to your existing tools for customizing inverse tone mapping on your HDR display, and you will need to use all of the tools available to you for best results. HDR is like that. That being said, if you are ok with experimenting, HDR has a lot to offer as an enhancement. When everything lines up, these HDR enhancements can improve the game's visuals on a scale similar to raising internal resolution! Games like Super Mario Galaxy and Sonic Colors look great with these enhancements! HDR is messy and complicated and a pain, but when everything lines up and it works correctly, there is nothing quite like it. While our Post-Processing shaders will appear on all platforms, our HDR Post-Processing feature is currently only available in our desktop Qt interface, and requires HDR to work. Functionally, that means that currently our HDR enhancements can only be used on Windows, macOS, and a tiny subset of Linux (that includes the Steam Deck OLED). To use these shaders, have an HDR screen and enable HDR. Then turn on HDR Post-Processing... And select an HDR Post-Processing Shader! HDR Post-Processing is currently not available on Android. 5.0-21253 - Implement Modem Adapter by fuzziqersoftware¶ The GameCube was released in the early days of the ubiquitous internet. In 2001, dial-up was still a normal way to go online, but broadband was increasingly spreading its tendrils throughout the globe, and our chronically-online doom-scrolling future was already well on its way to consuming us all. To facilitate experimenting with this terrifying new frontier, the GameCube had an accessory port on the bottom that could fit the GameCube BroadBand Adapter (BBA), a 10/100mbps ethernet adapter that allowed the GameCube entry to the information superhighway! The BroadBand Adapter Instruction Booklet walked users through the arduous installation process. Since it was an addon accessory for an experimental feature, it saw limited support in the GameCube lineup. Some games used the BBA for its LAN mode, allowing players to connect multiple GameCubes together locally for crazy high player numbers while avoiding that whole scary internet thing. But a select few games dove right into the Online mode, requiring an internet adapter and an internet connection! The iconic Phantasy Star Online MMO franchise survived the fall of the Dreamcast this way. However, while the BBA is reasonably well known amoungst GameCube enthusiasts, there was another accessory that could go into that port - The GameCube Modem Adapter. This was a 56kbps dial-up modem alternative to the BBA. While it lacked the LAN mode, the Modem Adapter granted more or less the same online features as the BroadBand Adapter, just... worse. All online-mode games that supported the BroadBand Adapter also supported the Modem Adapter, so users were expected to just pick the internet adapter that matched their connection and access the same online content. Though, with some mild variation in user experience. Except, for one game. There is one game that requires the GameCube Modem Adapter, and does not work with the BroadBand Adapter! This game is Phantasy Star Online Episode I & II Trial Edition. The final version of PSO I & II supports the BBA, but its Trial does not. Dolphin only supported the BroadBand Adapter, so for the entirety of Dolphin's existence, PSO I & II Trial Edition required game modification to be playable in Dolphin! This change resolves that. fuzziqersoftware, a developer behind PSO reverse engineering tools and PSO custom servers, has implemented tapserver-based Modem Adapter emulation in Dolphin! By combining modem adapter emulation with a compatible custom server, Phantasy Star Online Episode I & II Trial Edition is playable in Dolphin for the very first time without action replay codes or game patches! Not only is this a win for preservation of this interesting era of GameCube hardware and PSO development, it's also a mark off the very short list of GameCube games that cannot be played in Dolphin without modification. 5.0-21345 - JitCache: Software Profiling Restoration by mitaclaw¶ As was mentioned earlier in this Progress Report, software JIT profiling is one of a small group of debug features left inaccessible by the transition from DolphinWX to DolphinQt. The underlying feature had a partial return as the component powering the Code Diff Tool, before that tool was replaced with the Branch Watch Tool shown previously. Following this, mitaclaw decided he must restore software JIT profiling to its former glory - it's the least he could do after leaving it abandoned once again. It's unlikely this feature will have many users, even among Dolphin's developers, but it's good to see an old feature get rekindled rather than extinguished. Here it is resurrected in DolphinQt. And for the first time, Android! Last Month's Contributors...¶ Special thanks to all of the contributors that incremented Dolphin from 5.0-21090 through to 5.0-21460! Social Media Update¶ We are now maintaining three social media presences: Mastodon, Bluesky, and Twitter! The content on these accounts will largely mirror each other. Our Mastodon is our flagship social media presence, it is strongly under our control (literally living on our servers) and truest to our open source philosophy. Twitter is our oldest account, with over a decade of history! Hopefully that will continue. And finally, our Bluesky is brand new! Feel free to follow us on whichever you'd like! Why Dolphin Isn’t Coming to the iOS App Store¶ In early April, Apple shocked the emulation community by updating their App Store Guidelines to permit retro game console emulators on the App Store. While there was some initial debate over whether the new guidelines only permitted "officially-developed" emulators, community-made emulators soon began appearing on the App Store. The floodgates were open. Ever since this happened, one question we've been frequently asked is "when will Dolphin come to the App Store?" Unfortunately, due to other restrictions set by Apple, we are not able to release Dolphin on the App Store. This also applies to app marketplaces in Europe, like AltStore PAL. The GameCube and Wii both use a PowerPC-based CPU, while most modern devices use x86-64 (Intel & AMD) and AArch64 (ARM) based processors. To be able to run GameCube and Wii machine code, Dolphin uses a Just-in-Time (JIT) recompiler to translate it into code that our modern CPUs can understand. This works well on all of our supported platforms. There's just one problem: Apple does not allow third-party apps to use JIT recompilers on iOS and iPadOS. Dolphin does have both the Interpreter and Cached Interpreter, which are JIT-less methods for emulating the CPU. However, they are many times slower than Dolphin's JITs, making them unusable for actually playing games. Click to see our Cached Interpreter race our JIT on an iPhone 15 Pro Max!For longer versions of these videos with sound: Interpreter, JIT There is one very narrow exception to the "no JIT" rule on iOS - alternative web browsers in Europe. This is because many web browsing engines utilize JITs to speed up JavaScript execution. As allowing alternative browsers is required in Europe under the Digital Markets Act (DMA), Apple gave these apps a special exemption in iOS 17.4. However, Dolphin is not a web browser, and Apple has very specific requirements that they use to check whether an app is really a web browser or not. JITs in web browsers are also subject to additional security requirements, such as separating the JIT into its own isolated and locked down process. This is extremely problematic for Dolphin, which expects everything to be included in one process. While retooling Dolphin to work within these constraints is theoretically possible, it would require a large architectural redesign and a significant amount of effort just for one platform. Apple may also just choose to ban our app in the end anyways for pretending to be a web browser. After reading about web browsers being able to use JIT recompilers, you may be wondering "why not just make a version of Dolphin that runs in a web browser?" Well, easier said than done! To make a usable web version of Dolphin, someone would need to write a brand new JIT targeting WebAssembly and add WebGL support to our OpenGL video backend. While we don't want to say that a web version of Dolphin is completely impossible, working on one just isn't in any of our plans at the moment. Another suggestion we've received is that we should use ahead-of-time compilation (AOT) on these platforms. This would involve re-compiling all of a game's code to AArch64 in advance, which lets us avoid having to generate the code on the actual device with a JIT. Unfortunately, having to rely solely on AOT compilation would likely cause several compatibility problems. These issues largely stem from the fact that games are freely able to self-modify their code. Some EA games, for example, store their code compressed on disc, and then decompress it at runtime. Other games are even able to generate entirely new code with a JIT of their own! The official Nintendo 64 emulator used in Virtual Console releases is one notable example of this, as it includes a JIT for emulation of the Nintendo 64's MIPS-based CPU. Since we aren't able to know with certainty what code will be executed before the game runs, it isn't feasible to use an AOT recompiler as the sole method for emulating the CPU. As such, barring Apple having another sudden change of heart or some other miracle, an iOS App Store release is off the table for Dolphin. [Less]

With the conclusion of the holiday season, it's time for us at the blog to get back to work. And this time around, we have a smattering of changes covering just about everything you could imagine. For those looking to enjoy some of the ... [More] latest homebrew with DSP-HLE, Dolphin now has support for the latest homebrew microcodes! For retail games, we also have a minor update to the Zelda-HLE microcode to fix a missing effect that's long overdo. In some more important news, for those of you having disk space issues when running Dolphin on Windows since the last beta, a fix is now available. And for those looking for the clearest picture possible, Dolphin's mipmap heuristic has been backed down to allow for higher resolution mipmaps across more textures. And of course, if you're wanting that perfect image, Custom Aspect Ratios will allow for easier use of ultra-widescreen hacks and more! Add to all of that a huge bugfix for older revision Steam Decks, another chapter in the Bounding Box saga, seeing a classic in an all new way, and yet another chapter in broken GPU drivers, and you've got yourself a Dolphin Progress Report. Enjoy. Notable Changes¶ 5.0-20353 - DSPHLE: Support 2023 libaesnd uCode by Pokechu22¶ libasnd and libaesnd are open source DSP microcodes for the GameCube and Wii, and are the standard DSP microcodes used by homebrew. When Pokechu22 reimplemented the libasnd and libaesnd microcodes in DSP-HLE back in 2022, we knew that if they were to ever be updated, the new versions would not automatically work in DSP-HLE. This is due to how DSP-HLE itself works - rather than emulating the DSP hardware and running the microcodes directly, DSP-HLE runs reimplementations of the microcodes themselves, made in C++. Thanks to a tremendous amount of work, this is just as accurate as the hardware-emulating DSP-LLE, yet many times faster. However, since DSP-HLE doesn't actually run the microcodes, Dolphin checks the hash of the microcode in the game to know what to use. If the hash of the game's microcode doesn't match any of the reimplemented microcodes, DSP-HLE will fallback to the reimplemented AX microcode, and in the case of homebrew probably not emit any sound at all. This occurred in 2023, when libaesnd saw an update to address a few minor issues. These small fixes meant a new microcode version with a brand new hash which Dolphin did not recognize, resulting in audio not working under DSP-HLE in titles that used the new version of libaesnd. Specifically, it was the latest versions of the Sonic Mania Wii decompilation port that brought this update to our attention. As a fairly new project in active development, they are consistently updating their microcodes, and they are the first software we are aware of to use the new updates. Thankfully, the updates to libaesnd were relatively minor and Pokechu22 mostly just had to document what was changed and add the 2023 hash to the libaesnd code paths in DSP-HLE. With that, users can enjoy Mania's Chemical Plant Zone theme in DSP-HLE once again! Sonic Mania running in Dolphin, with sound in DSP-HLE! 5.0-20880 - Zelda-HLE: Fix Reverb Volume Factor by flacs¶ Sticking to the theme of DSP-HLE, we have a microfix from longtime contributor flacs. This in particular targets the missing reverb effects noticed in Mario Kart Double Dash!!. These effects were noted to be broken way back in 2015 but was marked as low priority amidst a massive Zelda-HLE rewrite. When the rewrite was complete, this bug remained as a minor issue. flacs returned and has been hammering down bugs in all quadrants. This one turned out to be rather simple. The reverb volume was erroneously being multiplied by current volume twice, resulting in the effect becoming incredibly quiet. While the bug reporters originally thought the reverb was missing, they actually just weren't listening hard enough for it! Once this oversight was fixed, the effect started working as intended. 5.0-20517 - Implement Send Mail by Sketch¶ Have you ever had an important work email that you needed to send right now but all you had at your disposal was an emulated Wii? This is a position I think we can say every single one of us have been at some point, but unfortunately in the past there was nothing you could do about it. Thankfully, Sketch took note of the plight of our users and has been slowly working through the Wii Mail system, and while it's not entirely complete, those registered with the WiiLink service can send messages to other Wiis and even emails directly from Dolphin! To get to this point, it's been a rather long ride, and a ton of the legwork was already done for WiiConnect24 emulation. Soon, we're hoping to have full parity between using WiiLink on a console and Dolphin, though there are still some missing features on the Dolphin side of things. 5.0-20589 - Rewrite LazyMemoryRegion by AdmiralCurtiss¶ Last Progress Report, we described a performance optimization that had the annoying side effect of taking up 32 GiB of disk space on Windows. Now AdmiralCurtiss has rewritten the code used on Windows to avoid side effects of this kind. To summarize the problem from last time: Dolphin needed a 32 GiB memory allocation to efficiently keep track of where recompiled code was located. Most of it didn't need to be backed by real memory, but whenever Dolphin wanted to access a particular location, real memory had to be allocated on the fly so the access wouldn't fail. In the solution described in the previous Progress Report, we handled this by asking the operating system to allocate pages for us as needed. This worked well on almost every OS, but on Windows we ran into the problem that the system would force the page file to grow to match our huge 32 GiB allocation, in case we try to access all 32 GiB. With the new solution, we're handling things more manually on Windows. AdmiralCurtiss's initial idea was to mimic what the operating system was doing by setting up a signal handler that runs when Dolphin tries to access an address that isn't backed by real memory – something Dolphin is already doing for the tried and tested fastmem optimization – and then allocating some real memory when the signal handler runs. But because Dolphin only writes to the 32 GiB region from two pieces of code, both of which run relatively infrequently, Progress Report reader PJB3005 was able to come up with a simpler solution that AdmiralCurtiss then implemented. Instead of using a signal handler, Dolphin now manually checks if it needs to allocate any real memory before it writes to the 32 GiB region. Parts of the 32 GiB region that aren't yet backed by real memory are pointed to a read-only page filled with zeroes, so that nothing will go wrong if Dolphin tries to read from a location that hasn't been written to. Now Dolphin users on Windows are able to benefit from the JIT Block Lookup performance optimization without worrying about Windows making their page file balloon. Issues like not being able to download large files while Dolphin is running will no longer occur. On operating systems other than Windows, Dolphin is still using the old approach where the OS allocates real memory on the fly, since we've only seen problems with that approach on Windows. 5.0-20745 - Disable Arbitrary Mipmap Detection by Default by iwubcode¶ As part of the essential hack that is raising Internal Resolution, Dolphin adjusts the mipmap level of textures. Mipmapping is the process of swapping to lower resolution versions of textures if they would appear too small in the final image. This is an old graphics staple - using maximum resolution textures everywhere leads to severe aliasing and moire on distant textures and textures at oblique angles. However, this is resolution dependent, and mipmap targets set for 480p will be intensely blurry at 4K. So Dolphin adjusts the mipmap levels to match the increased Internal Resolution, significantly improving overall texture quality of the final image. However, some GameCube and Wii titles use mipmap shenanigans for effects, and by changing the mipmap levels, we were breaking these tricks. To have our high resolution cake and eat it too, in 2017 we added Arbitrary Mipmap Detection, a heuristic that attempts to detect mipmap mischief and drop to a more accurate mipmap implementation for only the textures involved in these effects. The result is that the specific textures used for these effects will be blurrier, but as it is correcting broken effects and should only affect the specific textures involved, it's a win win. Theoretically. Galaxy 2 reads the mipmap level to control this fog effect in the sky. Without Arbitrary Mipmap Detection, the fog is gone and the clouds repeat infinitely. Unfortunately, this heuristic has proven to be problematic. It often has false positives, incorrectly detecting mipmaps as being used for effects and needlessly using blurrier versions. With Arbitrary Mipmaps, the back of the ship in Skies of Arcadia is much blurrier than it should be. Without Arbitrary Mipmap Detection, the ship is considerably crisper. To account for this, in 2018 we added the Arbitrary Mipmap Detection toggle. On by default, this option gave anyone who was having trouble with the heuristic the ability to simply turn it off, and avoid any problems it may cause. It was a simple solution, and it has remained ever since. Fast forward to late 2023, and iwubcode asked a question that shook us all: "how many games use arbitrary mipmaps for effects?" In the resulting back and forth, we realized the number of games that utilize mipmap hijinks is... not a lot. To our knowledge, only Nintendo used this technique. Of course these were games by Nintendo, titles that are flagships of the GameCube and Wii lineup, like Super Mario Galaxy and The Legend of Zelda: The Wind Waker. However, by being such core titles, we realized that the importance of detecting these effects was overestimated. As far as we are aware, a couple dozen games use the trick, and thousands of games do not. Considering just how common and pernicious false positives are with the heuristic, having the heuristic on by default for every game was probably causing more harm than good. So we have decided to change that. Arbitrary Mipmap Detection is now off by default. From now on it will only be enabled by default in known cases, via our GameINI system. If you happen to spot any issues that are resolved by turning on Arbitrary Mipmap Detection, please let us know and we'll add it to the list of known mipmap tomfoolery. 5.0-20785 - Support Custom Aspect Ratios by Filoppi¶ Dolphin's Widescreen Hack is both amazing and terrible in equal measure. By expanding the View Frustum, it allows Dolphin to able to render any game at any aspect ratio, and thus fill any screen without stretching the image! However, the Widescreen Hack is only performed on the Dolphin side, and doesn't affect the game's logic at all. Frustum Culling, screenspace 2D graphics, and more are entirely unmodified. The result is large blank areas in the expanded space, stretched 2D elements, and aberrant pop-in are simply the reality of the Widescreen Hack. Fortunately, we have an alternative - game-specific aspect ratio cheat codes. By editing the game itself through our cheat system, all of these quirks can be addressed and a much better result can be achieved. Wasn't this room supposed to have walls? Through the power of action replay codes, geometry is no longer being culled and we don't have to worry about pop in! However, aspect ratio codes require the user to configure their aspect ratio. For example, to run Ralf's 16:9 Aspect Ratio code for Wind Waker, a user must set Dolphin's aspect ratio to Force 16:9. Simple enough. But what happens if your display is an UltraWide? 21:9 codes are fairly common, but there is no "Force 21:9" option. To work around this, 21:9 display users can set the aspect ratio to "Stretch to Window" and enter fullscreen. This does the job, but this has some issues. Ultrawide aspect ratios are less a standard and more of a suggestion, so even within the 21:9 category, the actual ratios vary. In the real world, our little workaround usually results in minor distortion. But worse still is Super UltraWide. 32:9 aspect ratio codes are few and far between, making the workaround above unviable. The best option available for 32:9 users was to combine a 21:9 code, windowed mode, and Stretch to Window Size, then very carefully size the window so that there was no stretching. Not great. This works, but you have to hide the Windows Taskbar, Windows will not let you move the titlebar of the window off screen if you don't have a secondary monitor, it's a lot of faff to set up, and it requires you to void your wallpaper for the best result. It's not a great experience. Filoppi decided that this will not do, and added a new Custom Aspect Ratio option to Dolphin. Using this feature, you can effectively force Dolphin's aspect ratio to whatever you want. Now, Super UltraWide screen users can enjoy 21:9 in fullscreen without any fuss or distortion! Set up a 21:9 code, configure a Custom Aspect Ratio of 21:9, and just enter fullscreen like normal! It's that easy! Plus, this change allows any aspect ratio on any display, so if you have a 16:9 display and want to play 21:9 on your OLED TV or something, you can do that! In fact, if a theorectical retro port to the GameCube or Wii has an incorrect aspect ratio, this could even be used to correct it! We haven't actually found any of those yet, but it's an intriguing possibility. To use this feature, just set the Aspect Ratio to "Custom", and configure the ratio to whatever you like! However, as we do whenever we give dangerous new powers to users, we must exit with a word of caution. The GameCube and Wii were never exactly 4:3, 5:4, or 16:9. Yes, on hardware. It was the days of analog displays and their crimes were all going to be overscanned away anyway, so game developers had no reason to care about being exact. Back when Dolphin assumed standard aspect ratios, every. single. game. was off to some degree. Remember the Melee shields? This is the hell we used to live in. This was a tremendous headache for us, and to resolve it required months of effort from very skilled engineers, testers, esports communities, and more. It was an enormous undertaking. The result of all that work is that Dolphin reads the exact Aspect Ratio the game is instructing the console to scan out and displays precisely that. And to make sure users see it without distortion, all of our aspect ratio modes used these corrections, with only Stretch to Window bypassing it. Well, now there is a second way to bypass it. A Custom Aspect Ratio will give you exactly what you enter, no matter what. So if you are playing in ordinary 4:3 or 16:9, and you configure the custom aspect ratio to 4:3 or 16:9, you are bypassing Dolphin's aspect ratio adjustment and you will be distorting the image in all cases. Please use this power responsibly. PLEASE. 5.0-20849 - VideoCommon: Apply "Force 24-bit Color" to EFB Copies by flacs¶ "Force 24-bit Color" is an enhancement that reduces banding by forcing the emulated hardware to the highest bitdepth possible. However, there were some cases where turning on the enhancement did not improve banding at all! This change fixes that, but to explain why, we're going to have to get technical. To understand this problem, we need to go over how post-processing works on the GameCube and Wii. This first paragraph may be a little familiar, but bear with us. While rendering, the ArtX GPU in the GameCube and Wii rasterizes to the "Embedded Frame Buffer" (EFB), a 2MiB chunk of extremely fast working memory that resides in the GPU itself. While some basic post-processing can be applied while the frame is in the EFB, any effect that involves reading then distorting the frame cannot be done while it is in the EFB. So for most post-processing effects, games will execute an EFB Copy to transfer the frame to main memory, then read the frame as a texture from which to render again on top of. However, the consoles primarily render in 6-bits per channel RGBA6, but cannot read a texture in that format. To deal with this discrepancy, it is common for games to convert the frame to 8-bits per channel RGBA8 during the EFB Copy to maintain full visual quality. However, a fullscreen image at RGBA8 is HUGE for this hardware. Assuming a 640x480 render target, that would be 9830400 bits, or 1.17MiB! And for post-processing effects, multiple renders need to be made! The GameCube's Main Memory is only 24MiB, and the game needs to live in that space too. So many games opt to EFB Copy some images into main memory in the RGB565 format. A 640x480 RGB565 image is only 4915200 bits in size, or 0.59MiB. That's half the size! But of course, this came at a cost. Most games render in RGBA6. 6-bits per channel is 64 values per color, for 262144 total possible colors (ignoring the alpha channel). RGB565 has two channels at 5-bits (32 values per color), combining to a total of 65536 total possible colors. RGB565 has significantly fewer colors making banding much worse, and it is missing the alpha channel entirely, limiting its uses. However, when the benefit was halving an image's RAM usage on a chronically memory-starved machine, this was a option that many developers utilized. A certain brave developer tried to maximize visual quality by switching between RGBA8 and RGB565 EFB Copies depending on how much memory was available. This was the equivalent of playing hot potato with a hand grenade. Click the explosion above to read that story! And now we return to Dolphin. In Dolphin, we support the original RGBA6 that games usually render with, and all other formats for rendering and EFB Copies. However, the hardware we are running on is almost guaranteed to be 8-bits per channel RGBA8 or better, so we have an enhancement called Force 24-bit Color. This mode forces the emulated console into a hybrid RGBA8-ish mode where the color channels are 8-bits per channel, and the alpha channel remains at 6-bits. This is mildly inaccurate, but it is not that far removed from what the console can do, and it substantially reduces banding. It's a relatively safe enhancement that can significantly improve image quality. However, for Luigi's Mansion, Force 24-bit Color did not affect banding at all. This was the game with Default settings. And here it was with Force 24-bit Color. Yes they are not the same image, we are sure. flacs noticed this discrepancy and looked into it. Force 24-bit Color forces the initial render to use the RGBA8 mode. However, Force 24-bit Color did nothing to EFB Copies, which every frame will undergo at least once! If the game used the typical option of EFB Copying into RGBA8, then Dolphin would take an RGBA8 image and EFB Copy it into an RGBA8 image, and the enhancement would still be in effect. But if the game chose to go with RGB565 (or RGB5A3... we're not going to talk about that one), Dolphin would follow the game's instructions and decimate the RGBA8 rendered image into RGB565, completely destroying the enhancement in the process! Due to the color compromises, most games use RGB565 sparingly, saving it for secondary post processing of effects that only partially cover the screen. Most of the time, the RGB565 pieces of an image would be difficult to spot. Not so with Luigi's Mansion, as it EFB Copies the entire framebuffer in RGB565! This decimates the entire screen, rendering Force 24-bit Color effectively useless! So flacs has corrected this oversight. Now, whenever Force 24-bit Color is enabled, EFB Copies will also use RGBA8 within Dolphin. Thanks to this change, we can see Luigi's Mansion as we never have before! Click/Tap and hold to see the banding improvement Force 24-bit Color can now achieve! Force 24-bit Color will be improved in any title that uses lower quality EFB Copy formats such as RGB565. Players using the feature should look for reduced banding in their favourite titles! However, most games only use these lower quality EFB Copy modes for part of the screen, so most titles that are improved will see a less dramatic change than Luigi's Mansion. 5.0-20923 - Steam Deck: Pad out feature report to 64 bytes by endrift and ArcaneNibble¶ In the previous Progress Report, we covered 5.0-20148 - Periodically Re-enable Steam Deck Gyro. Current versions of SteamOS will try to shut down gyros that it thinks are not being used. This gave us a lot of issues, so this change addressed this by making Dolphin re-enable the gyro on Steam Decks roughly once per second. However, due to SteamOS quirks, it's not easy for users to run Development builds on Steam Decks. Most Steam Deck users get Dolphin builds through Flatpaks of our Beta builds. So while the change was tested by the developers before being merged, it was only after the Report and the Beta release that the Flatpaks were updated and this change was finally able to reach wide adoption in users' hands. And almost immediately, we started to get reports of doubled inputs in the latest version of Dolphin. Uh oh. The author of the change, ArcaneNibble, immediately retested and couldn't reproduce it. And yet reports kept pouring in. So more of our developers tried it, and they couldn't reproduce it either. A few of our users and testers tried it, and weren't able to reproduce it either. Yet more and more reports kept pouring in. What was happening!? This back and forth continued for weeks, until finally, we stumbled upon the answer. Older Steam Decks were affected, and newly built Steam Decks were not. It turns out that the Steam Deck LCD had a major revision in the fall of 2023! The revision completely changed the Deck's internals, with significantly different PCBs and component parts! And sure enough, the Deck's Steam Controller controller chip was refreshed too. Steam Decks made before fall of 2023 use an Atmel controller, while Steam Deck LCDs made after fall of 2023, and all Steam Deck OLEDs, use a Renesas controller. Once we realized this potential source, we asked users to run a command that reported the controller in their Deck. In all of our samples, Steam Decks with Atmel controllers always had the issue, and Decks with the Renesis controller never had it. Now that we knew how to reproduce the issue, we asked developers who work on the Deck for help. endrift, mGBA author and Dolphin contributor, has been working on the Deck a lot lately. She came in and worked with the author of the change for a thorough debugging. It turns out, ArcaneNibble made an tiny oversight and didn't fill in one value. Broken Code: const unsigned char pkt[] = {0x00, 0x87, 0x03, 0x30, 0x18, 0x00}; Working Code: const unsigned char pkt[65] = {0x00, 0x87, 0x03, 0x30, 0x18, 0x00}; ArcaneNibble forgot to pad the packet size of the feature report packet. That's it. Here's endrift explaining what happened: When Steam tells the Steam Deck (or previously the Steam Controller) to change a setting, it uses something called a HID feature report. Feature reports can be up to 64 bytes long in USB 2.0, and the size of a device's report is described in the suitably named report descriptor, which is specified by the HID standard. Feature reports can be split out into up to 256 different IDs, each of which can have a separate size as described in the descriptor. However, for a dynamic system like the Steam Deck, sometimes devices just define a longer-than-used 64 byte report size and just pad the end out with zeroes, then define the ID outside of the descriptor. Steam always sends a fully padded 64 byte report, in accordance with the report descriptor. However, by sending a feature report with less than 64 bytes, the implementation on the USB device end gets confused. Quite possibly later feature reports get misinterpreted as a result, and one of these misinterpreted reports from Steam causes this issue. However, Renesas chips don't appear to get confused and just internally assume the report should be padded to 64 bytes even when fewer are sent. endrift This resulted in Atmel controllers entering a glitched state where they operated in both "Lizard Mode" (the default fallback controls for when Steam is not running) and normal mode at the same time, doubling every input. Renesas controllers, on the other hand, were entirely unaffected. So endrift tested a fix and made a quick PR, and now the double input issue is resolved! While the solution may have ended up being very simple, this bug was a very difficult one to identify. It took the entire Dolphin Steam Deck community chasing this bug for us to figure it out and get it sorted. Thank you to everyone who reported and helped us chase this sneaky bug! 5.0-20941 - SDL: Add GameController API, cleanup by SuperSamus¶ SuperSamus has given our SDL input backend some love. First, they added support for the GameController API, an abstraction that allows consistent mapping across different controllers. Users will be able to switch controllers, i.e. a DualSense to a Switch Pro Controller, seamlessly without remapping! SuperSamus also cleaned up our SDL input backend, cleaning up a bunch of workarounds for old SDL versions that are no longer applicable to current our current SDL2 input backend. SDL is now better than ever before, on all operating systems! In fact, as of this change SDL has once again been enabled by default in our Linux builds! SDL has come a long long way. 5.0-20961 - Only initialize Bounding Box if supported by GPU/driver by AdmiralCurtiss¶ "Renderer" was an abstraction in Dolphin's code that functioned as an interface for video plugins. However, when the video plugins were merged with Dolphin's code and became video backends, Renderer became a dumping ground, filling up with tons of miscellaneous code and features. So, last year, Phire set off with the mission to kill Renderer entirely, refactoring enormous amounts of Dolphin's graphics code. Kill Renderer moved a lot of code around. We covered Kill Renderer here on the blog, both because it was a huge achievement, but also because any change that touched that much of Dolphin's codebase was likely to have unforeseen consequences. And that is what we come to today. After Kill Renderer, we received reports from users on very old GPUs that Dolphin no longer worked for them. Now, any game they attempted to run would fail to start, with the error "Failed to create BoundingBox Buffer." This occurred after running Super Smash Bros. Brawl. That game doesn't even use Bounding Box! After Kill Renderer, Bounding Box was always initialized whether the hardware supported it or not. This doesn't affect most our of userbase, as >99% of our users' hardware supports the feature, but for any hardware that doesn't support Bounding Box, this regression completely broke Dolphin! AdmiralCurtiss looked into this and made a quick fix. As of this change, Dolphin will perform the same as it did before Kill Renderer on those GPUs - Dolphin runs again and games work, but if a user attempts to run a Bounding Box title, they are in for a buggy good time. Mario refuses to be associated with the Intel HD Graphics 3000. Now that's an air ship. Unlike the GameCube, Intel HD Graphics 3000 cannot handle this many sprites at once. Notice for Nvidia Users¶ We've recieved reports of texture corruption in D3D11 on Nvidia GPUs with their latest drivers. This is still developing, as we have yet to properly isolate and analyze this, but we believe it to be some sort of driver issue. For now, we recommend Nvidia users avoid our D3D11 backend. Last Month's Contributors...¶ Special thanks to all of the contributors that incremented Dolphin from 5.0-20349 through to 5.0-21088! [Less]

With the conclusion of the holiday season, it's time for us at the blog to get back to work. And this time around, we have a smattering of changes covering just about everything you could imagine. For those looking to enjoy some of the ... [More] latest homebrew with DSP-HLE, Dolphin now has support for the latest homebrew microcodes! For retail games, we also have a minor update to the Zelda-HLE microcode to fix a missing effect that's long overdue. In some more important news, for those of you having disk space issues when running Dolphin on Windows since the last beta, a fix is now available. And for those looking for the clearest picture possible, Dolphin's mipmap heuristic has been backed down to allow for higher resolution mipmaps across more textures. And of course, if you're wanting that perfect image, Custom Aspect Ratios will allow for easier use of ultra-widescreen hacks and more! Add to all of that a huge bugfix for older revision Steam Decks, another chapter in the Bounding Box saga, seeing a classic in an all new way, and yet another chapter in broken GPU drivers, and you've got yourself a Dolphin Progress Report. Enjoy. Notable Changes¶ 5.0-20353 - DSPHLE: Support 2023 libaesnd uCode by Pokechu22¶ libasnd and libaesnd are open source DSP microcodes for the GameCube and Wii, and are the standard DSP microcodes used by homebrew. When Pokechu22 reimplemented the libasnd and libaesnd microcodes in DSP-HLE back in 2022, we knew that if they were to ever be updated, the new versions would not automatically work in DSP-HLE. This is due to how DSP-HLE itself works - rather than emulating the DSP hardware and running the microcodes directly, DSP-HLE runs reimplementations of the microcodes themselves, made in C++. Thanks to a tremendous amount of work, this is just as accurate as the hardware-emulating DSP-LLE, yet many times faster. However, since DSP-HLE doesn't actually run the microcodes, Dolphin checks the hash of the microcode in the game to know what to use. If the hash of the game's microcode doesn't match any of the reimplemented microcodes, DSP-HLE will fallback to the reimplemented AX microcode, and in the case of homebrew probably not emit any sound at all. This occurred in 2023, when libaesnd saw an update to address a few minor issues. These small fixes meant a new microcode version with a brand new hash which Dolphin did not recognize, resulting in audio not working under DSP-HLE in titles that used the new version of libaesnd. Specifically, it was the latest versions of the Sonic Mania Wii decompilation port that brought this update to our attention. As a fairly new project in active development, they are consistently updating their microcodes, and they are the first software we are aware of to use the new updates. Thankfully, the updates to libaesnd were relatively minor and Pokechu22 mostly just had to document what was changed and add the 2023 hash to the libaesnd code paths in DSP-HLE. With that, users can enjoy Mania's Chemical Plant Zone theme in DSP-HLE once again! Sonic Mania running in Dolphin, with sound in DSP-HLE! 5.0-20880 - Zelda-HLE: Fix Reverb Volume Factor by flacs¶ Sticking to the theme of DSP-HLE, we have a microfix from longtime contributor flacs. This in particular targets the missing reverb effects noticed in Mario Kart Double Dash!!. These effects were noted to be broken way back in 2015 but was marked as low priority amidst a massive Zelda-HLE rewrite. When the rewrite was complete, this bug remained as a minor issue. flacs returned and has been hammering down bugs in all quadrants. This one turned out to be rather simple. The reverb volume was erroneously being multiplied by current volume twice, resulting in the effect becoming incredibly quiet. While the bug reporters originally thought the reverb was missing, they actually just weren't listening hard enough for it! Once this oversight was fixed, the effect started working as intended. 5.0-20517 - Implement Send Mail by Sketch¶ Have you ever had an important work email that you needed to send right now but all you had at your disposal was an emulated Wii? This is a position I think we can say every single one of us have been at some point, but unfortunately in the past there was nothing you could do about it. Thankfully, Sketch took note of the plight of our users and has been slowly working through the Wii Mail system, and while it's not entirely complete, those registered with the WiiLink service can send messages to other Wiis and even emails directly from Dolphin! To get to this point, it's been a rather long ride, and a ton of the legwork was already done for WiiConnect24 emulation. Soon, we're hoping to have full parity between using WiiLink on a console and Dolphin, though there are still some missing features on the Dolphin side of things. 5.0-20589 - Rewrite LazyMemoryRegion by AdmiralCurtiss¶ Last Progress Report, we described a performance optimization that had the annoying side effect of taking up 32 GiB of disk space on Windows. Now AdmiralCurtiss has rewritten the code used on Windows to avoid side effects of this kind. To summarize the problem from last time: Dolphin needed a 32 GiB memory allocation to efficiently keep track of where recompiled code was located. Most of it didn't need to be backed by real memory, but whenever Dolphin wanted to access a particular location, real memory had to be allocated on the fly so the access wouldn't fail. In the solution described in the previous Progress Report, we handled this by asking the operating system to allocate pages for us as needed. This worked well on almost every OS, but on Windows we ran into the problem that the system would force the page file to grow to match our huge 32 GiB allocation, in case we try to access all 32 GiB. With the new solution, we're handling things more manually on Windows. AdmiralCurtiss's initial idea was to mimic what the operating system was doing by setting up a signal handler that runs when Dolphin tries to access an address that isn't backed by real memory – something Dolphin is already doing for the tried and tested fastmem optimization – and then allocating some real memory when the signal handler runs. But because Dolphin only writes to the 32 GiB region from two pieces of code, both of which run relatively infrequently, Progress Report reader PJB3005 was able to come up with a simpler solution that AdmiralCurtiss then implemented. Instead of using a signal handler, Dolphin now manually checks if it needs to allocate any real memory before it writes to the 32 GiB region. Parts of the 32 GiB region that aren't yet backed by real memory are pointed to a read-only page filled with zeroes, so that nothing will go wrong if Dolphin tries to read from a location that hasn't been written to. Now Dolphin users on Windows are able to benefit from the JIT Block Lookup performance optimization without worrying about Windows making their page file balloon. Issues like not being able to download large files while Dolphin is running will no longer occur. On operating systems other than Windows, Dolphin is still using the old approach where the OS allocates real memory on the fly, since we've only seen problems with that approach on Windows. 5.0-20745 - Disable Arbitrary Mipmap Detection by Default by iwubcode¶ As part of the essential hack that is raising Internal Resolution, Dolphin adjusts the mipmap level of textures. Mipmapping is the process of swapping to lower resolution versions of textures if they would appear too small in the final image. This is an old graphics staple - using maximum resolution textures everywhere leads to severe aliasing and moire on distant textures and textures at oblique angles. However, this is resolution dependent, and mipmap targets set for 480p will be intensely blurry at 4K. So Dolphin adjusts the mipmap levels to match the increased Internal Resolution, significantly improving overall texture quality of the final image. However, some GameCube and Wii titles use mipmap shenanigans for effects, and by changing the mipmap levels, we were breaking these tricks. To have our high resolution cake and eat it too, in 2017 we added Arbitrary Mipmap Detection, a heuristic that attempts to detect mipmap mischief and drop to a more accurate mipmap implementation for only the textures involved in these effects. The result is that the specific textures used for these effects will be blurrier, but as it is correcting broken effects and should only affect the specific textures involved, it's a win win. Theoretically. Galaxy 2 reads the mipmap level to control this fog effect in the sky. Without Arbitrary Mipmap Detection, the fog is gone and the clouds repeat infinitely. Unfortunately, this heuristic has proven to be problematic. It often has false positives, incorrectly detecting mipmaps as being used for effects and needlessly using blurrier versions. With Arbitrary Mipmaps, the back of the ship in Skies of Arcadia is much blurrier than it should be. Without Arbitrary Mipmap Detection, the ship is considerably crisper. To account for this, in 2018 we added the Arbitrary Mipmap Detection toggle. On by default, this option gave anyone who was having trouble with the heuristic the ability to simply turn it off, and avoid any problems it may cause. It was a simple solution, and it has remained ever since. Fast forward to late 2023, and iwubcode asked a question that shook us all: "how many games use arbitrary mipmaps for effects?" In the resulting back and forth, we realized the number of games that utilize mipmap hijinks is... not a lot. To our knowledge, only Nintendo used this technique. Of course these were games by Nintendo, titles that are flagships of the GameCube and Wii lineup, like Super Mario Galaxy and The Legend of Zelda: The Wind Waker. However, by being such core titles, we realized that the importance of detecting these effects was overestimated. As far as we are aware, a couple dozen games use the trick, and thousands of games do not. Considering just how common and pernicious false positives are with the heuristic, having the heuristic on by default for every game was probably causing more harm than good. So we have decided to change that. Arbitrary Mipmap Detection is now off by default. From now on it will only be enabled by default in known cases, via our GameINI system. If you happen to spot any issues that are resolved by turning on Arbitrary Mipmap Detection, please let us know and we'll add it to the list of known mipmap tomfoolery. 5.0-20785 - Support Custom Aspect Ratios by Filoppi¶ Dolphin's Widescreen Hack is both amazing and terrible in equal measure. By expanding the View Frustum, it allows Dolphin to able to render any game at any aspect ratio, and thus fill any screen without stretching the image! However, the Widescreen Hack is only performed on the Dolphin side, and doesn't affect the game's logic at all. Frustum Culling, screenspace 2D graphics, and more are entirely unmodified. The result is large blank areas in the expanded space, stretched 2D elements, and aberrant pop-in are simply the reality of the Widescreen Hack. Fortunately, we have an alternative - game-specific aspect ratio cheat codes. By editing the game itself through our cheat system, all of these quirks can be addressed and a much better result can be achieved. Wasn't this room supposed to have walls? Through the power of action replay codes, geometry is no longer being culled and we don't have to worry about pop in! However, aspect ratio codes require the user to configure their aspect ratio. For example, to run Ralf's 16:9 Aspect Ratio code for Wind Waker, a user must set Dolphin's aspect ratio to Force 16:9. Simple enough. But what happens if your display is an UltraWide? 21:9 codes are fairly common, but there is no "Force 21:9" option. To work around this, 21:9 display users can set the aspect ratio to "Stretch to Window" and enter fullscreen. This does the job, but this has some issues. Ultrawide aspect ratios are less a standard and more of a suggestion, so even within the 21:9 category, the actual ratios vary. In the real world, our little workaround usually results in minor distortion. But worse still is Super UltraWide. 32:9 aspect ratio codes are few and far between, making the workaround above unviable. The best option available for 32:9 users was to combine a 21:9 code, windowed mode, and Stretch to Window Size, then very carefully size the window so that there was no stretching. Not great. This works, but you have to hide the Windows Taskbar, Windows will not let you move the titlebar of the window off screen if you don't have a secondary monitor, it's a lot of faff to set up, and it requires you to void your wallpaper for the best result. It's not a great experience. Filoppi decided that this will not do, and added a new Custom Aspect Ratio option to Dolphin. Using this feature, you can effectively force Dolphin's aspect ratio to whatever you want. Now, Super UltraWide screen users can enjoy 21:9 in fullscreen without any fuss or distortion! Set up a 21:9 code, configure a Custom Aspect Ratio of 21:9, and just enter fullscreen like normal! It's that easy! Plus, this change allows any aspect ratio on any display, so if you have a 16:9 display and want to play 21:9 on your OLED TV or something, you can do that! In fact, if a theorectical retro port to the GameCube or Wii has an incorrect aspect ratio, this could even be used to correct it! We haven't actually found any of those yet, but it's an intriguing possibility. To use this feature, just set the Aspect Ratio to "Custom", and configure the ratio to whatever you like! However, as we do whenever we give dangerous new powers to users, we must exit with a word of caution. The GameCube and Wii were never exactly 4:3, 5:4, or 16:9. Yes, on hardware. It was the days of analog displays and their crimes were all going to be overscanned away anyway, so game developers had no reason to care about being exact. Back when Dolphin assumed standard aspect ratios, every. single. game. was off to some degree. Remember the Melee shields? This is the hell we used to live in. This was a tremendous headache for us, and to resolve it required months of effort from very skilled engineers, testers, esports communities, and more. It was an enormous undertaking. The result of all that work is that Dolphin reads the exact Aspect Ratio the game is instructing the console to scan out and displays precisely that. And to make sure users see it without distortion, all of our aspect ratio modes used these corrections, with only Stretch to Window bypassing it. Well, now there is a second way to bypass it. A Custom Aspect Ratio will give you exactly what you enter, no matter what. So if you are playing in ordinary 4:3 or 16:9, and you configure the custom aspect ratio to 4:3 or 16:9, you are bypassing Dolphin's aspect ratio adjustment and you will be distorting the image in all cases. Please use this power responsibly. PLEASE. 5.0-20849 - VideoCommon: Apply "Force 24-bit Color" to EFB Copies by flacs¶ "Force 24-bit Color" is an enhancement that reduces banding by forcing the emulated hardware to the highest bitdepth possible. However, there were some cases where turning on the enhancement did not improve banding at all! This change fixes that, but to explain why, we're going to have to get technical. To understand this problem, we need to go over how post-processing works on the GameCube and Wii. This first paragraph may be a little familiar, but bear with us. While rendering, the ArtX GPU in the GameCube and Wii rasterizes to the "Embedded Frame Buffer" (EFB), a 2MiB chunk of extremely fast working memory that resides in the GPU itself. While some basic post-processing can be applied while the frame is in the EFB, any effect that involves reading then distorting the frame cannot be done while it is in the EFB. So for most post-processing effects, games will execute an EFB Copy to transfer the frame to main memory, then read the frame as a texture from which to render again on top of. However, the consoles primarily render in 6-bits per channel RGBA6, but cannot read a texture in that format. To deal with this discrepancy, it is common for games to convert the frame to 8-bits per channel RGBA8 during the EFB Copy to maintain full visual quality. However, a fullscreen image at RGBA8 is HUGE for this hardware. Assuming a 640x480 render target, that would be 9830400 bits, or 1.17MiB! And for post-processing effects, multiple renders need to be made! The GameCube's Main Memory is only 24MiB, and the game needs to live in that space too. So many games opt to EFB Copy some images into main memory in the RGB565 format. A 640x480 RGB565 image is only 4915200 bits in size, or 0.59MiB. That's half the size! But of course, this came at a cost. Most games render in RGBA6. 6-bits per channel is 64 values per color, for 262144 total possible colors (ignoring the alpha channel). RGB565 has two channels at 5-bits (32 values per color), combining to a total of 65536 total possible colors. RGB565 has significantly fewer colors making banding much worse, and it is missing the alpha channel entirely, limiting its uses. However, when the benefit was halving an image's RAM usage on a chronically memory-starved machine, this was a option that many developers utilized. A certain brave developer tried to maximize visual quality by switching between RGBA8 and RGB565 EFB Copies depending on how much memory was available. This was the equivalent of playing hot potato with a hand grenade. Click the explosion above to read that story! And now we return to Dolphin. In Dolphin, we support the original RGBA6 that games usually render with, and all other formats for rendering and EFB Copies. However, the hardware we are running on is almost guaranteed to be 8-bits per channel RGBA8 or better, so we have an enhancement called Force 24-bit Color. This mode forces the emulated console into a hybrid RGBA8-ish mode where the color channels are 8-bits per channel, and the alpha channel remains at 6-bits. This is mildly inaccurate, but it is not that far removed from what the console can do, and it substantially reduces banding. It's a relatively safe enhancement that can significantly improve image quality. However, for Luigi's Mansion, Force 24-bit Color did not affect banding at all. This was the game with Default settings. And here it was with Force 24-bit Color. Yes they are not the same image, we are sure. flacs noticed this discrepancy and looked into it. Force 24-bit Color forces the initial render to use the RGBA8 mode. However, Force 24-bit Color did nothing to EFB Copies, which every frame will undergo at least once! If the game used the typical option of EFB Copying into RGBA8, then Dolphin would take an RGBA8 image and EFB Copy it into an RGBA8 image, and the enhancement would still be in effect. But if the game chose to go with RGB565 (or RGB5A3... we're not going to talk about that one), Dolphin would follow the game's instructions and decimate the RGBA8 rendered image into RGB565, completely destroying the enhancement in the process! Due to the color compromises, most games use RGB565 sparingly, saving it for secondary post processing of effects that only partially cover the screen. Most of the time, the RGB565 pieces of an image would be difficult to spot. Not so with Luigi's Mansion, as it EFB Copies the entire framebuffer in RGB565! This decimates the entire screen, rendering Force 24-bit Color effectively useless! So flacs has corrected this oversight. Now, whenever Force 24-bit Color is enabled, EFB Copies will also use RGBA8 within Dolphin. Thanks to this change, we can see Luigi's Mansion as we never have before! Click/Tap and hold to see the banding improvement Force 24-bit Color can now achieve! Force 24-bit Color will be improved in any title that uses lower quality EFB Copy formats such as RGB565. Players using the feature should look for reduced banding in their favourite titles! However, most games only use these lower quality EFB Copy modes for part of the screen, so most titles that are improved will see a less dramatic change than Luigi's Mansion. 5.0-20923 - Steam Deck: Pad out feature report to 64 bytes by endrift and ArcaneNibble¶ In the previous Progress Report, we covered 5.0-20148 - Periodically Re-enable Steam Deck Gyro. Current versions of SteamOS will try to shut down gyros that it thinks are not being used. This gave us a lot of issues, so this change addressed this by making Dolphin re-enable the gyro on Steam Decks roughly once per second. However, due to SteamOS quirks, it's not easy for users to run Development builds on Steam Decks. Most Steam Deck users get Dolphin builds through Flatpaks of our Beta builds. So while the change was tested by the developers before being merged, it was only after the Report and the Beta release that the Flatpaks were updated and this change was finally able to reach wide adoption in users' hands. And almost immediately, we started to get reports of doubled inputs in the latest version of Dolphin. Uh oh. The author of the change, ArcaneNibble, immediately retested and couldn't reproduce it. And yet reports kept pouring in. So more of our developers tried it, and they couldn't reproduce it either. A few of our users and testers tried it, and weren't able to reproduce it either. Yet more and more reports kept pouring in. What was happening!? This back and forth continued for weeks, until finally, we stumbled upon the answer. Older Steam Decks were affected, and newly built Steam Decks were not. It turns out that the Steam Deck LCD had a major revision in the fall of 2023! The revision completely changed the Deck's internals, with significantly different PCBs and component parts! And sure enough, the Deck's Steam Controller controller chip was refreshed too. Steam Decks made before fall of 2023 use an Atmel controller, while Steam Deck LCDs made after fall of 2023, and all Steam Deck OLEDs, use a Renesas controller. Once we realized this potential source, we asked users to run a command that reported the controller in their Deck. In all of our samples, Steam Decks with Atmel controllers always had the issue, and Decks with the Renesas controller never had it. Now that we knew how to reproduce the issue, we asked developers who work on the Deck for help. endrift, mGBA author and Dolphin contributor, has been working on the Deck a lot lately. She came in and worked with the author of the change for a thorough debugging. It turns out, ArcaneNibble made an tiny oversight and didn't fill in one value. Broken Code: const unsigned char pkt[] = {0x00, 0x87, 0x03, 0x30, 0x18, 0x00}; Working Code: const unsigned char pkt[65] = {0x00, 0x87, 0x03, 0x30, 0x18, 0x00}; ArcaneNibble forgot to pad the packet size of the feature report packet. That's it. Here's endrift explaining what happened: When Steam tells the Steam Deck (or previously the Steam Controller) to change a setting, it uses something called a HID feature report. Feature reports can be up to 64 bytes long in USB 2.0, and the size of a device's report is described in the suitably named report descriptor, which is specified by the HID standard. Feature reports can be split out into up to 256 different IDs, each of which can have a separate size as described in the descriptor. However, for a dynamic system like the Steam Deck, sometimes devices just define a longer-than-used 64 byte report size and just pad the end out with zeroes, then define the ID outside of the descriptor. Steam always sends a fully padded 64 byte report, in accordance with the report descriptor. However, by sending a feature report with less than 64 bytes, the implementation on the USB device end gets confused. Quite possibly later feature reports get misinterpreted as a result, and one of these misinterpreted reports from Steam causes this issue. However, Renesas chips don't appear to get confused and just internally assume the report should be padded to 64 bytes even when fewer are sent. endrift This resulted in Atmel controllers entering a glitched state where they operated in both "Lizard Mode" (the default fallback controls for when Steam is not running) and normal mode at the same time, doubling every input. Renesas controllers, on the other hand, were entirely unaffected. So endrift tested a fix and made a quick PR, and now the double input issue is resolved! While the solution may have ended up being very simple, this bug was a very difficult one to identify. It took the entire Dolphin Steam Deck community chasing this bug for us to figure it out and get it sorted. Thank you to everyone who reported and helped us chase this sneaky bug! 5.0-20941 - SDL: Add GameController API, cleanup by SuperSamus¶ SuperSamus has given our SDL input backend some love. First, they added support for the GameController API, an abstraction that allows consistent mapping across different controllers. Users will be able to switch controllers, i.e. a DualSense to a Switch Pro Controller, seamlessly without remapping! SuperSamus also cleaned up our SDL input backend, cleaning up a bunch of workarounds for old SDL versions that are no longer applicable to our current SDL2 input backend. SDL is now better than ever before, on all operating systems! In fact, as of this change SDL has once again been enabled by default in our Linux builds! SDL has come a long long way. 5.0-20961 - Only initialize Bounding Box if supported by GPU/driver by AdmiralCurtiss¶ "Renderer" was an abstraction in Dolphin's code that functioned as an interface for video plugins. However, when the video plugins were merged with Dolphin's code and became video backends, Renderer became a dumping ground, filling up with tons of miscellaneous code and features. So, last year, Phire set off with the mission to kill Renderer entirely, refactoring enormous amounts of Dolphin's graphics code. Kill Renderer moved a lot of code around. We covered Kill Renderer here on the blog, both because it was a huge achievement, but also because any change that touched that much of Dolphin's codebase was likely to have unforeseen consequences. And that is what we come to today. After Kill Renderer, we received reports from users on very old GPUs that Dolphin no longer worked for them. Now, any game they attempted to run would fail to start, with the error "Failed to create BoundingBox Buffer." This occurred after running Super Smash Bros. Brawl. That game doesn't even use Bounding Box! After Kill Renderer, Bounding Box was always initialized whether the hardware supported it or not. This doesn't affect most of our userbase, as >99% of our users' hardware supports the feature, but for any hardware that doesn't support Bounding Box, this regression completely broke Dolphin! AdmiralCurtiss looked into this and made a quick fix. As of this change, Dolphin will perform the same as it did before Kill Renderer on those GPUs - Dolphin runs again and games work, but if a user attempts to run a Bounding Box title, they are in for a buggy good time. Mario refuses to be associated with the Intel HD Graphics 3000. Now that's an air ship. Unlike the GameCube, Intel HD Graphics 3000 cannot handle this many sprites at once. Notice for Nvidia Users¶ We've received reports of texture corruption in D3D11 on Nvidia GPUs with their latest drivers. This is still developing, as we have yet to properly isolate and analyze this, but we believe it to be some sort of driver issue. For now, we recommend Nvidia users avoid our D3D11 backend. Last Month's Contributors...¶ Special thanks to all of the contributors that incremented Dolphin from 5.0-20349 through to 5.0-21088! [Less]

This past October, Dolphin turned 20 years old since its initial release to the public as an experimental GameCube emulator. It's been a long ride, with twists and turns. I don't know if anyone back in 2003 expected Dolphin not only to ... [More] still be under active development 20 years later, but to also support the GameCube's successor in the Wii. You might be wondering, where is all the pageantry? The honest truth is that things aren't ready yet. We have a few massive changes on the horizon that we wanted to be ready for the 20th anniversary, but that date was not an excuse to release something in a broken and incomplete state. For now, development will continue as normal, but we promise that there is some excitement to be had on the horizon. In the meantime, we have some great changes for you this in Dolphin Progress Report! Notable Changes¶ 5.0-19886 - Add Custom Dark Style for Windows by AdmiralCurtiss¶ The waiting game is over. After much discussion and work, AdmiralCurtiss bit the bullet and added a dark mode to Dolphin. Some of you may be wondering right now, Wait, didn't Dolphin already have dark mode? Yes. Also no. Essentially, on macOS, Android, and Linux, Dolphin has supported dark mode for years. On those platforms, if your system is configured to dark mode, Dolphin will switch to darker colors to match without requiring any input from the user. It is completely seamless on macOS and Android, and has been since early 2020, nearly four years ago. Dolphin on Linux has supported dark mode for even longer, however it may or may not work out of the gate depending on the packaged Qt defaults and other Linux quibbles. If you're a Linux user, you know the dance. Dark mode has been effortless in macOS for years now. Android too! However, the above fails to mention a very significant operating system that we support - Windows. As that is nearly half of our userbase, a lot of our users were missing out on nihilistic bliss. There were many reasons why we didn't support dark mode on Windows until now, but the core of the matter is our desktop GUI toolkit - Qt. While Qt 5 supported automatic dark mode switching on macOS and Linux, it did not respond to the Windows dark mode setting at all. But there was a lot of demand for the feature, so Qt promised that a solution was in progress. For us as an application that uses Qt, we could have bodged together some sort of dark mode switching ourselves, but it would have inevitably been jank and weird. So upon hearing that Qt was working on it, we decided to wait for their solution. That eventually came with Qt 6.5, which indeed delivered automatic dark mode switching on Windows as promised... in their new "Fusion" style. The Windows-matching QWindowsVistaStyle Dolphin has used for years was abandoned and will not be getting dark mode at all. Qt gave many reasons for their decision (spoiler: Windows be Windowsing), but fundamentally, they did what they thought was best given the circumstances. With Qt's unexpected move to a new style, we had to make some decisions. Do we adopt the new Fusion style, affecting all of our Windows users both light and dark, or do we use the switching they built into Qt 6.5 and create something ourselves? So people experimented, with nearly a half dozen pull requests of all kinds! We tried Fusion, but the look of the style proved to be unpopular. So we started experimenting with custom styles of our own, with multiple people going different directions and bikeshedding for months. The end result is a hand-crafted dark mode alternate QWindowsVistaStyle created by our very own AdmiralCurtiss. It is what we had hoped Qt's default support for dark mode on Windows would have been - Dolphin on Windows, but dark. The same Windows Dolphin style you know... Can now go dark! Now every platform we support now has dark mode and automatic switching! Of course it will switch automatically, but on Windows you can manually select between our dark and light styles and even custom user styles with the new Style dropdown in Config → Interface. This replaces the old Custom User Style control, combining our official styles and custom user style controls in one place. 5.0-19939 - Implement Output Resampling (Upscaling/Downscaling) by Filoppi and samb¶ For years now, whenever a user has asked us for settings that would give them the best image quality possible from Dolphin, there's been a familiar back and forth. In response to the question, we'd tell them to set Dolphin's Internal Resolution to match their screen (following our recommendations in the GUI), set Anisotropic Filtering to x16, and use 4x or 8x SSAA (Super Sample Anti-Aliasing). On a sufficiently-capable gaming PC, that combination will give pristine visual quality. However, users would counter our recommendation by saying that since SSAA runs at a higher resolution than the screen and uses downsampling for its resolve, why can't they just do the same by raising Dolphin's Internal Resolution higher than their screen? And we'd reply by reminding them that Dolphin didn't have its own output resampling, and the basic downsampling from the GPU meant that their idea would create more aliasing rather than less. Believe it or not, this is using 4xSSAA. The Internal Resolution in this shot is much higher than the screen, and the GPU's basic bilinear downscaling is so sharp it creates new aliasing. This song and dance has happened dozens of times, enough that we would remind users about this whenever new Internal Resolution options were added. However, as of this change, things are different. Dolphin now has its own Output Resampler! With Area, Bicubic, Sharp Bilinear and more, users can now take upscaling and downscaling into their own hands. In fact, as far as we know no other game, emulator, or even GPU driver implements such an advanced and comprehensive resampler! B-Spline, Catmull-Rom, and Mitchell-Netravali, oh my! Has this changed our recommendation for the best possible visual settings? Not really. While you can use output resampling to create a "DIY SSAA" that can meet SSAA's visuals, hardware SSAA is faster at equivalent fidelity (on an Nvidia GPU). SSAA is an easy recommendation. However, performance was never the point. Output Resampling is an extremely powerful new tool that was built to give users control of Dolphin's final look. From an especially soft and temporally stable image, to razor sharp pixels, to the highest fidelity imaginable, our new output resampling features can do it all! There's a lot to cover here, so let's get started. What is Output Resampling?¶ Before we continue, let's briefly go over the basics for any readers who are unfamiliar with these topics. Whenever rendering at a resolution that doesn't match the render window, the pixels of the game's output must be resampled (effectively remapped) into a new image that matches the new pixel grid. For example, a 1x Native (640x528) frame in a 1920x1080 canvas must be scaled up to fill the canvas. As it is not a 1:1 ratio and not even an integer multiplier, we can't just directly translate pixels from our output onto pixels of the screen, it must be resampled during upscaling. With the familiar Bilinear upscaling, it will fill the canvas by interpolating the source pixels into the new pixel grid, for a consistent, though soft, resulting image. If we run a game in 4:3 at 1x native in a window with Auto-Adjust Window Size, we get razor sharp pixels thanks to direct pixel mapping. At least, as close to direct mapping as is possible for the GC/Wii. But this configuration is quite small on a 1080p screen. If we enter fullscreen, the game is much larger. However... Our pixels are now soft. This is because the ~480p pixel grid has been interpolated into the 1080p pixel grid of our display. The GameCube and Wii were built with analog displays in mind, where exactness simply didn't exist. Every game is close to a standard aspect ratio but subtly nonstandard, and frustratingly uniquely subtly nonstandard. Plus, widescreen is achieved by just.. making the pixels wider, not adding more of them, so that means non-square pixels are a factor too! To accurately recreate these games on modern displays, we have no choice but to account and adjust for these behaviors, which we do by resampling the image. As such, any time you play a game in Dolphin, the image you are seeing will have been resampled at least a little in all cases. Resampling is unavoidable in Dolphin. Without an internal output resampler, Dolphin has been entirely reliant on host GPU's provided resampling for this important task. It's... not amazing. The GPU Bilinear Resampler was designed to be fast and simple, and not necessarily to have the best visual resolve. The GPU provided bilinear resampling a 1x native image into 1080p gives a soft result, but not an especially clean or great one. It does the job. Downscaling a 6x native image to 1080p is similarly "meh". Despite using four times the pixels of 3x native (which is close to our 1080p canvas), it's not much better. But it did downsample it for us. Despite all this, resampling hasn't been a huge issue for us. After all, Dolphin's GPU load is pretty low* and we are always* CPU limited, so with GPU power to spare*, users should just run at the Internal Resolution that we recommend for their screen and call it a day. With modern devices, even a phone can do that*. And they probably even have enough spare GPU power to add antialiasing for an even better result! Despite all those asterisks, that is still usually the case, if all you care about are high resolutions and crisp antialiased lines. However, not everyone wants that. And even in 2023, there are still cases where not everyone can achieve that. This is where Output Resampling comes to its own. What are the resample options?¶ Our Output Resampler is extremely comprehensive with many different possible settings and use cases. Here are some of the options and some ways that you can use them. Area is a resampler that samples every pixel on the screen for the maximum possible sample count. It is built for downsampling, with a soft resolve to combat aliasing, shimmer, and moire issues inherent to downscaling. It can be used for upsampling though, to curious results. By sampling all the pixels, the Area downsampler is extremely sharp when upsampling. When downsampling, Area's soft resolve helps smooth edges of textures and polygons alike. Upsampling isn't really what Area is intended for, but is does give an interesting result - an extremely sharp look, akin to Sharp Bilinear. However, we recommend Sharp Bilinear over using Area this way, as Sharp Bilinear is explicitly designed for upscaling pixel art titles and has lower GPU usage than Area. Experiment with it yourself and compare! Downsampling is where Area shines. The frick ton of samples and softened resolve allows Area to avoid the downsample aliasing that Bilinear and other resamplers experience. In fact, by combining the area resampler with MSAA and an Internal Resolution much higher than your screen, you can create a DIY SSAA. Add in some MSAA and the Area downsampler can match SSAA's exceptional picture quality. However, SSAA is a graphics driver feature that is optimized with your GPU to make it surprisingly efficient, for a brute force technique anyway. A DIY SSAA cannot be faster than a hardware optimized solution! But by being within the users' control, Area provides a lot of interesting downsampling options that we have not had before. Furthermore, SSAA is not so optimal everywhere and may not even be available for everyone. More on that later. Bicubic uses cubic spline interpolation for its resolve. It comes in three flavors: B-Spline (soft), Catmull-Rom (sharp), and Mitchell-Netravali (medium). B-Spline is an exceptionally soft upsampler. With extreme temporal stability and minimal noise, B-Spline can give an extremely clean and stable result. If you ever wanted Dolphin to use a modern display's pixels for a soft image rather than just more and sharper pixels, the softness of B-Spline is for you! B-Spline's downsampling is kind of inbetween Area and Bilinear. Add SSAA to 1x Native B-Spline for a silky smooth resolve! All of the detail is still there, but the source pixels have melted into light and shapes. Be sure to click/tap this image, it's something else. On the opposite end of the spectrum is Catmull-Rom, an extremely sharp upsampler. Now THIS is a different look for Dolphin! Click/Tap the image for detail! Downsampling, Catmull-Rom's sharpening is still present and gives some highlights around pixels, but it is significantly weakened. Mitchell-Netravali is inbetween these two extremes. For upsampling, Mitchell-Netravali kind of looks like B-Spline and Catmull-Rom combined. It is both softer and sharper than Bilinear. When downsampling, Mitchell-Netravali more or less just looks like Bilinear, but with a tiny bit of sharpening added on. It's fine. Sharp Bilinear was previously added to Dolphin as a post processing filter, and now has joined the suite of output resamplers. As we have already covered Sharp Bilinear quite recently, we won't be going into detail here. But in summary, Sharp Bilinear is a best-of-both-worlds combination of Bilinear and Nearest Neighbor, allowing nearest neighbor pixel clarity without its shimmering artifacts. It is primarily designed for upsampling low resolution sprites, but it can be used to upsample 3D graphics if you want unnaturally sharp jaggies. It is not intended for downsampling. Sharp Bilinear is extremely sharp and ready to upscale pixel art! It's not made for downsampling, but downsampling Sharp Bilinear... looks like Bilinear. Also it is extremely close to the Mitchell-Netravali image above! Click the image above to be taken to our previous coverage on Sharp Bilinear. It has animations and everything! When is Output Resampling Better than Existing Solutions?¶ Output Resampling is primarily focused on providing visual options for players, and it typically isn't outright superior to existing solutions. However, it is very powerful, and during testing, we found several scenarios where Output Resampling is able to create a better result than what was possible before. EFB Copy Brute Forcing¶ Some games use a large EFB effect that is particularly expensive, and have to render it at a fraction of the game's output resolution. A classic example is the mirrored surface of Fountain of Dreams in Super Smash Bros. Melee. The mirrored surface is rendered at 1/8th the resolution of the rest of the image! We don't have to worry about the hardware limitations that lead to these decisions, but the consequences of their choices affect us even today: as these effects are rendered proportional to the game's rendering resolution, they scale proportionally too. No matter what Internal Resolution multiplier we use, the mirrored pool in Fountain of Dreams will always be 1/8th of that. As such, the only way to increase the resolution of these effects relative to the screen (without modding the game) is to increase the Internal Resolution way beyond the screen resolution. But as we have already talked about thoroughly in this section, this will introduce aliasing with the GPU bilinear resampler. Users simply had to deal with this - it was either aliasing or a low resolution reflection. Until now! Using our Output Resampler (specifically Area), we can raise the Internal Resolution as much as we want without adding aliasing! Fountain of Dreams can now be seen in perfect clarity! Smash 64 is that you? Upsampling to a Close Resolution¶ As mentioned previously, resampling is basically unavoidable in Dolphin due to quirks of the GameCube and Wii. However, if you use the Internal Resolution recommendations we have our in GUI (such as 3x Native for a 1080p screen), the GPU Bilinear Resampler will be good enough that switching to our Area resampler will give only marginal improvements even for pixel peepers. But not everyone has a system powerful enough to run at our recommendations for their screens, and they may have to settle with the highest Internal Resolution their hardware can manage. Depending on their circumstance, our Output Resampler could help them achieve a better image than was possible before. A good example of this is resampling a 2x Native (1280x1056) 16:9 title into a 1920x1080 canvas. 2x Native nearly matches a 1080p screen vertically (1056 → 1080), but it has significantly fewer pixels horizontally (1280 → 1920). The GPU Bilinear Resampling clearly exposes the resolution difference, with much softer pixels horizontally. Our Area resampler gives a sharper and more consistent result under the same circumstances. This is most clear on Pit's rings in the left half of this image. This benefit of our Output Resampler is highly situational, but it can improve Dolphin's image quality on lower end systems. Experiment and see what works best for you! Downsampling on Platforms where SSAA is Unviable¶ SSAA has pristine visual quality and surprisingly good performance for a brute force solution. However, that doesn't matter if your system doesn't support SSAA! In desktop land we have been spoiled by SSAA being near universal, but Dolphin's mobile users are now over half of our userbase, and SSAA is uncommon on mobile SoCs. Furthermore, SSAA may be present but not optimal. Adreno in particular hates SSAA! A DIY SSAA made with Output Resampling may be just what a user needs on those platforms. Unfortunately, our Output Resampler is not yet available on Dolphin Android. We tried our best to hunt down some non-Android devices that lack SSAA or have poor SSAA performance, but the best we had on hand was a 2019 Surface Pro X. While its Adreno GPU absolutely hated SSAA as predicted, it was too weak to serve as a good demonstration. Once this feature arrives on Android, we have loads of powerful Android tablets to try this on. Stay tuned! 5.0-20193 - Expose Resolutions Multipliers Up to 12x (~8k) by Filoppi¶ Now that we have proper downsampling, we've decided to increase the maximum Internal Resolution exposed by default in our desktop Qt GUI from 8x Native to 12x Native (8K). This will allow users of 4k displays to increase the Internal Resolution beyond their screen for downsampling purposes without editing INIs. For the twelve of you with an 8k panel, now you don't need to set MaxResolution at all! Unless you want to, 8k users tend to have silly hardware so do whatever you want. That's a lot of pixels. However, just because Dolphin shows 12x Native in the GUI does not mean that your computer can achieve it. 12x Native is 48,660,480 pixels, or 48.7 megapixels. Currently most computers will run out of VRAM before reaching 12x Native! Statistically speaking your computer will not run this resolution at fullspeed. Use this power responsibly! This change only applies to our desktop Qt GUI, and does not affect Dolphin on Android. We do not need to explain this. 5.0-20199 - Use LZ4 for SaveState Compression/Decompression by Malleo¶ If you're in the TAS community or relying on constant savestate usage for your project, this is a huge optimization that might make your life a lot easier. Malleo noticed that Dolphin was using LZO for savestates, which has a good compression ratio, but is quite a bit slower than LZ4 when it comes to decompression. By moving Dolphin's savestate compression to LZ4, savestate loading is now ~72% faster. For the casual users, savestate loads are now snappier. For speedrunners this will make practicing a single trick over and over again take a little less time. But for people using hundreds, thousands, or tens of thousands of savestate loads for TAS creation or AI projects, the savings really start to add up. This is the kind of work that will be much faster now! 5.0-19415 and 5.0-20126 - Improve JIT Block Lookup Performance by krnlyng¶ To run game code that's been designed for the GameCube and Wii's PowerPC CPU, Dolphin's JIT translates PowerPC machine code into machine code that your computer can run natively. Once a chunk of code has been translated, the resulting code block is stored in Dolphin's JIT Cache so that the code doesn't have to be translated all over again if it needs to run again later. Usually when we optimize the JIT, the improvement is in how the code gets translated. But this time, krnlyng has improved how quickly Dolphin can start executing the next block after a block is done running. Or to be more specific, how quickly Dolphin can do it in the case where it doesn't know in advance which block comes next. To find out what block to run, Dolphin has a large table that maps emulated code addresses to the corresponding block of translated code. Before krnlyng's changes, this table was 256 KiB, and doing lookups in the table worked as follows: Dolphin grabs the lowest 16 bits of the current emulated code address. This results in a number from 0 to 65,535. The number calculated in the previous step is used as an index in the table. Dolphin reads the table at that index and gets a pointer to JIT block metadata. Dolphin checks that the pointer isn't 0, and then reads the JIT block metadata. If the pointer is 0, the code hasn't been translated yet, so Dolphin has to go and translate it before it can continue. Dolphin checks that the emulated code address stored in the JIT block metadata matches the current emulated code address. Sometimes, the address might not match because two different emulated addresses have been mapped to the same index in the table. In that case, Dolphin has to use a much slower piece of code to find the right block. Dolphin checks that the IR and DR bits of the MSR register match. We'll skip the details, but this is very similar to the previous step. Dolphin gets the pointer to the translated code from the JIT block metadata, and jumps to it. After the changes, Dolphin has a new table that's 32 GiB in size, and doing lookups in it works as follows: Dolphin takes the entirety of the current emulated code address and prepends the MSR bits that were mentioned earlier. This results in a number from 0 to 17,179,869,183. Dolphin reads the table at the index calculated in the previous step and gets a pointer directly to the translated code. Dolphin checks that the pointer isn't 0. Like before, a 0 means that Dolphin has to stop what it's doing and go translate the code. Dolphin jumps to the pointer. This not only gets rid of the problem of different emulated addresses sharing the same index in the table, but also lets us skip reading the JIT block metadata entirely! But you may have an important question: How the heck is Dolphin going to fit a 32 GiB table into RAM when many computers and all phones have less total RAM than that? In reality, Dolphin isn't asking the operating system for 32 GiB of real memory. Instead, it sets up 32 GiB of address space and asks the operating system to only allocate memory as needed. The first time Dolphin tries to access any given section of the 32 GiB table that isn't backed by real memory, the operating system allocates a small chunk of memory on the fly and fills it with zeroes. In the end, this new table can use a few more megabytes of memory than the old table, but nowhere even near 32 GiB. In an ideal world, that would be all we have to say about the new solution. But for Windows users, there's a special quirk. On most operating systems, we can use a special flag to signal that we don't really care if the system has 32 GiB of real memory. Unfortunately, Windows has no convenient way to do this. Dolphin still works fine on Windows computers that have less than 32 GiB of RAM, but if Windows is set to automatically manage the size of the page file, which is the case by default, starting any game in Dolphin will cause the page file to balloon in size. Dolphin isn't actually writing to all this newly allocated space in the page file, so there are no concerns about performance or disk lifetime. Also, Windows won't try to grow the page file beyond the amount of available disk space, and the page file shrinks back to its previous size when you close Dolphin, so for the most part there are no real consequences... unless you like to download large files while running Dolphin. We will look into improving the situation on Windows, but for the time being, please don't be alarmed if you see a sudden decrease in available disk space when running Dolphin. 5.0-20201 - Increase FarCode/NearCode Cache Sizes by dreamsyntax¶ When playing certain games for an extended time, Dolphin's JIT Cache has an annoying tendency to run out of space. The most prominent example is of games like Metroid Prime 2: Echoes where the game can dynamically load code into different places in memory. An even more difficult case is N64 Virtual Console games, like The Legend of Zelda: Ocarina of Time which use a recompiler to generate code on the fly. Once either the FarCode or NearCode cache is full, they must both be flushed, wiping both old and current data in the cache. This forces the JIT to rebuild all the code the game currently is running on the fly, leading to a noticeable stutter that cannot be avoided. A huge step that mostly remedied this situation was merged back in 2021 which allowed Dolphin to evict code from the JIT Cache that the game itself invalidated. However, It wasn't a perfect solution. Dolphin was reliant on the game invalidating code, but sometimes games just don't, especially if they happen to be a trashfire like True Crime: New York City. Also it couldn't actually defragment evicted code, meaning that the longer the game was running, the more fragmented the caches would become. If there was no longer enough space to fit a chunk of code, a full flush would be required. Back in 2021, we mentioned that the ability to just use a bigger JIT Cache was still on the table, but we were worried about its ramifications and hoped it would not be necessary. Fast forward to today, and dreamsyntax made a proposal to expand the JIT Cache. As part of it, they showcased a game that blew away all of our tricks: Shadow the Hedgehog. It generates just enough code that it created a consistent, rhythmic, annoying stutter due to the JIT Caches filling up and flushing every 15 - 30 minutes. The pauses. Are very. Consistent. dreamsyntax showed that enlarging the JIT Cache completely eliminated the JIT Cache flushes in Shadow the Hedgehog, and showed many other games that benefitted from it as well. They made a compelling case, so with a little hesitation, we pulled the trigger. As of this change, the JIT Cache has been enlarged! However, all of the things we were worried about with a larger JIT Cache, such as longer more severe stutters, just didn't happen. The JIT Cache flush stutters that we have observed take the same amount of time, yet they happen MUCH less frequently if ever. In fact, the potential to have a cache flush stutter is now pushed so far into a play session that it is outside the usual play session for most users! Players may never see a JIT Cache flush stutter again as of this change! It makes us feel a little silly that we were so hesitant to enlarge the cache. So far it appears that this is the JIT Cache flush stutter solution we have all been waiting for. Hopefully that holds true, as any further improvements to the JIT Cache from here will be much harder. Note: This change only applies to our x86-64 JIT, and does not affect our AArch64 JIT for ARM systems. Due to architectural differences, raising the AArch64 JIT Cache size beyond 128 MiB would require special solutions. 5.0-20148 - Periodically Re-enable Steam Deck Gyro by ArcaneNibble¶ In the latest version of SteamOS, the gyro is disabled whenever SteamOS thinks the gyro is not being used. This includes situations like opening the Steam Deck's menus, which users might do quite frequently! For Dolphin, this would make the gyro suddenly stop working for unknown reasons, with no clear way to reenable it. We're not sure why this behavior changed, but we have no choice but to find some way to deal with it. ArcaneNibble came up with a clever workaround. Rather than try to detect when the gyro is enabled/disabled, Dolphin will try to re-enable the gyro roughly every second or so. If it's already enabled? No harm, no foul. If it's disabled, it'll usually get re-enabled quickly, hopefully before the player even noticed it was disabled. This will make playing some of your favorite Wii games on the latest version of SteamOS a lot more enjoyable, without you having to worry about the motion controls suddenly breaking for previously unknown reasons. 5.0-20097 and 5.0-20109 - Allow Widescreen Heuristic to be Modified Per-Game by OatmealDome and Billiard¶ As an emulator for consoles in the 4:3 to 16:9 transition, players can expect to encounter many different aspect ratios as they play their library in Dolphin. So users don't have to change our aspect ratio setting with each game, we have a widescreen heuristic which detects how wide of an image the game is rendering and sets Dolphin accordingly. The widescreen heuristic works magically! ....usually. Unfortunately, being a heuristic, Dolphin is effectively making an informed guess as to what aspect ratio the game wants. And sometimes, a game is able to fool our heuristic and create wildly inconsistent results! Oh no. Metroid Prime 2, Pokémon Colosseum and a few other games render certain effects with a viewport size that tricks our heuristic! Unfortunately, we couldn't fix this by just changing what threshold the heuristic uses, as this would create false negatives - situations where the heuristic should have changed the aspect ratio but didn't. Regressions would be inevitable. Fortunately, there is a very simple solution available to us - our GameINIs. As of this change, the parameters used by our widescreen heuristic can be be overridden by our GameINIs. If we know a game is problematic for our heuristic, we can tweak how the heuristic behaves for that game without affecting any other games! With that said, none of our GameINIs have had any parameters added yet. For the time being, you'll still run into problems in games like Pokémon Colosseum, but now that we have a workable system we can move forward with figuring out what parameters are needed for each problematic game. 5.0-20041 - Add Support for Touchscreen Latching (Toggle) Buttons by ThunderousEcho¶ Sometimes playing certain games in Dolphin on a touchscreen feels like an impossible challenge that would require another couple of hands and maybe a few extra fingers. For our touchscreen gamers, ThunderousEcho comes in with the ability to change various buttons on the touchscreen to be toggled instead of having to hold them down. This is known as a latching button, and is effectively the same as a toggle button in Dolphin's input system for physical controllers. Simply tap the button once to have it "held" and then tap it a second time to release it. This is a simple addition, but it opens up the touchscreen controls a lot to be able to play more games on a touchscreen device. If you don't have a controller for your phone/tablet, or just prefer the single device form factor, latching might be the feature you need to play your favorite game. You can find the feature in the side menu, under Overlay Controls > Latching Controls. 5.0-20001 - Another PanicAlert Deadlock Fix by JosJuice¶ If you're a veteran of the Dolphin Progress Reports, you're well aware of the eternal battle with PanicAlerts and the seemingly random deadlocks they can cause in combination with certain settings. Thankfully, another one bites the dust as JosJuice fixes a hang that could happen when pressing the "Ignore for this session" button in a PanicAlert. Is this the end of the PanicAlert deadlocks? Has our lovable villain finally been felled in such an anti-climatic manner? Find out next time on Progress Report Z. Last Month's Contributors...¶ Special thanks to all of the contributors that incremented Dolphin from 5.0-19872 through to 5.0-20347! [Less]