There was apparently some big deal this month about getting every GameCube game to boot. But, the increasingly more amusing part of this new found accuracy is emulating game crashes. When using MMU Enabled + Single Core, it should be impossible for a game to crash Dolphin, but, much more likely to emulate a game crashing in situations where it would on console. As such, booting all games is old news, Dolphin is now onto emulating crashes in all games. One infamous one that didn't work in Dolphin is known as the Gotcha Force "Force 20" game glitch.
Though not specially highlighted this month, our applause has to go to aldelero5 for continuing to work on and renovate Dolphin's debugger. With Dolphin's increasingly accurate MMU emulation, it's actually become even more useful to poke at and prod games. They are making it so much easier to research and prod bugs like this to delve even deeper into the game logic!
While that was merged near the beginning of the month, we had another major change merged at the end of the month. Two hours before the progress report was originally scheduled. Dolphin now has another experimental backend, this time using the Vulkan API. Much like D3D12, it should be considered experimental, with a few features still missing from the backend, and many drivers having their own issues with Vulkan.
With that out of the way, let's get onto this month's notable changes!
If you couldn't tell by the introduction, this is still a pretty big deal. Dolphin is capable of booting every single GameCube game now, and the only two games that don't get in-game are Phantasy Star Online 1&2 Trial Edition and the Game Boy Player. Both require emulating new hardware addons for Dolphin to boot them, and the Game Boy Player is an entirely different system! Fortunately there is already a great emulator out there which may take up the task.
Because we already had an absolutely huge article on it, there isn't much else to say. In summary, better Memory Management Unit emulation gets Star Wars: The Clone Wars to boot while fixing a gaggle of other bugs.
Instead, let's focus on the impact and reports we've gotten from users, as well as some trends we've noticed over the past four weeks since it's been merged.
- Reports of Broken Games: Harry Potter and the Prisoner of Azkaban was reported as broken by this change. We investigated and found that this game is a bit of a special case. It only runs in Dolphin's JIT! The seemingly more accurate Interpreter, Cached interpreter and less accurate JITIL all immediately crash on boot! We tested the game before and after Dynamic BATs. There is no regression.
- Performance Issues: Some users have reported anywhere from a 16% to 33% slowdown on certain configurations, but when it comes to reproducing these slowdowns, no one on the staff can actually see a major slowdown in non-MMU titles. If you're seeing slowdowns since Dynamic BATs in non-MMU titles, try to hang in there; there's still more optimization that can be done on CPU emulation and any slow down should be possible to counteract. It's just identifying what (if anything,) is slower right now.
- JITIL Issues: We broke JITIL again. There is no reason to be concerned, this is par for the course. We break JITIL all the time. Anyway, enable MMU + JITIL will cause Dolphin to lockup on game boot. We recommend you do not do this. Unless you really need to see that we're not joking. The question is whether we do the work to fix JITIL or simply remove it. With JIT issues becoming less and less common, JITIL is becoming less and less useful to keep around. Also Cached Interpreter replaces some of its usefulness as a comparison to the JIT that isn't super slow.
While Dolphin still doesn't support USB Microphones, there are actually a couple of games that check for the USB Microphone without actually requiring it, such as the newer Just Dance titles. Since Dolphin didn't even have basic USB emulation, when the game checked for a USB microphone, it would just crash before it even finished booting. So in order to get the non-Microphone portions of the game to work, some very basic functionality of USB Microphone detection needed to be added.
Dolphin now properly fails the game's USB check, allowing the game to boot.
A while ago on the Progress Report, we alluded to the fact that Dolphin's Auxilliary RAM Direct Access Memory (ARAM-DMA) timings suddenly become different when Resident Evil 2 or Resident Evil 3 are being played. At the time, we said we were ~99% sure that the GameCube's DMA timings wouldn't become instant when playing Resident Evil 2 or 3, and now we are 100% sure.
The last known full GameCube "game" that wasn't reaching gameplay in Dolphin after Dynamic BATs was Army Men: Sarge's War. When doing more research into why Army Men was broken, phire realized it was hitting the ARAM-DMA hack that was designed to fix Resident Evil 2 and 3.
See, the ARAM-DMA hack wasn't just activating in Resident Evil 2 and 3. Instead, Dolphin looked for cases where L1/L2 cache invalidation was happening during a Direct Memory Access transfer. When this happened, Dolphin went into instant ARAM-DMA mode to try and curb any issues caused not emulating the L1/L2 CPU cache.
In the cases of Resident Evil 2 and 3, they use their own custom streaming audio setup. Developers currently disagree with what is actually going wrong at the current state; but, L1/L2 cache emulation is likely needed for things to work properly.
The music never correctly loads in areas with two "music" tracks.
Instead of leaving a big ARAM-DMA hack just for Resident Evil 2 and 3, we decided to break the music in the games and remove the hack altogether. The games are still fully playable, but areas with multiple music tracks will have issues with the music cutting in and out as they constantly fight to play each area. Often, ambience and other reoccuring sound effects are used as a second "music" track, so don't be surprised if the music is missing in a lot of areas.
This change fixes Army Men: Sarge's War and likely other games inadvertently activating the ARAM-DMA hack.
Before anyone asks, yes, Dolphin could have activated the hack only for Resident Evil 2 and 3. The reason that was not done was because we really want to fix this properly. So many times in the past, a developer has left a hack in Dolphin that has come back to cause issues when accuracy is increased. Sarge's War is just one of those casualties, but there have actually been dozens of titles broken by assumptions made by old hacks; some of which extended the feature freeze before 5.0 by quite some time as regressions from finally removing them were sorted out.
We will fix Resident Evil 2 and 3 eventually, and this time it won't be with a hack.
This one fixes one of our favorite bugs in all of Dolphin. There's a bug in Fishing Resort, where the player pulls out the map, but, for some reason, the map is actually upside down. Among developers, we've joked quite a bit about the character being an idiot and simply holding the map upside down!
Yet, we knew there was a real issue, and a lot of attempts to fix it have already failed. Finally, Armada pulled off the seemingly impossible when looking at ornox's Texture Coordinates Q == 0 fix featured in last month's Progress Report. He realized there were other cases where texture coordinates weren't being divided by q.
Also this fixes Find Mii's dark stages, but, that's not nearly as amusing.
Ahh that's better. Note: this was discovered by fifoci, hence the missing faces. Fifologs don't record EFB Copies generated before the fifolog.
Note: An earlier version of this entry referenced a different change. The writer responsible has been flogged.
Well, it's been a while. Dolphin Android hasn't been seeing many unique updates since outside of a few components, it's internally the same thing as the PC versions. But SeannyM has stepped up to the plate and has committed a ton of fixes for Android! These are all well needed fixes, so let's ignore the specific commits and just go through the fixes one at a time.
Scale buttons based on screen dimension¶
Dolphin now scales the on-screen buttons based on your screen dimensions. This helps smaller phones and of course, portrait mode!
Improved Button Scaling¶
This little change scales all of the buttons relative to each other based on real world measurements. There are some differences from world sizes here and there for usability, but it makes the on-screen controls much more familiar.
C-Stick and Dpad Support¶
Dolphin now has on-screen controls for the GameCube Dpad and C-stick! You can finally spam downsmash as Peach in Melee and then taunt after yet another kill!
Android: fix save and load state menus on non-TV devices¶
This fix restores a very important bit of functionality that is especially important for mobile users - the ability to save and load savestates on demand. Previously, the save and load state menus would try to load the Android TV UI fragments regardless of the device it was currently running on. On non-Android TV devices, such as phones, this resulted in a crash because the layout doesn't exist on that device. With this addressed, manually saving and loading savestates works properly once again!
Toggleable buttons UI¶
Next up, there is now a configuration menu that allows you to toggle on-screen buttons as you please. This very simple change makes it simpler to use what you need for a game; for much cleaner, easier to use on-screen controls.
Wait wait, those weren't GameCube controls in the toggle menu!
Wiimote on-screen buttons¶
That's right, Dolphin on Android now has Wiimote touch controls! For the first time you can control a Wii game with nothing but your screen. It's still limited though, as only the Wiimote and Nunchuk are available, and there are no motion controls or pointer, but this is a big step toward Android compatibility for on-screen users.
With all of these changes, on-screen controls for Android have taken a huge leap forward! However, there are still considerable issues left. The buttons do not indicate when they are pressed, joysticks do not slide about in their range, the classic controller pro has not been implemented, and motion controls will be a nightmare.
But thanks to SeannyM, we're slowly moving toward a complete touch control interface.
OpenGL cannot emulate Kirby's Return to Dream Land's shadows without this hack. For quite a while Dolphin has been attempting to move on from the two pass method it uses when dual-source blending is not supported, and things were getting close with most graphics cards now supporting it as a basic feature.
Destination alpha is emulated by writing two colors from the fragment shader. The first contains the alpha value that is written to the framebuffer, and the second contains the value passed into the blending equation to determine the final color of the pixel. Unfortunately logical operations cannot be combined with blending, and cannot be applied on a per-channel basis, meaning that the two-pass fallback was needed to write the constant alpha value to the framebuffer.
The only known case where this causes an issue is Kirby's Return to Dream Land. This is far from a perfect solution, due to it not being accurate in all cases, but it does make Kirby's shadow only appear on the ground as expected.
Why did we finally cave and add the hack? Vulkan, D3D12 and Metal, the three new APIs, all lack the functionality Dolphin needs. So, instead of waiting any longer, stenzek implemented the hack and degasus approved it. After realizing help was not on the way, it was either leave it broken forever or implement a hackfix.
For those of you on D3D11/12... this fix isn't coming your way. Now, you probably are thinking, "Hey, Kirby's Return to Dreamland's shadows already works on D3D," and you'd be correct. It does work. The output of the broken implementation there lines up with what appears on console. On the other hand, lack of LogicOp support altogether does cause other issues. The most well known example is F-Zero GX in Story Mission 2.
With D3D12, there is the possibility of supporting F-Zero GX's boulder shadows in the future. On the other hand, D3D11 completely lacks any functionality toward it.
Stenzek implemented a backend that uses some weird graphics API a few people seem to like. There's actually a lot to say, but this got merged the night of the progress report (literally two hours before October 1st.) So in honor of the devs who have absolutely no regard for the blog staff, prepare for the ultimate technique for blog article writing: winging it.
Vulkan for AMD Users¶
The biggest news for us with Vulkan is that they will finally bring AMD graphics cards up to speed on a non-D3D backend. Linux users with AMD graphics have had it pretty rough in Dolphin, seeing much, much worse performance compared to similar hardware from other vendors. Vulkan finally levels the playing field, giving absolutely huge boosts to AMD users. AMD users on Linux can finally celebrate reasonable performance! Once Vulkan is feature complete, there won't be much purpose for AMD graphics users to ever go back to OpenGL in Dolphin.
With an AMD APU, Vulkan shows that it can stand toe to toe with D3D11/12 in performance. This means our Linux AMD GPU users... well, before this point there was no point in trying Dolphin on that configuration. Now those users can get comparable performance to D3D11/12 on Windows without having to install Windows. Unfortunately for our Mac OS users, to our best knowledge they do not plan to support Vulkan.
Vulkan for NVIDIA Users¶
NVIDIA users have the opposite problem. The OpenGL drivers are so fast that it's fairly difficult to find games that perform all that differently inVulkan than OpenGL. Twilight Princess is one of those exceptions. Much like D3D12, Vulkan greatly outperforms D3D11 and OpenGL when taking away the Twilight Princess speedhack provided by the emulator.
NVIDIA users really have no reason to use Vulkan outside of the few rare cases where its efficiency really shines. Once it's feature complete and has some optimizations, this can change very fast.
Note: NVIDIA's drivers are broken on Vulkan for Dualsource Blend. Dolphin uses this quite a bit, so, if you're planning on using the Vulkan backend on your NVIDIA cards, you'll need 368.81 or older on Windows or 367.44 or older on Linux. We'll plan on sending in some test cases so the drivers can be fixed. Again, OpenGL performs fairly similar for these users, so it shouldn't be considered too urgent. EDIT: This issue was fixed by 375.63.
Vulkan on Android¶
Mobile users have been itching for Vulkan to give sweet sweet performance gains! Yeah, not happening yet. Mali crashes immediately on start, and it doesn't give any reason why. Adreno at least renders something, but it's completely wrong even on many test programs and Dolphin isn't close to playable. We haven't tested all the other mobile drivers yet, but so far it appears they have similar problems.
On Android, Vulkan driver support just isn't ready yet.
Vulkan on Intel using Mesa¶
For right now, Vulkan is slower than OpenGL on Intel Mesa due to several hardware features being left unimplemented. This should change in the near future as it's brought closer to completion.
General Information about Vulkan Support¶
Vulkan support is finally here! So, what does it mean? Well, both Vulkan and D3D12's greatest strengths simply don't apply to most emulators. That means that we aren't going to see world changing performance boosts simply by implementing the API. Instead, we'll be looking at various optimizations that use Vulkan's unique abilities to help emulate games with quirks that are particularly demanding. Where Vulkan does shine, it really is great. Being able to play Twilight Princess without a specialized speedhack is a result of the newer APIs simply being more efficient, and there will likely be more cases where we can gain added accuracy without a cost to speed.
But, that will come with time.
On that note, while the Vulkan backend is very stable, it's not quite complete. The most notable missing feature is External FrameBuffer (XFB) support, which is because we're currently in the process of rewriting support. It felt a bit wasteful to greatly complicate the Vulkan backend for something that was going to get renovated soon anyway. Also, Vulkan lacking XFB support just means we can bug the developer behind it (phire) to work harder because our AMD Linux users are suffering greatly while he does things that aren't HybridXFB. The other missing feature is actually missing from Vulkan altogether: exclusive fullscreen. We're hopeful that extensions in the near future will rectify that, but, it's something to keep in mind for now.
Unlike D3D12, we don't consider Vulkan to be quite as "experimental." It shouldn't randomly crash, it doesn't have any egregious hacks in the backend, and we have stenzek here to maintain it. There may still be occassional bugs, and, do remember titles that require XFB will not work for now. Other than that, have fun with it and see how it stacks up with our other backends. It should be a solid alternative to D3D12 for AMD users, and definitely has the potential to go further than OpenGL longterm!
If you find any issues with the Vulkan Backend, please report them, we currently have a developer actively working on it so it's likely there will be a quick turn-around on issues!