After some minor delays, Dolphin's new issue tracker is up and running, with all of the old issues preserved and imported. It hasn't taken long for things to heat up on our new tracker despite trying to keep it on the down low while it was being tweaked. A mixture of delays with the issue tracker and new bugs in our stable branch cropping up has pushed back the Dolphin 5.0 release out of September. When will it be released? Well, it all depends on when all critical bugs and regressions are stomped out of the stable branch. In order to prevent a fiasco, it's better to report these regressions now rather than after release. No one wants another 4.0.1 and 4.0.2 situation on their hands.

As the release candidates drag on, we've noticed that many users are assuming that 5.0 release candidate builds are newer than development builds. Please remember, the 5.0 release candidates are based on 4.0-6727, and only have bug fixes applied beyond that. Almost all of the new features from July's progress report onward ARE NOT in the stable branch unless they are a regression fix. For new features, the development builds are still recommended. Speaking of the newest features...

Notable Changes¶

4.0-7517 - Derive Field Timings from Video Interface Registers by booto¶

This is one of those changes where it's not correct to ask what it fixes but rather what it implements. This change wasn't made to fix anything; in fact, booto originally called this change "vaporware" as it wasn't expected to do anything and would be quickly forgotten. Unfortunately, booto underestimated just how hacked together some parts of Dolphin were and this supposedly fruitless change fixed a lot of problems.

Field timings are, at its most basic level, the timings in which graphics are output to the monitor/television. These timings vary between the NTSC and PAL versions of interlaced, progressive, and double-strike outputs. Previously, Dolphin hardcoded values for each of these outputs.
With this change, Dolphin now gets these timings from values the game configures in Video Interface registers. As many testers expected, this change in behavior actually fixes quite a few bugs!

Metroid Prime 2/3/Trilogy Black Bar

The Metroid Prime games are some of the most susceptible titles to shader compilation stuttering. Basically, the GC and Wii have no concept of shaders - everything runs directly "on the metal" without any APIs. Modern desktop and phone systems do not work in this way, requiring the use of shaders as an intermediary so your system's GPU can perform the tasks that the GC and Wii GPU performed. But shaders have to be created, and since GC/Wii games are not designed to create shaders ahead of time as a PC game would, when a new effect appears Dolphin has to delay the CPU thread while the GPU thread performs the compilation; a pause that does not exist on the consoles. For most games shader generation takes only a few milliseconds, but for the Metroid Prime series and a few other demanding titles, the shaders that they generate are so large that they can result in noticeable stuttering. In the case of Metroid Prime 3 in particular, stutters of over a second can occur! This sudden stop for this long of a time can desync the CPU and GPU threads. With Metroid Prime 2, 3, and Trilogy, this leads to cascading timing problems which breaks rendering, causing an inaccurate aspect ratio and the appearance of the dreaded "black bar" along the bottom of the screen. But now, with booto's more accurate field timing emulation, Virtual XFB or Real XFB can be used to not only prevent, but also fix the black bar, allowing these games to be used in Dual Core mode without this serious graphical issue.

The black bar consumed 15% of the game's vertical pixels. At times in Dolphin's history it was nearly impossible to avoid

Now with Virtual or Real XFB, this problem can be avoided entirely

PAL NES Virtual Console Audio

One of the most peculiar issues with Dolphin's Virtual Console emulation finally comes to an end. We know what you're thinking: but this is a video change! It turns out that field timings are pretty important to get right. The explanation for this one is simple, each NTSC frame takes 16.666ms per field, where as each field takes 20ms on PAL50. If, for some reason, the game is expecting the timings to be slightly quicker (Dolphin giving the game NTSC timings, for instance), it leaves a gap of 3.333ms of deadness per frame. It seems to accumulate for the first 50 frames of a second before the game becomes totally silent for the next 10 frames. This behavior isn't entirely understood, but, at least it can be filed away as a fixed bug.

Wind Waker PAL50 hang

AdmiralCurtiss' changes allowed Wind Waker PAL to play in PAL60 mode. That allowed users to work-around a hang that occurred while going into new game plus. With this change hitting the emulator, the hang is actually truly fixed, with no work-around necessary.

SNES/Megadrive/Neogeo Virtual Console Framerate Issues

These games seemed to run at the incorrect framerate. Previously, overclocking the emulated CPU would alleviate the issue, making developers think that our emulated CPU was too slow for these titles (which, is true in some cases.) However, the issue was actually a symptom of incorrect field timing; by correcting it to be more accurate, the games no longer struggle at the default emulated CPU clockrate.

Various aspect ratio problems

