
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 Update¶ 6s262q
s may 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. s 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¶ 10q4e

A few s 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 s 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 U 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 U is expecting it to be running speed while the GPU is running at another.
For experienced s 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 aware of the implications of disabling it.
DolphinBar Bluetooth Adapter through Update¶ 4o3z6m
It seems that Mayflash has expressed interest in implementing Bluetooth through for the DolphinBar in the future! Considering the large number of s with DolphinBars, we hope can be added so more people can try Bluetooth through!
With those big announcements out of the way, let's get to this month's Notable Changes!
Notable Changes¶ 39372c
¶ 6nt53
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 s, it'll make things a lot easier for those looking into strange behaviors with more logging available in the most common builds of Dolphin.
¶ 6nt53
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.
¶ 6nt53
Two years ago, flacs 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 through mode. This gives DolphinBar 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.
¶ 6nt53

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!
¶ 6nt53
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 through 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 through is and its limitations, check out our feature article!
¶ 6nt53
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.
¶ 6nt53
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 of HiDPI, EmptyChaos stepped up big with a mammoth change adding HiDPI 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.
¶ 6nt53
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 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 , we'll have to start considering whether to remove the experimental tag on it!
¶ 6nt53
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 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!
¶ 6nt53
Despite the innocuous name, this is actually a huge change that can potentially affect the pixel accuracy of every game.
The Issue¶ 6l3740
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 asg 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¶ 5c55i
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 s, 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¶ 4o4w1n
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 s 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 preference.
Last Month's Contributors...¶ 2v561r
Special thanks to 5.0-1209!