When an open source project is really working, things can move frighteningly fast. One developer can focus on a feature while others are reviewing the code and preparing it for merge, allowing things to move forward in a very streamlined fashion. This not only gets things done faster, but each coder can specialize in what they do best, producing the best possible product for the user base.
When things come together just right, months like this can happen. The June Progress Report is a massive monument to months of hard work put together by not one, but all of the people contributing to the project.
Usually we don't feature GameINI updates in the Progress Report. These are small, silent updates that don't really feature any core change to the emulator. However they serve an important purpose: they override troublesome settings. GameINIs are an integral feature for the basic users of Dolphin who do not want to mess with settings just to get a game playing properly.
This INI update is slightly different, mostly due to the controversy around the removal of the hard-coded Twilight Princess Hack from Dolphin. Known to users as the ZTP Hack on the game properties page, that hack called deep into Dolphin's codebase into ugly game specific code. The hack itself skipped certain drawing commands for the minimap in order to greatly speed up the game.
The removal was done unceremoniously as a cleanup measure. A few builds later, changes to the code would have made the hack no longer work anyway, but fans of the game were left with a far inferior experience.
Realizing that this was an unacceptable price for the users to pay, Kiesel began developing cheat code that would NOP (Null OPeration) out the troublesome minimap drawing calls without needing game specific code in the emulator. skid_au then converted that code into a patch that could be inserted into a GameINI and degasus optimized it with even more NOPs. Not only does this work, it actually outperforms the old Twilight Princess Hack in head to head comparisons!
Everyone will be happy with how things turned out. The code base doesn't have a nasty hard-coded hack in it, and users can still use the Twilight Princess Hack to get faster speeds within the game, even faster than with the old hack!
It should be noted that there currently aren't codes for all Wii revisions or the Japanese versions (GC and Wii) of the game. It's as simple as finding the necessary offset, and should be possible for someone who owns those revisions of the game to make. When they are available, they will definitely be added to the GameINIs.
The removal of OpenGL's Vertex Streaming Hack was not supposed to cause any performance regressions on NVIDIA cards that supported Buffer Storage. After rigorous testing, it was determined that there was no performance regression and merged in the code to rid us of the horrible hack.
Unfortunately, the Geforce 400 and 500 series cards saw a huge drop in performance, and due to a coverage gap in GPUs that none of the developers noticed. But thanks to research and persistence by our forum users, the issue was brought to the developers attention and tracked down. Losing the Vertex Streaming Hack caused a 30% performance drop on NVIDIA 400 and 500 series cards. Apparently Coherent Mapping, an OpenGL extension designed to sync GPU caches and CPU memory, was at fault. It shouldn't have caused any slowdowns, and no one knows why it was only affecting those video cards. Luckily, it wasn't needed anyway (as neobrain pointed out from day one) and could be removed without any regressions. As of this build, performance will be restored on those video cards.
Fixed issue 7348
The user interface is something most users see every single time they use Dolphin, yet for years, all we had was Boomy - a theme so generic the wiimote was represented by a guy in a pink shirt. In 4.0 there was an effort to modernize Dolphin's interface, resulting in a new logo and a new default theme: Clean. However, so much of the focus was put on the logo that the Clean Theme ended up being rushed. This update rectifies a few problems and design quirks that arose, especially in the alternate color schemes.
Memory Card files are a staple of 5th and 6th gen console emulation. Making a small disk image file that acts as a virtual Memory Card is the obvious solution for emulating such a device. However, delroth thought that perhaps it could be done better. Enter LPFaint99, who had already been thinking about such a system, but doubted it would garner any interest. With interest obviously expressed, LPFaint99 began work on a new system that would be more robust and simpler for users to interact with.
The end result is a way to use folders as the Memory Cards that simply hold raw GameCube Saves (.gci and .sav files) within them, allowing direct user interaction without needing a Memory Card Manager. This fixes several potential issues as well, including the fact that Memory Cards could break when deleting save files from them.
Some people may think this would be pretty simple, but there were a lot of hurdles to clear. Namely, the GameCube needs to check how full the Memory Card is, and can check multiple save files at once. Also adding to the degree of difficulty were games like Metal Gear Solid: The Twin Snakes and Super Smash Bros. Melee which could check for saves from other games to unlock special features.
If all this wasn't enough, the new functionality also allows save files to be saved within savestates. Users may have noticed that in older versions of Dolphin, particularly with The Legend of Zelda: The Wind Waker, using savestates could cause the in-game save feature to malfunction. By adding savefiles to the savestate, that issue will no longer occur.
Fixed issue 6599
We avoid combining commits in a Progress Report because these changes deserve their own spotlight, but what happens when one commit is completely reliant on another? E-ticket Service Launch (ES_Launch) completely relies upon Interprocess Communication (IPC) HLE event handling to work properly. Only when IPC HLE event handling was fixed could ES_Launch be completed.
Starting off with the groundwork, IPC is a very, very delicate thing to handle. This functionality is responsible for the Wii operating system, bluetooth communication (including the Wiimotes), booting games and more. If emulation isn't done done impeccably, things can break in spectacular fashion, as the developers relearned the last time they messed with it around 3.5. The IPC HLE timing changes made for ES_Launch support ended up breaking the usage of Wiimotes in several games and had to be reverted. Developers had to make a choice between support for four Wiimotes and the ability to launch channels from the Wii System Menu. Wiimotes won.
So, what does IPC-HLE timings being improved mean for the emulator? Primarily, there will be less problems when multiple processes are communicating, usually when a game or application is booting. ES_Launch is another service for booting games with specialized parameters.
Most users probably don't notice any problems with booting games except in a few rare cases. That's mostly thanks to the amazing job done by skid_au that helped tons of popular games reach a playable state during initial support of ES_Launch.
If much of the work was done, what does full ES_Launch and improved IPC-HLE Event handling allow the emulator to do?
For the first time in Dolphin, the system menu is fully functional! The IPC-HLE improvements allow users to launch Virtual Console games, App Channels, and Wiiware titles. The additional ES_Launch changes brings even more functionality to the System Menu by finally getting the Disc Channel itself working!
Full ES_Launch also affects several multi-title Wii games, such as Metroid Prime Trilogy and House of the Dead 2 & 3 Return. Those games were severely hampered by problems: difficulties, modes and even games from within the titles completely inaccessible thanks to incomplete ES_Launch support.
Unfortunately, this does not support booting GameCube games from the Wii System Menu. This is because of how difficult it would be to emulate the Wii switching into GameCube mode. For those wishing for a more authentic GameCube experience, Dolphin can run a dumped GCN Bios and you can toy around with that and boot games from there.
Though not an issue with Dolphin particularly, users with emulated Wiimotes will have to reconnect them after some ES_Launch boots, just like the actual Wii. Unlike real hardware, hitting buttons on an emulated Wiimote does not get it to reconnect; you must manually hit the shortcuts to reconnect the disconnected Wiimotes. Users of real Wiimotes will not have to worry about this problem thanks to continuous scanning.
A lot of the rewrites and cleanups this month didn't affect anything for users directly. That cannot be said about the Disc TracK (DTK) Audio rewrite. With this merge, the last remnants of asynchronous audio are finally put to rest. While not all users may not be supportive of synchronous audio, even they can't defend game reset bugs and completely out of sync cutscenes caused by the old method of emulation.
While this rewrite repairs a majority of the DTK Audio bugs, it does not address issues unrelated to the asynchronous audio processing used by the old method. A partial list of DTK audio games can be found here for those curious of some of the games affected.
One final note is that the OpenAL audio backend previously used its own method of time-stretching DTK audio prior to this merge. It is unaffected by the changes, and will still work as normal.
Any time there is a visual regression between the console and emulator, people notice. For a long while, vertical sync (vsync) hasn't been working at all in OpenGL on Windows, at least under the default settings. This has led to the unfortunate side effect of turbo not working properly and an abundance of screen tearing in OpenGL. While some crafty users have been going and editing driver settings with spotty results, Anti-Ultimate decided to attack the heart of the matter.
The problem? Dolphin was getting a function pointer in ClearCurrent (which Dolphin only calls at shutdown) instead of MakeCurrent (which Dolphin calls upon initialization).
Fixed issue 6964
Behind the Scenes: Dolphin and the NVIDIA Tegra K1 Jetson¶
As many people know, Sonicadvance1 has been working on the Android port of Dolphin as his main project. The initial reaction was that ARM processors weren't powerful enough, that Android wouldn't work, the graphics drivers weren't there, etc. And those reactions were right... but not for much longer.
The Tegra K1 Jetson is the first consumer ARM device to provide full OpenGL 4.4 support coupled with reliable drivers. For the first time a game is completely full speed on ARM, and many others are getting frighteningly close.
But there is a new chipset on the horizon that is even more intriquing: the Tegra K1 Denver SuperCore. Though it cuts out two cores, the remaining cores are clocked higher and boast a 64-bit architecture, all good things for Dolphin. If early benchmarks are any indication, it could boost performance in Dolphin by up to 100% versus the Tegra K1 Jetson!
For more videos of Dolphin on the Tegra K1, please check out Sonicadvance1's Youtube Channel
Issue Tracker Gold¶
"Oh boy, I got this amazing new time on Mario Kart Wii, I'm going to transfer it to Dolphin and render it in HD!"
Dolphin's ability to render GameCube and Wii games at higher resolutions is considered one of its greatest features. But what if your greatest moments from Super Smash Bros. Brawl or Mario Kart Wii could be transferred into Dolphin and rendered in glorious High Definition? People have tried exactly that and discovered Dolphin doesn't like to play replays recorded on console.
This has been an issue in Dolphin since day one; it has never been able to sync replays recorded on certain GameCube and Wii titles. Up until a few weeks ago there were no leads; the only thing to do was make the CPU more accurate and hope that something, anything affected it.
Yet, somehow things have a way of working out. In this case, despite having analyzed hundreds of replays already, a tester stumbled upon one that reacted differently between JIT and JITIL. To make things even more interesting, this difference only turned up after 4.0-1706 meaning that just six weeks ago, this analysis would have been wasted energy. Thanks to impeccable timing and luck, we finally had our lead.