Some games had weirdly incorrect aspect ratios in Dolphin, especially with the PAL versions. booto's changes fix a lot of the random issues where the aspect ratio is wrong with the PAL version of a game, but fine on the NTSC version. This affects a lot of PAL50 games, such as Hydroventure (Fluidity in other territories.)

Much like Metroid Prime's bug, the game used to be squished, except this wasn't triggered by a Dual Core desync

The game isn't squished so badly any more when using Virtual or Real XFB

This is the joy of a pure accuracy change; so many difficult to debug problems can be fixed without even knowing about it. But, there is another side of the coin. Even assuming booto's changes are 100% correct, there can be other parts of the emulator that rely on the old, broken behavior. There were some serious regressions after this was merged!

For something that fixes so many Virtual Console issues, it actually brought out a lot of problems at first, too. It turns out most Virtual Console games would hang on startup without further changes. Unfortunately, those changes actually caused some PAL games to hang, meaning it wasn't included with the final pull request. Why were these virtual console titles hanging...? It turned out to be HLE audio specific! LLE audio was fine. Regardless, booto debugged the issue and found a solution to make HLE audio act more like LLE audio with some timings. HLE audio strikes again.

Endless Ocean and Endless Ocean: Blue World had a hanging issue as well, but, their problem wasn't related to the Virtual Console hangs. It turns out the vertical beam emulation just wasn't accurate enough yet, causing the games to hang. First, booto did a quick fix up which obliterated those hangs, but then Mario Kart: Double Dash!!(PAL) and Metroid Prime started having FMV issues! This forced booto to write some homebrew to figure out exactly what the GameCube/Wii was actually doing. After examining those results, booto came up with a solution that seems to work in all cases. In fact, Metroid Prime's menu video seems to line up with main menu actions better than ever before!

Sonic Mega Collection Flickering¶

There's one regression that we decided was worth allowing into the emulator in order to get the huge accuracy and compatibility bonuses elsewhere. Sonic Mega Collection flickers now regardless of your settings. Without XFB, the game reports 60 VIs per 120 frames! This is obviously wrong, but it does clue us in a bit to what's going on. Nearly 8 years ago, there was a hack merged into Dolphin for this exact situation. The hack deflickered this game, by presumably dropping half the frames, and no one had any more complaints. But, because Dolphin is now accurately doing things the old hack was removed and no longer works. Sonic Mega Collection flickers once more. Considering Dolphin's higher code quality requirements in comparison to the past, a modern version of the hack will not be accepted. This time around, the only way to kill the bug will be to actually fix the issue. Currently, there are no leads on a real solution.

4.0-7538 - Move to Visual Studio 2015 by shuffle2¶

This is a bit of a bitter sweet change for us among the Dolphin Team. Upgrading to a new compiler means a wave of old Windows hacks and work-arounds can be removed as Microsoft catches up to the standards used by other compilers. The bad news is that Windows Vista users now require Service Pack 2, and Windows 7 users need Service Pack 1; but that shouldn't be too much trouble as long as you don't have dial-up.

But, other than making our code a lot cleaner, VS2015 executables end up being quite a bit faster! The gamelist tends to load faster, and a bunch of games are running over 5% faster than before. That's a pretty noticeable chunk for a compiler change! Users looking to get the most out of their computers should download the VS2015 runtime and try out the latest builds if they haven't already.

But not all is good with the changeover. The VS2015 libraries have some nasty bugs that seem to be afflicting Dolphin. Users having issues with crashing in The Legend of Zelda: The Wind Waker and Spongebob Squarepants Battle for Bikini Bottom are recommended to use Dolphin's compress ISO functionality to avoid hangs in those games for now. The process is lossless (for GC games only! Wii games will not uncompress to the same MD5) and will work around the known issues in those two games without any side-effects. Microsoft already has a fix for the bug in progress; when it is released we'll post a message on our twitter with instructions.

One other little side effect is that Dolphin can no longer integrate the runtime files, simply because VS2015 has too many and are far too large to reasonably integrate. To continue using development builds, Windows users will have to download the 64-bit Visual C++ redistributable for Visual Studio 2015. The 5.0 release candidates and the future 5.0 release, being based on 4.0-6727 which was well before this change, will not require any runtime files.

Anti-Aliasing Improvements¶

• 4.0-7578 - Properly support MSAA and SSAA as separate features(+GLES) by Sonicadvance1¶

• 4.0-7622 - VideoBackends: Reimplement SSAA, now for D3D + OGL by degasus¶

• 4.0-7818 - Improved OGL and D3D's AA options in UI by Helios747¶

