Now that the festivities surrounding the Dolphin 5.0 (and more importantly the feature freeze) are complete, changes have begun to roll into Dolphin once again. While none of the heavy hitters have gotten in just yet, June and July had more than their fair share of merges, regressions, and reverts that make up the typical Dolphin workflow.
It's good to be back!
While many were expecting Dolphin's next video backend to be Vulkan-based, degasus had something else up his sleeve - the Null Video Backend. Make no mistake: the Null Video Backend is the fastest video backend in Dolphin by far. The other backends don't even come close! The cost of this performance is... well... it doesn't render anything. The Null Video backend is mostly for testers and developers who are tackling very specific issues. General users shouldn't really shouldn't be using it, except for narrowing down performance issues. Hopefully the next backend on the docket is more to the tune of what people expect!
This is totally a screenshot from the null video backend, and not a black box made in paint. We swear.
This is a fairly simple change on the outside that was a bit more complicated to actually implement. Previously, developers recognized that many paired loads and stores in games ran with the Graphics Quantization Registers (GQR) set to zero, so they set up a fast (optimized) path for zero while falling to a slow path for anything non-zero. While this gave a nice speed up in most games, mmastrac realized that the performance gains could be spread even further. Instead of just having an optimized path for zero, Dolphin now optimizes it for any constant value, resulting in significant performance gains for all games that use non-zero constant values for the GQRs. This can result in up to a 10% speedup in those games.
5.0-97, 5.0-99 - Split Video/Audio File Dumps on Changes That Would Previously Corrupt or Desync Output File by Fog¶
Dolphin's audio and video dumping capabilities have improved a lot since Dolphin 4.0. While users still have to manually combine audio and video, for the most part, things just work for a majority of games. But, as Dolphin gets more accurate, a wrench always seems to get thrown into previously written code.
One of the rules of video dumping in Dolphin is that if the resolution of the output changes, the video will be corrupted. Now, this behavior used to only affect users who were changing graphics settings while dumping output, so there was no real need to change the behavior. But, upon Dolphin has gotten a more accurate over the years and can even emulate resolution changes employed by the games, subtle or not. One key example is with Dolphin's GameCube Widescreen Detection; because this involves a change in output, it could now corrupt videos. This meant games that started in 4:3, like F-Zero GX, and then checked before the main menu for widescreen on the save couldn't be recorded with the default settings.
Another case is those games that subtly change their aspect ratio throughout play, such as Super Smash Bros. Melee. Between the main menu and character select, the aspect ratio very slightly changes, and now that Dolphin more accurately emulates a game's aspect ratio, it matches this change. This also would cause video output to be corrupted!
In order to obviate these issues, Fog came up with the idea of splitting the video on resolution changes. While it's not the most elegant of solutions, it works as planned and prevents videos from being corrupted.
As for audio issues the same thing applies - Dolphin now emulates sample rate changes properly instead of having it hardcoded. Some games change the audio samplerate a lot, and it would cause issues with syncing audio to video. Dolphin now splits audio on samplerate changes, allowing for much easier synchronization between video and audio files.
As an added bonus, Fog also added a configurable dump-path in 5.0-112 so that users can use a secondary hard-drive for all of their dumping needs.
In Dolphin, cheatcodes from the previous game session would normally be cleared when you boot up the next game. So, let's say you're playing Super Smash Bros. Melee, with the Netplay Gecko Codes, then go to play Super Smash Bros. Brawl with Brawl's Netplay cheat codes. Everything works as intended.
The problem is that there are specific cases where we can miss that trigger. Namely, homebrew; which actually posed a significant problem for smashladder players. They use GeckoOS in order to patch in complicated cheatcodes to turn Brawl into Project M, but under Dolphin's method of applying cheatcodes, if they had already played Melee beforehand, Melee's cheats would get stacked in on top, usually causing invalid reads and a crash.
This oversight occurred because there are so many different GameCube/Wii filetypes that can be loaded in Dolphin with their own specific needs. Now instead of clearing Dolphin's PatchEngine upon booting a game, it is cleared when shutting down a game. This completely solves the issue of Action Replay and Gecko codes from one game leaking into another.
Here's a fun-fact: Wiimote Netplay has never been in any of Dolphin's releases. It was implemented very shortly after Dolphin 4.0's release, and removed shortly before Dolphin 5.0's because no one among the staff could get it to work. Emulated Wii Remotes in Netplay was an experimental feature that never quite lived up to expectations.
In order to make Wiimote Netplay actually usable, several issues had to be addressed.
- You had one chance to start a Wiimote Netplay Session. If you failed to get it right the first try, you had to exit the emulator because any subsequent attempts would cause the emulator to hang.
- Each instance of Dolphin randomly assign wiimotes to slots on its own, creating randomness that would make Wii Remotes desync.
- Wiimote Extensions didn't work.
- Tons of games simply wouldn't boot.
With all of those issues, Wiimote Netplay was very crippled as a feature and thus removed before Dolphin 5.0. With the fixes from mimimi and JMC47 all of these issues should be solved. This does not mean you should rush out and try Wiimote Netplay, it is still a feature that should only be used by very advanced users that are familiar with netplay and its quirks. For one, it still pulls in extension data from each player; meaning users will need to mostly sync up their Wiimote settings before playing, and some unknown data from the emulator is leaking into the blank NAND, meaning that a portable copy of Dolphin without an imported console NAND is still recommended for use on Wii netplay if you run into desyncs.
Aestek is on a mission: Make netplay easier and more efficient to use. Since Dolphin 4.0, a ton of features have been added to make netplay easier to setup, such as not writing to memcards, a traversal server for users who can't port forward, and the automatic syncing of important settings. But those are all internal features: the UI itself has remain mostly unchanged outside of being modified to fit the new features. In order to make things outwardly easier, Aestek has made a bunch of changes to the netplay experience to make things less inconvenient.
- Netplay Disc/SD MD5 check: Allows users to check their ISO and SD hashes. If the MD5 hashes don't match, it could cause a desync.
- Chat Display on Screen: Chatting with other users when playing in full-screen could be a pain before. Now there is a setting to allow netplay messages to be sent to the screen! This includes the "Possible Desync Detected!" message.
- Panic Alert No Longer Freeze Netplay: If a non-fatal Panic Alert hits Dolphin during netplay, it is now displayed in chat instead of freezing or crashing netplay.
- Prettier UI and Colored Chat: Makes it easier to go through and read chat.
These are the basics; everything about the user experience has been improved!
The Real Time Clock (RTC) is a feature most people don't think about, but it is used by a lot of games. In Pokemon Channel, they force you to wait over the course of days for new content to arrive on the T.V. for example. Animal Crossing has different events for day and night and some people may not be able to play throughout the different times of day.
Dolphin emulated the RTC by simply using the host computer's system time. It was an elegant solution. Not only does it just work, but if someone wanted to change the time in game, just change the system time! Super simple. But there are two cases where changing the system time was not cutting it - Tool Assisted Speedrunning (TAS), and netplay. Many games actually use the RTC as a variable in random number generation, and to create a replayable TAS or stable netplay, the RTC has to be accounted for. Netplay had a trick of just running at a default time, but TASers had no choice but to struggle with their system time and hope it worked.
To address these issues, Fog added a configurable RTC setting to Dolphin's advanced settings. Most users still won't need to worry about it, but if you ever need to change the RTC, this makes it so much simpler!