On July 13th, 2008, Dolphin went open source, now just over ten years ago. While it could be easy to drift off into how much things have changed... there's one particular feature that has never quite lived up to the hype despite debuting that very same year - netplay.
As surprising as it may sound Dolphin Netplay has been around since the emulator went open source. For roughly a decade, users have tried their hand at taming the beast of synchronizing multiple instances of a GameCube and Wii despite their relative complexities. Netplay allows users to run the same instance of game on multiple computers by having two or more emulators in the exact same state, only transferring inputs between one another. By staying in lockstep like this, theoretically the emulators' states will never diverge assuming perfect determinism. This would allow people across the world to play a game together, even if it only featured local multiplayer on the console.
The problem has always been attaining that determinism. Back in the early days of netplay, it didn't especially matter what settings were used; Dolphin wasn't deterministic enough to stay in lockstep for very long. Then in the early days of the 3.0 era, it was finally possible to stay synced - if you were willing to sacrifice audio and performance. Early netplayers would hack up Dolphin to reduce requirements with 30 FPS hacks to Super Smash Bros. Melee, hacks to LLE audio to make it slow down less during attacks, and much more.
Despite the stutters and desyncs, some serious Melee players saw the potential and kept with the project. It wasn't until New-AX-HLE Audio (part 2) hit Dolphin that audio was both performant and deterministic enough to use in netplay. By the time Dolphin 4.0 rolled around, netplay had become a staple for Melee users and could be used by advanced users willing to suffer through some annoying quirks.
In the last few years, a focus has gone toward adding highly requested features to make netplay easier to use. Dolphin's STUN service allows some users who cannot port-forward play on netplay without issues, saves can be disabled to make synchronizing party games easier. But the one constant is that despite all these advances, simply getting netplay to work was a chore and crashes were common even if you did everything right.
Getting netplay into a more user-friendly state has been quite the process. In July, we saw some of the most drastic changes to netplay that we've seen in the past couple of years! Emulated Wii Remotes also saw huge usability improvements and some non-NVIDIA Android devices will finally be able to use Dolphin's Vulkan backend. If that wasn't enough, spycrab0 delivered some very big improvements to the DolphinQt GUI to give a new way to display your favorite games in the gamelist. Let's not delay any longer, please enjoy this month's Dolphin Progress Report.
5.0-8498 - Add Ability to Download/Display Covers for Grid Layout by spycrab0¶
A lot of people have been wanting a coverflow GUI in Dolphin for a long time. While the banners may look okay in some instances, covers have added detail, nostalgic value, and can look great when flowing through Dolphin's gamelist. When DolphinQt was given Grid Layout long ago, the dream was to eventually pair that up with a cover database to produce a more visually pleasing gamelist. Thanks to some additions by spycrab0 and GameTDB's massive cover database, Dolphin can now display full covers in grid mode.
To enable this feature, a new option in the interface menu has been added - Download Game Covers from GameTDB.com for Use in Grid Mode and must be enabled for Dolphin to start downloading covers. Do note that this will cause Dolphin to access the internet and, depending on the size of your gamelist, download hundreds of covers. There are a few differences between this and banners. Because Dolphin is downloading this from a separate service, we cache these separate from the gamelist cache in a GameCovers folder. This makes it less likely you'll have to download a cover multiple times, even if the gamelist cache is incremented to a new version. The other key difference is a big one - Wii games do not need a save for their cover to show up in the gamelist, unlike their banner. Depending on your gamelist, it may be easier to fill it in with covers than it is with banners!
While Grid Layout has existed for quite a while, without the ability to use covers it didn't see much use. For those of you to make use of this feature for the first time, remember that Control and + will zoom in, making the covers bigger, while Control and - will zoom out, allowing Dolphin to display more covers at once. If you have a lot of games, zooming out can give you a broader view.
There are some limitations to this - GameTDB doesn't have every cover to every game and Dolphin doesn't try for more common regions yet on off-region games. As well, because Dolphin uses GameID to to determine which cover to grab, this means some homebrew and unlicensed titles may get the wrong cover or not cover at all. Some custom covers are on GameTDB and will show up in Dolphin with patched ISOs, such as some Mario Kart Wii Track Packs and various Super Smash Bros. Brawl mods!
For now this is only available in the DolphinQt GUI and is not present within either Android GUI. That being said, there are plans to port the feature into the Android T.V. GUI where it would give everything a much nicer look.
What if your favorite game doesn't have a cover?¶
While GameTDB has a massive amount of covers, it doesn't have every cover for every region and there are some additional cases where looking up covers by GameID just doesn't work. In these cases, you can force a cover to a particular item in the gamelist by putting a file in the same directory with this structure. This can be done by adding a file in the directory that is [gamename].cover.png. Let's say you want to do it with the Advance Game Port (named agp.iso for our purposes) a custom cover because it uses a GameINI stolen from NHL HITZ 20-02. While GameTDB doesn't have a cover directly for it, Dolphin's Game Wiki does! We can download that, put it in the same folder as agp.iso and name it agp.cover.png to get a custom cover!
In the situation above, two of custom covers for the unofficial discs came from Dolphin's Game Wiki and the last was made from photograph of the game case. Being able to do this is incredibly useful in the situations where GameTDB is missing covers or Dolphin can't search for the cover thanks to the game having a bogus or no GameID. While this may seem like a lot to digest, there are mostly just edge-cases. The vast majority of users should be able to have a fully covered gamelist by just enabling the option. With that, we hope you enjoy using this new feature.
The Netplay Revolution¶
5.0-8322, 5.0-8395, and 5.0-8504 - Improve Netplay Shutdown Behavior by spycrab0 and Techjar¶
Anyone who's used Dolphin's netplay in the past couple of years knows a few key truths about the netplay experience. Once you know what you're doing, starting and playing a game on netplay aren't huge problems. Dolphin is relatively stable and people have proven that Dolphin can stay in sync for multiple days in a single session. While extending the session could delay the inevitable, when you were ready to stop, there was no avoiding your final fate.
Dramatization of spycrab arriving on the scene.
After being repeatedly harrassed, spycrab0 finally caved in and decided to look into the netplay stability issues. After felling the fearsome beast that was DolphinWx and porting over the netplay GUI, he couldn't imagine it being something he couldn't handle. Little did he know the horrors that awaited.
After recovering from the initial shock of seeing netplay's condition, spycrab0 realized there was a tiny flaw in the netplay infrastructure that could be the cause of some very minor issues. Namely, Dolphin instances connected to one another in netplay had no intention of letting the others know when they had stopped the game. So if a player closed their game after they were done playing, their instance would then say literally nothing to the other instances. So now these sessions are frozen waiting for inputs from the game that is stopped. Then, when that first instance leaves netplay altogether, the pad mappings attempt to change and all the other instances would deadlock! But even the instance that successfully left the session was a bit messed up. That instance would have to close Dolphin before it could ever start another netplay session because Dolphin never communicated to itself that the netplay session was over. This is what happens when you do not maintain your features.
In order to make things slightly more stable, spycrab0 has retrofitted Dolphin's netplay infrastructure with the revolutionary ability to tell itself and other instances of Dolphin within the same netplay session when the game has actually ended. Thanks to this change, it's entirely reasonable to play on netplay without everyone crashing at the end because Dolphin was in some messed up state of not knowing if a game was running of not.
spycrab0's efforts made it so anyone playing with GameCube controllers should be fine, but, while testing this feature, Techjar and JMC47 ran into another issue that was just as puzzling. Spectators have no controllers assigned to them and Dolphin tries to make sure a spectator has no impact on the players playing the game. If a spectator has slowdown, it can fall behind the other players. If a spectator disconnects, the netplay session is supposed to continue on. And sometimes it did... and other times, Dolphin crashed. Over the course of three days (and testing other features in this report,) the two of them messed around with just about every idea you could imagine.
Finally, spycrab0 added some extra netplay debug logging into the mix with 5.0-8391 and they noticed packets indicating GameCube Pad/Wii Remote mappings being updated. This happening during a netplay session was a huge red flag and after some investigation, Techjar realized the input mapping code was misplaced outside of a loop and being triggered erroneously by spectators leaving the match despite not having any controllers! With two lines of code moved, this mysterious random crash was quelled.
Addtional crashes relating to ending a session while MD5 calculation was active and other race conditions were quelled in 5.0-8504. These crashes were caused by the netplay client object being destroyed while other threads were still using it. Because it was somewhat rare that this happened (and netplay shutdown behavior didn't work prior to this month...) it took quite a while to track down and cleanly fix the issue.
Note: Emulated Wii Remotes are still a disaster on netplay. The above applies to GameCube Netplay and Wii games that can use GameCube Controllers.
5.0-8324, 5.0-8381, and 5.0-8412- Reduce Netplay Bandwidth Usage - by Techjar¶
Because Dolphin's netplay is more or less sending inputs to synchronize clients, you may think that bandwidth usage isn't an issue whatsoever. While those of you on top-end internet connections probably don't notice, Dolphin could actually use quite a bit of bandwidth. A popular netplay game like Mario Party 5 could require up to 300 Kbps upload in addition to other overhead. Super Smash Bros. Melee can have even higher requirements thanks to popular cheat codes to increase its polling rate beyond what it was on console.
Techjar's connection wasn't strong enough to use netplay because of the high upload requirements. Oddly enough, this wasn't always the case, Dolphin used to purposefully limit how many times a game would poll the controller during a Movie/Netplay in order to simplify things. This was removed as part of a feature to fix Sonic Heroes
Thanks to various fixes since the old polling rate hacks were removed, Sonic Heroes works fine even the new Reduce Polling Rate enabled. Other games with polling rate issues, such as Mario Kart: Double Dash!! also work correctly with the revived reduce polling rate option. With this option enabled, Mario Party 5 drops from over 200 Kbps to only 100 Kbps. Do note that the Reduce Polling feature is optional. If you have good enough internet to play your favorite games with full polling, you can completely ignore it. That doesn't mean you don't get some benefits regardless, though. Techjar also reduced Dolphin Netplay's bandwidth requirements by reducing timebase checks to once per second and bundling controller packets when multiple controllers are used by a single instance of Dolphin. Together, these changes make a huge impact, especially for those of us who may not have the best internet options.
5.0-8347, 5.0-8357, 5.0-8362, 5.0-8421, and 5.0-8423 Fix and Improve Netplay Interface Issues by Techjar and spycrab0¶
While the Qt version of Dolphin's Netplay GUI certainly looked a lot nicer and was much more customizable than its Wx sibling, there were more than a few things that had minor issues.
Some were more minor than others, with one particularly annoying (though insignificant) problem being that Dolphin wasn't correctly restoring the saved IP address/Traversal ID when switching between the traversal server and direct connect connection modes. Dolphin now correctly restores the values for whichever mode you're using rather than carrying over the previous value. Another oversight was the fact that Dolphin was using panic handlers to communicate key connection error information to users if they were not able to connect. The only problem with this is that users can disable panichandlers and would then just be left with nothing but a generic error message.
We also realized that in the port of the netplay over from Qt, the flash on notification feature was left behind. spycrab0 joined the party to restore this missing feature so that you no longer have to watch the netplay window directly to make sure your friends aren't waiting on you.
But by far the funniest of the GUI issues has to go with whatever happened to the MD5 Hash Verification feature. While it worked in Wx, the port over to Qt left it in absolute shambles. It was absolutely sure the hashes matched no matter what. It was so sure, it wouldn't even wait until everyone was finished checking their hash. And if they were different? It stuck to its guns.
With these issues quelled, every feature within the netplay interface should finally be fully functional.
5.0-8478 - Automatically Sync Save Data on Netplay by Techjar¶
One of the more annoying steps when setting up a netplay session was figuring out what to do with saves. Whether it was syncing a whole folder of GameCube saves, transferring a memory card blob, or exporting a Wii save, users had to be extremely careful to make sure every player had the same saves available. If one player mistakingly booted the games between sessions, then syncing would have to be done yet again. In a beloved game like Tales of Symphonia where a playthrough may take place over the course of weeks or even months, this can lead to a lot of wasted time, frustrating desyncs, and unhappy players.
Techjar officially puts an end to this struggle by synchronizing save data from within Dolphin. All users have to do is wait a few moments while the savedata is passed between players!
How does this all work? The base save that everyone uses is controlled by the host. It is their save that is used and transferred between all of the players. This does not overwrite the save on the client's end, though! Instead, Dolphin will keep it safe and sound in a temporary folder for the session. The host's save will automatically be transferred out of that temporary folder at the end of the session and overwrite the original save. If for some reason Dolphin crashes during a netplay session and it does not export, don't panic! The saves will be kept in that temporary folder until the next time you use netplay.
When using GCI Folders or Wii games, only saves matching the GameID of game launched in netplay will be loaded. If you're using a homebrew launcher to startup Brawl, the GameID may not match that of the savefile that Brawl is looking for, meaning the save synchronization will fail. There are also a small number of Wii games that block save exporting, which breaks Dolphin's ability to automatically synchronize them. Those titles will still need their saves manually synchronized until an automated solution is found.
5.0-8502 - Synchronize Important Settings on Netplay by Techjar¶
Getting instances of Dolphin to synchronize can be difficult. While previous changes mentioned fixed some major issues with netplay, there's still one key thing that hasn't been mentioned. Sometimes you'll do everything right, synchronize save data, have the correct version of a game, setup the buffer and controllers correctly and yet... Dolphin still won't synchronize. You try flipping every setting in hopes that maybe something will fix it but in the end, you can't fix it. So, you download a new version of Dolphin, make it portable, setup netplay and boom, it works. This is because there are a lot of hidden settings that can absolutely affect netplay.
Techjar learned this very quickly when playing on netplay with JMC47, whom had tons of insane settings that no reasonable user would have turned on. FPRF permanently enabled? AccurateNaNs always on?! While those settings may be fine when hunting for bugs, they cause headaches for anyone trying to play with him on netplay.
In order to rectify this issue, Techjar and JMC47 came up with a list of settings to synchronize on netplay that would allow even the most customized configurations to still synchronize on netplay.
Strict Settings Sync¶
In addiction to synchronizing more settings, Techjar also added a new option to the mix called Strict Settings Sync.
In some cases games tend to require extra synchronization due to certain behaviors. In the case of Mario Party 8 some minigames use Store EFB Copies to Texture and RAM. Using different internal resolutions can cause desyncs after a while if a game reads from the screen. Strict Settings Sync synchronizes various graphical enhancements and settings in addition to everything else synchronized by default.
Use this feature with caution - you may be able to run a game at 8x Internal Resolution, but your buddy on a laptop using onboard graphics may not! In a case like Super Mario Sunshine, you may additionally need the same graphics backend to stay synchronized. Because not all operating systems have every graphics backend, Dolphin will not attempt to synchronize that. There's really not much that can be done in those very rare cases. Even though these new setting syncing features are incredibly helpful, still try to be aware of your settings to avoid the remaining potential pitfalls.
5.0-8383 - Fix SRAM on Netplay Issue by Techjar¶
Sometimes an issue is actually really simple and silly - the problem is actually tracking it down. Once he knew what was wrong, Techjar was able to fix it in moments by removing a single flawed condition. Stumbling upon the issue took a tremendous amount of luck and patience. If not for the huge netplay features hitting all at once necessitating a ton of testing, it's very likely this bug would still exist in the emulator.
JMC47 and Techjar were testing Mario Kart: Double Dash!! quite a bit with the new input polling and save synchronization features. These features allowed for smoother gameplay on Techjar and less setup. With the saves synced, they could just join and play without issues and sync up. But, in longer sessions, they'd find that their games would quickly start desyncing usually within the first 30 seconds. Considering that they were both using relatively fresh Dolphin folders and carefully took care of their settings, this was bewildering. Worse yet, the problem would come and go at seemingly random. Neither of them could reproduce the issue with local netplay instances, it only occured when both of them were playing together.
They tried more carefully synchronizing their builds, wiping settings, adding the real GameCube fonts, DSP-LLE files, and even trying other games! Seemingly randomly, they would desync. One day turned to two and two turned to three before they made any real headway. While simply throwing stuff at the wall they booted into The GameCube Main Menu during a netplay session. When checking memcards and flicking around the various options, a setting caught JMC47's eye. He typed over the netplay chat, "Did you see that?" and got nothing but bepuzzlement in response. They flicked back to the audio tab and JMC47 said that his said MONO for audio. Techjar's instead said STEREO.
Techjar: "So, why exactly is your SRAM set to MONO?"
JMC47: "I dunno."
The odd thing is that this desync wouldn't always happen. Now that they knew what they were looking for, the two of them narrowed down the behavior. On first boot of a new netplay session, the SRAM was properly synced. If you stayed in the netplay session and booted another game, the original SRAM on each player would be used. Because Spycrab0 literally just fixed the ability to survive a netplay game without crashing, this bug went unnoticed for years. But even then, without all of the new additions, it'd be unlikely for two players to even notice this behavior at all. It turns out on game stop in netplay, it was clearing the synced SRAM, causing each client to fallback to their own.
...but there's one more mystery in all of this. Why was JMC47's SRAM set to MONO? Without this key detail, their SRAM settings would have been identical and this bug may not have been found. Even JMC47 was puzzled as these builds were mostly fresh and only used for netplay testing. It wasn't until days later that he remembered what was wrong. When having difficulties creating a new memory card for use in netplay (before save syncing existed,) he was having problems getting the game to save. Before the creating new memory cards was fixed, he gave up on this proposition. ...But one of the settings he changed when trying to trick the game into saving was STEREO to MONO in the main menu of the game he was setting up! Because the SRAM is separate from memory cards, that particular setting did get saved unbeknownst to JMC47.
Sometimes it takes the stars to align to fix a simple bug in logic.
5.0-8377 - Disable Branch Following for N64 VC games by spycrab0¶
Branch Following is an optimization added in 5.0-2178 and greatly improved performance in popular games such as Fire Emblem: Radiant Dawn and Xenoblade Chronicles. This feature of Dolphin's JIT allows it to optimize larger blocks of code at once. Larger blocks means that our optimizer has more knowledge about what the code does, which allows us to shortcut many things that we would have to do with small blocks.
These massive performance improvements aren't exactly typical, but overall Branch Following is a performance increase of some amount in most games. For Nintendo 64 Virtual Console games, this actually holds true - their maximum performance is increased with Branch Following enabled but it comes at a cost. While if you tested a single spot in Mario Party 2 with it enabled, you'd see an increase in performance, problems show up as soon as you start to do just about anything. Any action, from navigating a menu, selecting a character, hitting the dice block, or simply loading a mini-game, Dolphin would stutter harder than Metroid Prime 3 before ubershaders!
While this can't be visualized well with raw performance, if you look at the framerate when navigating the menus with Branch Following enabled and disabled, you can see a stark contrast between the two experiences.
So why exactly is Branch Following causing all of these gigantic stutters? In order to truly understand this, we have to look at the emulator. Not just Dolphin, mind you, but Nintendo's N64 emulator powering Mario Party 2 on the Wii. JITing a JIT isn't exactly the most elegant of situations for Dolphin, the JIT within these emulators were creating incredibly big blocks of code. Branch Following now allowed Dolphin's JIT to try and inline the branches within them which resulted in Dolphin compiling gigantic blocks. This isn't bad on its own, but after a look at the logs the problem becomes very apparent.
45:29:685 Core/PowerPC/Jit64/Jit.cpp:749 E[PowerPC]: Compiling JIT block 0x8006b690, 350 instructions
45:29:692 Core/PowerPC/Jit64/Jit.cpp:749 E[PowerPC]: Compiling JIT block 0x8006b6c0, 338 instructions
45:29:692 Core/PowerPC/Jit64/Jit.cpp:749 E[PowerPC]: Compiling JIT block 0x8006b6ec, 327 instructions
45:29:693 Core/PowerPC/Jit64/Jit.cpp:749 E[PowerPC]: Compiling JIT block 0x8006b71c, 315 instructions
45:29:693 Core/PowerPC/Jit64/Jit.cpp:749 E[PowerPC]: Compiling JIT block 0x8006b744, 305 instructions
The rest of the log keeps going down until Dolphin compiles a ~19 instruction block. But, we can already see what's wrong with this little slice. Dolphin compiles a JIT block of 350 instructions using branch following and then only executes 10 instructions of it before hitting a jump and compiling a block of 338 instructions. Within one block Dolphin can take the wrong branch over 30 times, bloating the JIT cache to unreasonable levels. Mario Party 2 and friends were managing to overflow the cache multiple times per minute while generating tons of unnecessary code that never gets executed. All because Dolphin's JIT was being a little too adventurous with its optimizations.
As of 5.0-8377 Branch Following has been completely disabled for N64 Virtual Console games, restoring their performance to that of before when branch following was added in 5.0-2178.
5.0-8397 - Android: Make Touch Joystick Re-centering Optional by gwicks¶
Joystick Re-centering makes a lot of games more playable on a touchscreen. Anything requiring precision movement or platforming is nearly impossible without re-centering enabled. Alongside some relief, there was also some disappointment among users who preferred the old method for the games they played. There were some valid concerns - some people preferred static placement for racing games and RPGs to making driving and menu navigation easier. While touchscreen games can carefully curate their control scheme to their needs, Dolphin can play thousands of different games. If we hope to make our touchscreen controls usable across many of those, there needs to be flexibility.
To truly explain why, here's a demonstration using homebrew to show how the controls translate to a controller.
Mode 1: Re-centering Disabled¶
This is the original way that Dolphin handled joystick input on touchscreens. The virtual joystick is planted in a spot, and if you touch in its range, it'll tilt toward the center of the touch. So if you touch at the extremes, you can immediately be at the limits of the joystick range. This makes navigating menus and making quick movements much easier to do while sacrificing some precision for smaller movements. If you're careful and make sure to plant your thumb right in the middle of the range every time, it's absolutely possible to perform precise movements. But when faced with complex platforming challenges or other timed challenges that require precise movement, this behavior is more likely to cause you to fail than anything else.
Mode 2: Re-centering Enabled¶
This was the only option as of 5.0-6376 and originally replaced re-centering disabled. This mode was a direct response to how difficult it was to control platformers and action games. Without this feature, it took JMC47 three hours to pass a simple platforming challenge in The Legend of Zelda: Wind Waker that would take less than a minute on a conventional controller. The problem was that whenever he touched the joystick, he would start moving in a direction and then have to adjust his thumb to get to the correct angle before accidentally jumping off a small platform. Touching it directly in the center to setup a precision jump without wasting too much time was extremely difficult to do once, but with there being several consecutive jumps, it bordered on maddening.
Everything about this puzzle is simpler when using Joystick Re-centering. Instead of being worried on exactly where you're going to touch the screen, you can instead focus on just moving around and making the jumps. As long as your thumb is close to the joystick range when you touch, it'll re-center on your thumb so that you can then accurately choose where you want to move. After getting used to the feature, all of the platforming challenges in The Legend of Zelda: Wind Waker can be completed without accidentally lurching off of small platforms at the slightest of mistakes. Is it as easy as just using a physical controller? No, it doesn't quite replace the tactile feedback of using a controller. But, if you're looking to play a platformer on your phone without lugging around a controller, this feature will make things much easier.
If you're not a fan of touchscreens, JosJuice fixed axis input detection issues in 5.0-8486 that caused Xbox One and other controllers to be impossible to configure.
5.0-8474 - Work-Around Adreno Issues To Fix Vulkan Support by stenzek¶
The Vulkan backend has been broken on most phones since its addition to Dolphin. And it's not because of anything in the Vulkan backend itself - it's just driver bugs. While stenzek was hoping for a driver update to resolve the issue, it appears that won't be happening any time soon. So he dug into the issue himself and found what Dolphin was doing to put the drivers into such a gnarly state. Eventually he found out that 32-bit floating point depth clears were broken on Adreno. This is rather problematic, as Dolphin needs every bit of that precision to accurately emulate some GameCube/Wii games.
But most users on phones are much more concerned about performance than flickering and broken edge-cases, so stenzek bit the bullet and made a less accurate path that uses 24-bit depth throughout rendering before resolving it to 32-bit depth at the end. While this causes a rather damaging loss in accuracy, it does allow Vulkan to render better than it once did on some Adreno devices.
While this will work for some games, Vulkan on Adreno will have various problems thanks to using 24-bit depth. Our hope that this will tide over users looking to take advantage of their phone's Vulkan support while the driver developers work on various upgrades for their driver. Once 32-bit depth clears are fixed in the Adreno driver, this hack will be removed.
5.0-8488 - Support for Android Oreo Homescreen Channels by zackhow¶
One of the new features of Android Oreo T.V. Interface is homescreen channels for apps. This lets you have a shortcut to your favorite Hulu/Netflix/Amazon/YouTube channel without having to boot into the main application. But, it doesn't have to just be used for channels like that, any application can use it. zackhow has taken advantage of the Homescreen Channels feature in order to give you the ability to directly boot your favorite games without even having to navigate through the Dolphin app!
With this feature, launching your favorite games is a snap. It also features the ability to display your games with the game banner, a temporary banner for Wii titles until a save is made, or a screenshot taken while playing the game.
5.0-8500 - Android: Fix Configuring Emulated Wii Remotes to Controllers by zackhow¶
This is one of those bugs that just slaps you in the face when things are starting to work. Dolphin on Android has seen a lot of features and improvements this month, there always seems to be more problems just over the horizon.
After so much work on getting touchscreen controls working well, a slew of reports hit claiming that configuring emulated Wii Remotes to controllers didn't work at all in Android. This was particularly problematic on Android T.V. devices that didn't really have any other option for using emulated Wii Remotes. zackhow investigated what was going on and found out that the bug was essentially... very embarrassing.
BEFORE AFTER
GCPAD_1("gcpad", 0), > GCPAD_1("gcpad", 0),
GCPAD_2("gcpad", 1), > GCPAD_2("gcpad", 1),
GCPAD_3("gcpad", 2), > GCPAD_3("gcpad", 2),
GCPAD_4("gcpad", 3), > GCPAD_4("gcpad", 3),
WIIMOTE_1("wiimote", 1), > WIIMOTE_1("wiimote", 4),
WIIMOTE_2("wiimote", 2), > WIIMOTE_2("wiimote", 5),
WIIMOTE_3("wiimote", 3), > WIIMOTE_3("wiimote", 6),
WIIMOTE_4("wiimote", 4), > WIIMOTE_4("wiimote", 7),
WIIMOTE_EXTENSION_1("wiimote_extension", 1), > WIIMOTE_EXTENSION_1("wiimote_extension", 4),
WIIMOTE_EXTENSION_2("wiimote_extension", 2), > WIIMOTE_EXTENSION_2("wiimote_extension", 5),
WIIMOTE_EXTENSION_3("wiimote_extension", 3), > WIIMOTE_EXTENSION_3("wiimote_extension", 6),
WIIMOTE_EXTENSION_4("wiimote_extension", 4); > WIIMOTE_EXTENSION_4("wiimote_extension", 7),
If you look at the controller IDs above, you'll see that GCPAD_2 through GCPAD_4 overlapped with WIIMOTE _1 through WIIMOTE_3. WIIMOTE 4's controller ID was actually being assigned to WIIMOTE_1. Needless to say, the issue was very quickly rectified once it was identified. Another offset issue in the code that was less damaging was also addressed in 5.0-8512 which was causing the emulated controller selection to be offset by one slot.
These hotfixes should combine to make Emulated Wii Remotes configurable to controllers on Android while the larger configuration rewrite goes through the review process. The rewrite should make it much harder for things to break like this in the future.
5.0-8443 - Improve Various Emulated Wii Remote Input Behaviors by iwubcode¶
Dolphin has three options for Wii Remote Inputs, two of which that require physical Wii Remotes. The third, Emulated Wii Remotes, excels mostly for games that don't do all that much with motion controls. A game like Super Mario Galaxy can be completed pretty easily with just mapping "shakes" to a button and using your mouse (or a joystick) for controlling the Wii Remote pointer. On the other hand, games like Red Steel and Metroid Prime 3: Corruption can be more difficult due to their insistence on using more precise motions. Others, like Boom Blox could be completely impossible because it actually takes the strength of the shake for your throw.
Thanks to Nintendo still using Wii Remotes as one of the primary input methods on the Wii U, real controllers are still fairly plentiful, but that doesn't excuse some of the flaws within Dolphin's emulated Wii Remotes. iwubcode returns to the project with a slew of improvements to Dolphin's Emulated Wii Remote code to make doing various motion inputs much easier!
Dynamic Motion Strength¶
Instead of shaking or swinging at a constant strength, you can now configure Dolphin to ramp up the strength of the motion depending on how long you hold the button. This can be useful in games that use shaking for recharging like No More Heroes or throwing the baseball at maximum speeds in Wii Sports.
Configurable Motion Intensity¶
Sometimes, simply having shaking get stronger isn't quite enough. Boom Blox has three specific shot types tuned for ranges of shaking. Simply trying to guess how long to hold down a button to get the strength required wouldn't make the game very fun. For situations like these, iwubcode has added the ability to have three completely separate shake strength options for each axis resulting in up to nine different buttons for various shake directions and strengths.
On top of all of that, iwubcode made the strength of each throw customizable for games that use different ranges for various actions. While this may seem daunting, Dolphin's GameINI system should simplify things by setting the strength of each throw to reasonable values for specific games. For now, only the two Boom Blox games have customized strength values, but the system is in place so that strength values can be added to more games as they are researched.
Improved Swing Reliability¶
Some games require more than just waggling in order to proceed. The Wii Remote can also report something called swings. The problem with Dolphin's swinging detection is twofold: it doesn't make what games are looking for with swings clear and it had buggy detection. While games can be picky about their detection, some issues with swings were fixed, including one that caused Dolphin to only report a swing for the first frame of a swing input. Disaster: Day of Crisis previously wouldn't detect your swings when lifting rubble off of others.
This also allows games like No More Heroes, Red Steel, and Spectrobe Origins to be more easily completed on emulated Wii Remotes and greatly increases the reliability of swing based actions in all games. Just remember that a swing motion on console is more than just the straight motion Dolphin calls 'swing' and because of that many games need to see two motions to be properly detected!
Increase Default IR Bounds¶
This was more of a usability problem than an actual bug in the emulator. The default IR limits didn't let you reach the corners of the screen in some games and software. This is because games could calibrate the IR however they choosed, meaning the bounds varied from game to game. Dolphin's defaults just weren't good enough for some titles. Advanced users could work around this through the advanced control configuration by right clicking a button, but, asking that of everyone was a bit unreasonable.
iwubcode happily changed the defaults to something more sensible while improving other aspects of emulated Wii Remotes. For games that seem too sensitive with the new defaults, the range can still be manually adjusted by right clicking the configuration buttons and adjusting the slider down.
Profile Switching¶
Even with all of the added customization, some games require even more to be playable on a controller. Games like Wii Party use the Wii Remote in a variety of ways that make it difficult to hook up to a single configuration. In order to make things easier for minigame collections, iwubcode has made Dolphin's Controller Profile support more robust. The newest feature for this is that you can now have game specific controller profiles and swap between them with hotkeys. This makes it possible to play through Wii minigame collections without having to start and stop to switch controller profiles at every minigame. And while less useful, this update also adds the ability to switch between all profiles on any game.
5.0-8482 - Remove Skip DCBZ Hack by booto¶
This is one of those options that... it's hard to explain why it's still around outside of ambivalence. Outside of a single WiiWare title, the setting hadn't been enabled in any games by default. In Rubik's Puzzle Galaxy: Rush the Skip DCBZ Hack had lain dormant, supposedly a benefit to be enabled for this game.
In the case of Rubik's Puzzle Galaxy: Rush, the Skip DCBZ Hack was once needed to work around other inefficiencies in Dolphin in order to make the game boot past the menu. At some point this behavior changed, likely around the time of Dynamic BATs. For some reason, upon its merger many games stopped requiring the Skip DCBZ Hack for unknown reasons, including We Love Golf! The stranger part of this is that none of these games actually required MMU emulation whatsoever and why they started working was never truly ascertained.
This feels oddly familiar...
Regardless of how we got here, the Skip DCBZ Hack is no longer needed and has actually been causing trouble. What actually spurned investigation into Rubik's Puzzle Galaxy: Rush was actually the growing issue of users accidentally enabling the Skip DCBZ Hack in older builds and forks where it still resides within the Game Properties page despite its removal in master many months ago. This would lead to wild goose chases trying to figure out why a game that works for everyone else is broken for this user. And when looking through their settings at a glance, everything would look fine!
The reason that Skip DCBZ Hack could be so damaging is that games often use this instruction to zero out memory before switching tasks. Skipping it will often cause issues with video playback, loading new levels, or even prevent the game from functioning whatsoever. In the case of Rubik's Puzzle Galaxy: Rush, it caused severe graphical issues with most 2D elements.
In order to make sure that the Skip DCBZ Hack could do no more harm, testers verified that it no longer benefited any games. This meant testing every game that had the Skip DCBZ Hack enabled at some point over its history as well as investigating old forum posts and recommendations. Despite this, no good results could be found and the feature was axed. It must be noted that this does not affect a separate DCBZ related hack that bypasses the anti-emulation code in Disney's Cars 2 and Disney Infinity. Because that option was never a part of the GUI, there is little to no risk of it being mistakingly turned on in other builds.
Website Improvements¶
You may have noticed that Dolphin's blog has seen some improvements over the course of July. One of those changes was probably noticable in the Myth Debugging Article this month when we looked at some of the different challenges that the GameCube and Wii hardware present to Dolphin. Featured within it was an interactive chart showing the performance of various GameCube and Wii games. Dolphin's blog now has support for highcharts charts which allows for easily creating and displaying interactive data. It's so easy a blog writer can use it... after some instruction. There were also some minor formatting fixes to the blog navigation page.
Other parts of the website also saw some major improvements over the month. The download page should be much snappier to use in recent days as a simple, yet huge optimization was pushed through by delroth to aid in the construction of the list of downloads. With dolphin-emu.org hosting every build of Dolphin's master branch all the way back to 3.0-749 the old code had become a bit too slow to handle the many thousands of builds.
On the translation side of things, the Farsi and Croatian translations were removed because they were lagging behind, but, Danish, Galician, and Norwegian (Bokmål) have been added in the meantime. Behind the scenes, Dolphin's website has been upgraded from Django 1.7 and Python 2.6 to Django 2.0 and Python 3.6. Overall the improvements should add up to a nicer experience when navigating Dolphin's website and help the blog staff continue to bring you high quality articles moving forward.
Last Month's Contributors...¶
Special thanks to all of the contributors that incremented Dolphin from 5.0-8309 through to 5.0-8512!