Anti-aliasing in Dolphin has always been less than optimal. OpenGL had 2x-8x MSAA (Multi-Sample Anti-Aliasing) and 4x SSAA (Super Sample Anti-Aliasing), as totally arbitrary but at least easy to understand options. D3D, on the other hand, displayed whatever the driver would give it, resulting in a nightmarish amount of obfuscated options that no one could understand, all while not having SSAA whatsoever.

No one actually knew how to bring SSAA to D3D11 for years, and when it was finally discovered, the needed GUI changes and the disparity between OGL and D3D the changes would create discouraged developers. But degasus and Sonicadvance1 realized that the new system of anti-aliasing in OpenGL 4, which Dolphin has used since the GLSL rewrite, works exactly the same way as the D3D system. By moving to it, Dolphin would have cleaner code and SSAA could finally be brought to D3D at last!

8xMSAA: Pit's feathers are texture elements which MSAA cannot anti-alias

8x SSAA: SSAA is able to correct all aliasing, no matter the source

Unfortunately, after these changes there were still some UI problems: D3D still showed a crazy amount of options, the SSAA checkbox was located far away from the dropdown, and the MSAA text in the dropdown never changed. These things combined to confuse users. Enter Helios747, who stepped up to push his way through the tide of bikeshedding to address these user problems! Even more work is planned - the intention is that the MSAA and SSAA options will be placed into the dropdown together without a checkbox, so the options are even more intuitive. Stay tuned!

Much better!

4.0-7630 - Store EFB Copies to Texture Improvements by phire¶

Store EFB Copies to Texture Only is a necessary evil for developers and users alike. It is perhaps the biggest performance hack in Dolphin, but often times it comes with severe consequences in games. EFB Copies Stored to texture suffer from avoidable bugs such as Wind Waker's Pictograph functionality breaking to showstoppers like Super Mario Sunshine not being able to tell you're clearing the paint. Yet, without the Store EFB Copies to Texture codepath, we would not be able to up the resolution of many special effects; anything that goes through the EFB Copies to RAM codepath is stuck to 1x internal resolution.

Store EFB Copies to Texture Only is one of the few hacks in Dolphin that are likely here to stay. As such, even though it's technically a hack, everyone wants to make it be as accurate and compatible as possible with as many situations as it can be. One of the bigger differences was that when using EFB Copies to Texture Only is that Dolphin didn't pay attention to what was being written to RAM, as it couldn't write the correct data anyway. This caused bugs when games overwrote (and thus invalidated) parts of the memory. When using EFB Copies to RAM, Dolphin kept track of everything, and thus when something was partially overwritten, it was handled and updated.

With phire's change, EFB Copies to Texture now hashes the RAM and is able to detect when it is changed. This allows it to invalidate and handle those situations correctly, making it nearly identical to the EFB Copies to RAM codepath. The big difference is that EFB Copies to Texture cannot write the correct data to RAM. This won't fix issues like Wind Waker or Super Mario Sunshine where that data must be correct, but it will fix a lot of weird issues that didn't seem to have any rhyme or reason.

• Texture Override: Games have been doing this for a very long time. When using EFB Copies to Texture Only, a game could overwrite an EFB Copy with a texture and Dolphin wouldn't be able to tell. This would cause really weird glitches, such as textures completely messed up in Super Smash Bros. Brawl, or walls covered by renders of Samus in Metroid Prime. In one hilarious instance on Twitch Plays Pokemon Battle Revolution, fire effects were simply replaced with the word "fire."

Randomly as you played Metroid Prime, some textures would be replaced with EFB Copies of Samus

The actual texture is now shown correctly

• Immediately Inflated GPU RAM Usage: People wanting to play classic N64 Virtual Console games like Super Smash Bros. and Mario Tennis may have noticed a slight issue. Namely, it brought their computer to its knees. This was because GPU RAM was getting smashed by out of control EFB Copies! Turning on EFB Copies to RAM would fix the issue, so, unsurprisingly, making EFB Copies to Texture invalidate things much more like EFB Copies to RAM fixes the issue.

• The Last Story Clothing: Users are going to see this as a negative, while developers are going to see this as a positive. Prior to this change, players of The Last Story would be able to flip off Store EFB Copies to Texture for one frame, then turn it back on in order to give all the clothing of characters in The Last Story their proper texture. That no longer works, as this relied on the previous behavior of Dolphin not paying attention to the contents of the RAM. This undoubtedly increases the system requirements for what is already one of the most demanding games in Dolphin.

4.0-7664 - Perform garbage collection for EFB Copies no longer in use by mimimi¶

