We have celebrated the 15th anniversary of the GameCube and the 10th anniversary of the Wii in the last few months. As the Wii's successor, and the brand lineage, has been discontinued in the run-up to the release of the Switch, it is a time for reflection. But, this doesn't mean an end for the GameCube and Wii; if anything, it's a new beginning.

This is when emulation and preservation becomes even more important. How many titles in previous generations would have been lost or forgotten if not for emulation? How many of your favorite games were first experienced in an emulator? With Nintendo's NES Classic and Virtual Console lines, it's very likely that the next generation of gamers are going to be more aware of emulation than ever. Favorite games and experiences are not only going to be passed from friend to friend, but across generations. And we here are going to do our best to make sure that not only are those popular games awaiting, but the entire library of highs and lows, knowns and unknowns.

On the note of software that most people probably haven't experienced, we decided to take a look at one of Nintendo's more interesting pack-in titles, The Legend of Zelda: Collector's Edition. Featuring emulation software for both the NES and N64 Zelda games (With A Link to the Past omitted only because they were trying to sell the Game Boy Player,) and a demo of Wind Waker, it's one of the more sought after GameCube games.

With all of that out of the way, we hope you enjoy this month's notable changes!

Notable Changes¶

5.0-1451 - Very Slightly Better UI for GameCube Microphone by aldelaro5¶

This one is fairly important to those who want to use GameCube Microphone emulation alongside Native GameCube Controller Support. It's also important to anyone who likes logical things that make sense. Dolphin doesn't handle exceptions very well; and the GameCube Microphone has one pretty big exception to it. It's a memory card device... with a button on it. Because it has a button on it, so, Dolphin has to let you configure how to hit that button. Clearly the logical place to put the configuration is... the GameCube Controller Configuration Page!!!

If that wasn't enough, there is even more insanity to be found. The Microphone could be plugged into Slot A or Slot B, with some games requiring it to be in Slot B. Mario Party 6 and 7 are probably the most commonly played of the Microphone games and use Slot B. A common complaint from users is the Microphone doesn't work... because they were configuring the microphone button on Player 1's configuration page. If you wanted to use the Microphone in Slot B, you'd have to configure Controller 2's microphone button. Even if that controller isn't plugged in.

While this may seem bad already, it still gets even worse than that. These menus are disabled when using Native GameCube Controller support, meaning you'd have to switch to a standard controller, configure the button, and then switch back to Native GameCube Controller. And that's assuming you already knew where the microphone configuration button was hiding.

After years of deliberation, the team finally determined that there is in fact a better way to do this. The button is now configurable where you select the Microphone.

A memory card slot accessory control placed where the memory cards go? Crazy!

5.0-1473 - Fix off by 1 Transparency Errors in HW Backends by stenzek¶

Sometimes, typos are the hardest bugs to find. You have this (theoretically) correct implementation that seems to do everything right, yet, the results are slightly off. So slightly off, that in most games the difference is extremely small. No one has reported that the fake-HDR glow is slightly too bright in Metroid Prime 3: Corruption. And why would they? The difference is so tiny that it's impossible to tell.

Can you tell which is before and which is after?

Without looking at the URLs, you cheater.

Thankfully, we do have FifoCi for catching small differences, which is incredibly useful when trying to make things more and more accurate.

The difference is hard to discern with the human eye, but FifoCi sees all.

For someone to even look into a bug, sometimes the trick is figuring out something is wrong. Would-be blog-writers actually reported a noticeable manifestation of this issue five years ago as one of their earlier contributions to the project. Fortune Street had a white mask in the middle of the screen that is fairly difficult to see. At the right moments, it could jump out though.

The accursed white box, bane of testers for years.

The reason why the bug is so much more noticeable than any of the other related issues is simple: there are ~20 invisible (or at least, should have been invisible,) objects stacked up in the middle of the screen! By having ~20 off-by-one errors stacked up on top of one another, a nearly invisible bug became visible! But why are they visible?

At this point, FifoCI could tell us that the software renderer did not have this bug (though, in the original issue report it was noted to suffer from it.) This made things a lot easier, because now all we had to do was compare both implementations and see where the difference occurred. On the hardware backends, it turned out the alpha value was exactly one higher than on software renderer.

