This month, we have a few very important things to go over before we get to our notable changes, so let's dig right into that.
NVIDIA Vulkan Support Update¶
Users may remember that we recommended using older versions of the NVIDIA drivers when using Vulkan. Well, this is no longer required as once NVIDIA was aware of the bug, they fixed it in a few minutes and the fix was rolled out in driver version 375.63. Users can now use the latest version of NVIDIA's drivers without worrying about Vulkan issues in games that use Dolphin's dual source blend.
Idle Skipping Option Removal¶
A few users got confused when they noticed "Disable Idle Skipping" was removed. Idle skipping is something you always want on at this stage of Dolphin's development. There are no known downsides, and it makes the emulator run faster by skipping instruction loops that do nothing.
Yet, some users will forever claim that turning off idle skipping raises performance, which is simply not true. What's actually happening in those cases is an exploit of another behavior. When a game hits idle skipping, Dolphin uses that opportunity to synchronize the CPU and GPU threads, greatly increasing the stability of the dualcore setting. Without it, many games will straight up crash in dualcore, such as Need for Speed: Hot Pursuit 2. Other games will run completely desynced; with those titles running at framerates they was never intended to run. When those games then try to communicate with the GPU, bad things happen because the CPU is expecting it to be running speed while the GPU is running at another.
For experienced users who do want to disable that syncing, the "SyncOnIdleSkip" option can be found in Dolphin's INI file and set per game in game INIs. We highly recommend you do not do this unless you're an advanced user aware of the implications of disabling it.
DolphinBar Bluetooth Adapter Passthrough Update¶
It seems that Mayflash has expressed interest in implementing Bluetooth Passthrough support for the DolphinBar in the future! Considering the large number of users with DolphinBars, we hope support can be added so more people can try Bluetooth Passthrough!
With those big announcements out of the way, let's get to this month's Notable Changes!
Logging in Dolphin is important; it helps immensely with tracking down bugs in the emulator and monitoring what games are doing in various situations. For many, many years, the two strictest log types, Info and Debug have been relegated to debug builds. With aldelaro's retooling of logging, a lot of the most useful debug logs have been moved to info. As an added bonus, Info logs are now available in release builds without bringing the drop in performance once associated with the Debug and Info logs.
While this may not seem all that exciting to users, it'll make things a lot easier for those looking into strange behaviors with more logging available in the most common builds of Dolphin.
Before this build, shutting down Dolphin was akin to unplugging the Wii. This is a hold over from the GameCube; where turning off the console simply cut power to the console. The Wii actually does quite a few things when you hit the power button before it actually turns off. While 99% of the time none of this matters, there is actually a case where this proves to be a fatal flaw.
NES and SNES Virtual Console games that save. Those games only flush the save data to NAND when you turn off the console, reset the game, or return to the system menu! That means if you save in Super Mario RPG: Legend of the Seven Stars and then turn off Dolphin... say goodbye to your savedata!
As of 5.0-775, Dolphin now attempts to shut down games properly. This means that Dolphin will go through the necessary steps to gracefully shutting down Wii software. This fixes issues in games that flush savedata on shutdown and makes it so games will properly fade out when closing the game window.
Do note: if for some reason gracefully shutting down does fail, attempting to stop/close the game twice will unplug the software, mimicking the old behavior. There are currently some games that don't work with graceful shutdown due to various deficiencies in Dolphin's IOS emulation.
Two years ago, flacs planned to completely remove the old Wii Remote support and use a unified HIDAPI backend for handling Wii Remotes. Not only would this have nicely simplified Dolphin's code, but it would have brought support for the DolphinBar to Linux. Unfortunately, the Windows implementation of hid_write() was incompatible with Wii Remotes ending that dream.
leoetlino picked this up nearly two years after the original backend was written. Instead of trying to replace all other Real Wii Remote implementations, he decided to instead add another one. While it added additional code complexity, the HIDAPI backend did increase compatibility of Wii Remotes on Linux when not using passthrough mode. This gives DolphinBar support to Linux and FreeBSD (the first time FreeBSD has had the ability to connect real Wii Remotes!) and replaces the old macOS implementation of HIDAPI.
This small feature is one of the most persistently requested features of all time! With the typical Emulated Wii Remote setup with the pointer mapped to a joystick, it works exactly as a joystick should: the center is center, press it all the way to the right for the pointer to go all the way to the right, and then release and the pointer immediately returns to the center. This is fine of course, but this is very very different from how the pointer works with a Wii Remote and sensor bar, making fine control very difficult.
This change addresses that, by adding an option to make joystick pointer movements relative: by moving the joystick, you are moving the pointer, but when you release the joystick, the pointer stays in place. You can increase or decrease its sensitivity as well, by right clicking each of the pointer IR directions and adjusting the input range. All in all, this is a HUGE step forward for controlling a pointer with a joystick!
This is one of those changes that we expected to do something but really came out of nowhere with just how big of a difference it made. Essentially it's exposed the limitations of Dolphin's emulated Wii Bluetooth emulation as fairly limited and buggy while at the same time proving that many Bluetooth adapters are capable of handling Wii Remotes when not hampered by Bluetooth stack limitations.
Bluetooth Passthrough mode is taking a hammer to all of our Wii Remote issues and saying, "We're not going to emulate a Bluetooth adapter," and instead just hand the game one directly. If you have a good enough Bluetooth adapter, it's very possible to get identical Wii Remote performance as console. In our feature article on it, there was an example showing a real Wii Bluetooth adapter hooked up to a PC and used in Dolphin!
There's no need to panic if you don't have a compatible adapter or don't want to use this feature. Emulated Bluetooth (the former Real Wii Remote emulation method,) is not going anywhere and should be easier to improve now that there is a another method with better results. For a full review on what Bluetooth Passthrough is and its limitations, check out our feature article!
While we have a dedicated menu for netplay, it can be a bit clunky and unneeded if you just want to host a game. In order to streamline things, you can now simply right click a game in the gamelist and host a netplay session from there.
With HiDPI screens becoming more and more common, Dolphin has had to adapt its ancient wxWidgets UI for a changing landscape. While the team does have plans to move on from it eventually, this is the main UI for now and it needs maintenance. In terms of HiDPI, EmptyChaos stepped up big with a mammoth change adding HiDPI support that works on Windows, Linux and Mac. If you have a HiDPI screen, this should fix various issues with text boxes being too small, numbers not showing up, misaligned menus in the control menu and much, much, much more!
As an added bonus, EmptyChaos also fixed a few UI segfaults and memory leaks spotted along the way.
Most of the changes in this are very minor, so we're going to rapidfire through them.
- Vsync is now disabled when the framelimiter is disabled. Fixes issues with using hotkeys to disable the framelimiter.
- Various Texture Cache issues resolved
- Add support for Destination Alpha + LogicOP case for Kirby's Return to Dreamland.
- Fix various memory leaks
Though not directly related to these changes, 5.0-985 also fixed a bug in Vulkan with Paletted EFB Copies. This fixes overbloom issues in Dragon Ball Z: Budokai Tenkaichi 2 and 3 along with other titles.
With these additions the Vulkan backend is maturing nicely. Once it has XFB support, we'll have to start considering whether to remove the experimental tag on it!
Working on Android Dolphin has gotten a lot easier recently; you can now build Android APKs from Windows. This makes it easier for developers to make changes; and hopefully will result in a much smoother time developing new features for Android. For now, though, two mainstays of Dolphin Android UI, Sigmabeta and SeannyM return to fix up quite a few UI problems that've cropped up!
Some of the highlights include changing to the light theme by default, which makes it a bit easier to see text, buttons and other UI elements. Don't worry if you preferred the dark theme; it's still there and you can switch to it at will. For Wii games, the Classic Controller is now available for use with on-screen buttons, allowing games like Xenoblade Chronicles and The Last Story to use their best control schemes! While performance may not be there yet, at least the controls are waiting!
The Android (and Shield Android TV) UI uses screenshots from the game within its UI so you can differentiate games more easily. Unfortunately, that somehow got broken and no one noticed. One of the issues with developing for Android at this point is that there isn't as big of a user pool for Dolphin yet; it requires insane hardware, the Android version isn't as complete in spots, and little bugs like this tend to slip through. It's fixed now, but don't be surprised if little Android-specific problems sneak in here and there.
Last but not least, Dolphin no longer crashes when going above the root folder! This means you can finally load games off of an SD card properly. Hopefully, continued development on the Android version of Dolphin and the ever increasing performance of phones will make the portable GameCube and Wii dream realized sooner than later!
Despite the innocuous name, this is actually a huge change that can potentially affect the pixel accuracy of every game.
The issue was discovered in Ed, Edd, and Eddy: The Mis-Edventures for GameCube. For some reason, in the hardware backends the game would render incredibly dark most of the time. After years of the bug existing, testers finally narrowed it down to only being dark when character models are being rendered. That led Armada to investigating further, eventually finding out it wasn't the characters themselves causing the darkening, but their shadows.
You can just see Johnny (a character in the show) on the bottom of the screen. Him being there causes the darkening.
The technique this game uses to render shadows is known as Stencil Shadows, which was used in a lot of games at the time. The trick behind this technique is to render an extra set of "shadow volumes" for each of the shaded character models and track exactly where these volumes intersect with the ground and other objects. This information is used to generate a "stencil" which serves as a sort of cut-out mask that can later be used to darken the spots that are covered by the shadows.
Normally the stencil is stored in a Stencil Buffer, but the GameCube doesn't have one, so the developers needed to find another way to store the stencil. They ended up with a creative solution: store the stencil in the alpha channel of the rendered frame which is normally used to store transparency information. This explains why the entire screen is dark: something went wrong with storing the stencil in the alpha channel, causing the cut-out mask to cover the entire screen. Thus the game thinks everything is in the shadow and darkens every pixel on the screen.
So what went wrong with storing the stencil in the alpha channel? Well, it turns out that on the GameCube you don't get the extra alpha channel for free. The alpha channel is part of the framebuffer (EFB) together with the red, green and blue color channels (RGB) and the GameCube only has 24-bit per pixel in the framebuffer. So to use the full 24-bit color range of your monitor it has to use everything for the RGB color channels. When you want to enable the alpha channel it has to make room for that by only assigning 6 bits to each color channel, which leaves another 6 bits free for the alpha channel. Dolphin on the other hand actually has 32-bit per pixel in the framebuffer, so it can use 24-bit colors and still have 8-bit left for the alpha channel.
But using 8-bit precision when the game only expects 6-bit will result in rounding errors at some point and it turns out that assumption finally broke something with this game. Despite being somewhat maligned, Dolphin's software renderer came into incredible use with this issue because it rendered everything correctly. Since the software backend was written to be as accurate as possible it was already using 6-bit for each channel in the framebuffer. Being able to compare the broken implementation to a working one proved that we finally found the problem.
Crafting a Solution¶
The solution was very straightforward, just use 6-bits of precision for each channel as the game expects. However considering that people have come to enjoy Dolphin for its ability to enhance the games, losing color precision would make things look worse in some cases. The increase in banding on skyboxes was immediately noticeable in early testing. Some dithering was added to reduce the banding, which the GameCube also supports, but it still wasn't as smooth as 24-bit color.
Armada added a great compromise though: only throw away the 2 bits when writing the alpha channel to the framebuffer. This way we can have an accurate alpha channel while displaying full 24-bit colors!
No no, "everything is brown and sickly" isn't the bug, it's supposed to look like that. It's too dark.
Most of the transparency effects are also still done with 8-bit alpha, because only the alpha stored in the framebuffer needs 6-bit accuracy. So only effects using the alpha value in the framebuffer will suffer from reduced alpha channel accuracy.
Aftermath and Observations¶
During the testing and after the merge of this change, two other games were discovered to rely on 6-bit alpha channel accuracy - Zero: Tsukihami no Kamen (aka Fatal Frame IV), and the Ace Attorney series. This fixes the blue fog in Fatal Frame IV and incorrect bars on the screen in Phoenix Wright.
Fun fact: while looking into Phoenix Wright, it was discovered that the Wiiware releases are emulating the DS releases to at least some degree. If you look into the graphics pipeline, you can see how the frame is constructed from an extra-tall framebuffer.
The more notable thing is that certain games were readily aware of the GameCube's limited color palette and had textures designed around it. Namely, we discovered some textures in The Legend of Zelda: The Wind Waker that can look better in spots with the reduced color accuracy.
Being designed for RGBA6 and dithering, Wind Waker's textures often look better and less splotchy with Force 24-bit Color disabled.
As such, if users want to use the color accuracy of the GameCube and Wii, you can now go into the Graphics Settings/Enhancements menu and disable "Force 24-bit Color". As noted, the alpha accuracy has been fixed in both modes, so this is not needed for fixing the aforementioned games that had issues previously. This is only for user preference.