More revamping to how EFB Copies are handled. Shortly after Dolphin 3.5 was released, the behavior of Store EFB Copies to Texture Only changed after testers discovered a simple solution that fixed long-standing F-Zero GX and Mii Face issues. Namely, Dolphin automatically culled saved EFB Copies after they weren't used for so long in order to prevent memory leaks. In Store EFB Copies to RAM, this wasn't a big deal as whenever the game used the textures again, the data still existed in the GameCube/Wii RAM and could be recreated (with the unfortunately limitation of 1x IR, as it's now forced upon the accuracy path). In EFB Copies to Texture, they were more or less gone forever. F-Zero GX would generate the shadows for all the ships well before the race, so by the time the races actually started, all you'd get was a bunch of garbage under the ships!

Before 3.5-427, using EFB to Texture resulted in shadows like this

Back then, the only solution was EFB to Ram, which made F-Zero GX obscenely taxing

By making Dolphin store these textures indefinitely, though, GPU RAM usage could go through the roof. A few hours in a game like Pokemon XD could max out your ram altogether! Fixing this problem in Store EFB Copies to RAM was more or less trivial as it hashed the RAM; Dolphin could tell what's been overridden and what hasn't through hashed data. mimimi originally made a fix using that assumption, but seeing that phire's Store EFB Copies to Texture improvements brought hashing to that, mimimi waited for that to be merged. By checking the hashes of EFB Copies in the cache and making sure they match that of the GameCube/Wii memory, Dolphin can tell whether it's safe for an EFB Copy to be deleted or if it must be kept for one of those unusual cases where they'll be pulled up later.

Thanks to their patience, Store EFB Copies to Texture and Store EFB Copies to RAM both no longer leak GPU memory without the old bugs of yesteryear returning to the emulator. Finally, users can safely venture into the world of Pokemon XD without having to take a break every few hours to refresh their RAM usage.

4.0-7698 - Fix "WriteRest Op Out of Range" warning by flacs¶

Dolphin has been running into a very strange error as of recent. Since adding the Vertex Loader JIT, users have been reporting Dolphin throwing a WriteRest Op Out of Range warning at certain users. Here's Sonicadvance1 explaining it.

The x86_64 CPU recompilers allocate all of their memory space at initialization, with the hint to the OS that we want the code to end up in the lower 32bits (<4GB) of memory space. This nearly always passes because there is typically nothing else in that memory space at initialization. We specifically ask the OS to allocate memory in the lower 32bit space so we can use x86_64's RIP addressing, which can only address memory space within a 4GB memory space of itself, and having Position Independent Code (PIC) would have our executable data and recompiler data potentially end up in completely random locations due to ASLR.

When the x86_64 vertex loader JIT compiler was added, it used the same generic code [as the CPU recompilers] to allocate memory, but it allocates memory each time a new vertex loader needs to be generated. After so long of us running a game and allocating large amounts of unrelated memory space, we will have exhausted all the memory in the lower 32bit memory space. So when the vertex loader attempts to allocate its small bit of memory, it would eventually end up outside of that 32bit memory space. Since the vertex loader supports PIC this wasn't actually an issue, but since it was using the same common code, it resulted in a warning message popping up.

Basically, because of the common memory code shared between them, the vertex loader thought it was limited to the lower 32bit memory space like the x86_64 recompilers, even though it can operate fine outside of it. And if that memory space was full and it had to run elsewhere, it would freak out irregardless of the fact that it was operating perfectly. Dolphin was throwing up the warning for absolutely no reason at all. The solution to this long standing issue was to literally disable the popup from happening for the Vertex Loader JIT code.

The Dolphin Emulator Foundation¶

The Dolphin Project has grown enormously over the years. To ensure that the project continues to reflect the goals of an open source community as it grows, the developers have decided to start a foundation. As such, upon September 29th, 2015, The Dolphin Emulator Foundation was founded in the Netherlands (officially known as Stichting Dolphin Emulator. Stichting means Foundation in Dutch.) It will be run by the developers as a non-profit with the goal of preserving games and hardware long after the hardware to run them is gone. The foundation will provide the legal status and financial support to ensure the project can continue to achieve its goal in the ever-changing open source landscape.

The foundation itself won't change anything in how the project is being run, Dolphin will remain the same open-source community it has always been. The foundation will only serve to provide all the services necessary to support the project as it's grown far bigger than anyone could have imagined twelve years ago!

Last Month's Contributors...¶

Special thanks to all of the contributors that incremented Dolphin from 4.0-7506 through to 4.0-7873!

Update: This article originally said the VS2015 compiler change would drop Windows Vista support. This was incorrect. Windows Vista SP2 should still run Dolphin properly.