Upon further investigation, the problem was located within the alpha combiner. A bias was being added in the hardware backends that was absent from the software renderer. While there is a field that controls whether this value is added or not, on the software renderer the behavior was different between color and alpha channels while the hardware backends used the same logic for both cases. This meant the bias was being added when it shouldn't be in this case, and not being added when it should be in others. When accounting for this behavior, this long time problem is finally fixed.

And finally the puzzle is solved. The white box is no more.

While Fortune Street is one of the only noticeable issues to the naked eye, there are a lot of games that will look very slightly different. The best chance for seeing something noticeable will be in titles relying on heavy use of glow and or bloom effects.

5.0-1487 - Texture Decoding Fixes by stenzek¶

We rely on users for accurate information regarding bugs. We don't always have access to the games or the time to play through to where a bug occurs. In the case of Burnout 2: Point of Impact, a user reported strange texturing defects on the sides of certain vehicles. They all looked low resolution, and they showed screenshots from PCSX2 as a comparison to how the textures were supposed to look.

Look at how much better PCSX2's version of the truck looks here!

This very much looks like an emulator bug in Dolphin.

The screenshots do show that the textures look way off in Dolphin, but to be sure, we asked the user to get screenshots from console. While we can't speculate on why, the user obfuscated the fact they were using PCSX2 for screenshots by switching it to 4:3 mode and lowering the internal resolution. At the time that was enough to fool us, and was only discovered a few weeks ago that they were indeed screenshots from PCSX2 due to its own issues with the game in the revision they were using.

And thus, this bug as become one of the more notable "unsolved GPU bugs" among Dolphin developers, and many man hours have been spent investigating it. Even a trusted tester made a mistake when testing it on console by getting screenshots of a different truck that had proper texturing. He eventually atoned for the mistake by retesting things and figuring out that the truck indeed was broken on console! And, thanks to sharp eyes, realized that there was something else that required attention.

The textures look terrible on the vehicle on emulator...

The textures also look terrible on console. But they are different, which means Dolphin was doing something wrong!

So what is going on now? Burnout 2 is using a common texture format referred to as "CMPR". It is a block texture compression format which is very similar to the DXT1/BC1 formats used on PC GPUs. In this format, groups of 4x4 texels share a 4-entry lookup table, and each texel uses a 2-bit index into this table. Each texture block contains two colors, in RGB565 format. The first two colors in the lookup table are the static colors without any modification. The third and fourth change value depending on whether the first color is numerically greater than the second:

if (color1 > color2)  
  color3 = color1 + (color2 - color1) / 3, opaque
  color4 = color2 - (color1 - color2) / 3, opaque  
else  
  color3 = average(color1, color2), opaque  
  color4 = color2, transparent (this is different to the PC, where it is transparent black)

The texels that were exhibiting the issue used color4, so the problem was likely within this calculation. Changing color4 to use average(color1, color2) as well, but setting the alpha channel to zero (making it transparent) makes the texture look a lot nicer.

While it doesn't make the broken textures look much better in Burnout 2, they do match console. And fixing this accuracy issue did bring us some surprising benefits as well! A lot of textures that used alpha cutout textures look a lot better around their edges.

Oh wow, could that be chlorophytum comosum?

Nope, just an alpha glitch.

While Harvest Moon: Animal Parade shows us an edge case where certain textures look slightly off, nearly every texture in Rogue Squadron 2 and 3 is changed to a degree. You don't even have to look any further than the main menu for issues.

The Rogue Squadron text really looks nasty.

Fixed. There are still some compression artifacts which can't be helped, but it looks much better.

Choosing a ship, flying around in-game and even the main menu all had defects thanks to this bug. Despite this, there weren't any bug reports about the game's texturing being wrong. It just goes to show you how many little things are still wrong out there.

5.0-1490 - EFB Copies Color Coefficient Fixes by stenzek¶

A few months ago, testers began experimenting with EFB Copies to Ram Only mode in an effort to weed out bugs in the EFB Copies to Texture path. Historically, Dolphin has had two modes for storing Emulated Frame Buffer (EFB) copies - to Texture Only (GPU memory) and to Texture and Ram (GPU memory and system memory). The later is what we commonly refer to as "EFB Copies to RAM."

EFB Copies to Ram Only should provide none of the benefits of the hybrid path while adding some extra downsides, so it is not accessible to users. Testers though were interested in using this mode to see if there were any bugs in the EFB Copies to Texture path. Poking around with the feature, testers noticed a few longstanding issues were fixed in that mode. Some minor overbloom issues in Sonic Riders: Zero Gravity aside, the biggest difference was in Metroid Prime 3. The colors were completely different in every codepath, even Software!

EFB to Texture/Hybrid, what all players saw. It looks weirdly warm and splotchy.

Software. It is very close here, but a bit too green.

EFB Copies to Ram Only, a mode only available by modifying the source code.

Every path was wrong except EFB Copies to Ram Only! After closely examining console screen captures, it was determined that software renderer wasn't blue enough while the EFB Copy to Texture/Hybrid path was losing precision. Because we had a path that matched console, although normally locked away, it was fairly simple to narrow down the culprit. The shader system uses floating point math, and each codepath had a different implementation!

But wait, our long time readers say, didn't Dolphin move from floating point to integers years ago to match the GameCube and Wii, becoming much more accurate in the process? While that is true, the big conflict of the time was that added accuracy would be a huge performance cost. Thus, a number of low-risk demanding paths were left in floating point to preserve as much performance as possible.

By figuring out where all of the code-paths differed, and checking with console, Stenzek was able to determine that the EFB to Ram Only codepath was indeed visually correct, and changed all of the other codepaths to that implementation. Thanks to Stenzek's efforts, the bug is fixed on all codepaths!

EFB to Texture/Hybrid. As cool as a spaceship should be!

Software. No more green machine.

Console. Slight differences via capture make it harder to compare than you might think.

This also fixes discoloration issues in other games. In case you've forgotten, any change to anything in Dolphin is likely to affect Rogue Squadron 2/3, and this is yet again no exception. Certain textures, reflections and shadows were returning slightly incorrect colors due to this bug. Though it's really hard to tell, nothing gets past FifoCi!

It should be noted that this is likely a temporary fix. While this is working in every case we've thrown at it, it is impossible to make a floating point value exactly match an integer value. Eventually, all of the remaining floating point math will need to be changed to integers.

5.0-1511 - Nintendo TGC Format Disc Support by Josjuice¶

As shown at the beginning of the progress report, Nintendo TGC files are a special disc format stored on GameCube Demo Discs. Dolphin already could run the demo discs, which would launch a loader that could go through and launch the discs, but, now you can extract those TGC files and load them right into Dolphin no problem.

For the most part, this just allows you to bypass the demo disc loader, but in some cases limitations on the demos are imposed by the loader itself!! So, in the case of Wind Waker's demo on The Legend of Zelda: Collector's Edition the loader itself imposes the twenty minute time limit! You can explore the full potential of the demo to your heart's content without cheat codes.

5.0-1605 - Yet Another Depth Adjustment by Armada651¶

Metroid Prime is one of those titles that seems to keep popping up here with depth issues. For years, the scan-visor was rendering slightly wrong due to clipping issues that Armada finally squashed a few months ago. Then, Armada brought forth depth range handling in the vertex shader to correctly handle depth calculation in scenarios with oversized depth ranges. Doing that fixed depth clipping issues in some games, but, in Metroid Prime it actually caused some regressions, namely in the mini-map!

No one likes Z-fighting.

The bad thing about handling the depth range in the vertex shader is that while Dolphin gains the ability to handle large depth ranges, we then lose precision with small depth ranges. So, Armada has moved yet again to try and fix this issue by only handling the depth range in the vertex shader when the game is using an oversized depth range. This restores Metroid Prime's minimap without breaking anything else. Hopefully. So finally, Metroid Prime (and every other game) should be working properly again on all backends and hardware.

Last Month's Contributors...¶

Special thanks to all of the contributors that incremented Dolphin from 5.0-1415 through to 5.0-1615!