One of the topics of talk that have been hitting up message boards and social media is that of when the next official Dolphin release is coming up. So much has happened in the past year that it's kind of crazy. Huge speedups that hit the core of the emulator, crazy accuracy improvements, hundreds of games with higher compatibility ratings and much more. Most people by default recommend the latest development builds over Dolphin 4.0.2.

But a release build is about more than the latest and greatest features. It's about putting the absolute best you have in terms of stability and usability as well. Yes, the latest development builds are fast, they're accurate, but they also have loads of issues that need to be taken care of before a release can even be considered. The fact of the matter is that a lot of people still use our older releases, and we don't want another case where a release has huge, advertised features broken. Dolphin 4.0 was a lesson that we'd rather be safe than sorry and have to release multiple hotfix builds shortly after a much anticipated release.

We understand that everyone is eager for the next official version, but when there are so many known critical issues on the tracker and others still getting discovered, it's just not the right time for release. While a lot of the issues have owners, due to the volunteer nature of the project, many of the problems aren't currently being worked on. For a lot of the issues, a little time and expertise may be enough to narrow down and fix release critical issues. For our users? Keep finding mistakes in the emulator and making developers aware. Especially when there are so many new features being added.

With that in mind, let's get to a more fun topic; February's Notable Changes!

We say goodbye to three features that have been on life support for quite some time. These features were once useful to either work around bugs, or thought to be accurate and were found not to be. So let's give a moment of silence to our retiring class of February 2015.

VBeam emulation has had a long and storied history. In CRT televisions, the image is sent in an interlaced format, rendering the raster image from top to bottom every other line, then blanking and starting again. The console fires interrupts when the raster line reaches certain points, and some games use these interrupts as internal timing. Naturally, Dolphin has to emulate these timings, and if it gets them wrong any game that relies on them will break. But if Dolphin's emulation is incorrect, then modifying these timings can actually fix them! That's how Accurate VBeam eventually became a mainstay feature.

Eventually skidau was able to make VBeam emulation accurate enough that it didn't have any problems, and could be turned on permanently in 3.5-1249! The hack was on the chopping block even then, but a few games behaved badly with Accurate VBeam and needed the speedhack, and so it remained as the "VBeam speedhack". Once the cause of those aberrations was discovered (special thanks to Fiora for that,) it was only a matter of time before the VBeam speedhack was removed.

Block Address Translation is an basic feature of the Memory Management Unit, more commonly known as the MMU. BAT is essentially registers in the MMU that allow for configuring how memory is accessed. This sounds like an excellent feature on paper, but Dolphin's implementation had one tiny caveat. It was totally broken, did nothing and still managed to cause a 10% speed down when enabled! magumagu removed this in preparation for a proper BAT MMU implementation. And people wondered why Dolphin's MMU emulation spelled doom for games until earlier this year.

When this bug was fixed during our initial progress report it seemed like a huge step forward in understanding one of the quirks of the GameCube. But what if a silly mistake caused a serious issue that somehow went unnoticed for nearly a year?

Despite the look, the bomb still does explode when the counter reaches zero.

This was actually fixed a long time ago by galop1n in a branch, but no one actually noticed!

It turns out that Dolphin never calculated perspective into the fix, making the calculations totally wrong. Most readers may not find this funny, but all the graphics oriented programmers are laughing their asses off right now!

In this case, Metroid Prime 3 had the unfortunate problem where the upper left quadrant of the screen would flicker between 1x native internal resolution and a user's internal resolution settings. That would be a rather easy bug to reproduce in normal circumstances, but this issue only turned up on certain computers.

Eventually both the issue and why it only happened on certain computers was solved. Dolphin CRC32 implementation was messed up on the last few bytes and reading one byte beyond the end of the hash into garbage. This garbage would cause a mismatch, forcing the EFB copy to be recreated from RAM. When Dolphin recreates an EFB copy from RAM, it does so at 1x IR. And finally, because the EFB Copy region is the upper left quadrant of the screen, it dropped down to 1x IR during these cache misses.

The upper left corner of the screen looks nasty unscaled!

With it scaled properly, it looks much better.

This bug does not appear when using "Store EFB Copies to Texture Only", as that setting will ignore the hashing. It's completely possible that other effects that did not consistently upscale are fixed by this as well. Here's to mimimi in hopes that he lasts long enough to find some more bugs in Dolphin's texture hashing.

This is more or less a regression fix. It prevents some hangs in certain games, while fixing the garbage audio bug in Resident Evil 3. The slight timing change shouldn't cause any noticeable differences for users, but if you've seen a recent regression related to disc timings, this is likely your salvation.

Last month saw the introduction of partial support for paletted textures without needing to store EFB copies to RAM. While this was a big step forward, it still didn't make things work correctly, and in some unfortunate cases, the partial support caused big problems in games!

Those worries were quickly alleviated when magumagu took up the task of decoding the EFB copies used as paletted textures. The result? One of the most demanding games in Dolphin, The Legend of Zelda: Twilight Princess, no longer requires EFB to RAM OR Safe Texture Cache for the minimap to function, and it can be upscaled!.

This is really how pixelated the minimap is at 1x IR. Remember, before this patch turning off EFB copies to RAM would cause garbage to cover this area.

With this fix, not only is the minimap able to be upscaled, but it also works without EFB Copies to RAM, dramatically lowering the hardware requirements of Twilight Princess.

But wait, there's more. Twilight Princess is actually FASTER thanks to this as well!

It's not just Twilight Princess that sees these huge benefits, the Tony Hawk Pro Skater games that use paletted textures for shadows can now avoid needing EFB copies to RAM. Rogue Squadron 2 and 3 no longer require EFB copies to RAM for their targeting computers. And all of the effects that use to need EFB copies to RAM for paletted textures can now be upscaled. It's always nice to get a big speed and graphical improvement all at once.

Thanks to degasus handling the OpenGL port of the feature, there are no longer any regressions from this change. A ton of games seemingly used this feature, so now may be the time to check your favorite game to see if now works with EFB copies to texture only.

This is notable as it was the last known Pixel Processing Pipeline upgrade regression. The fix itself is pretty much just removing some room for error in rounding with GPU drivers, making sure Dolphin gets the results that it wants for things to render correctly. Because the Titantron itself has a lot going on, we're actually going to turn to a Teenage Mutant Ninja Turtles game aptly named TMNT for a much, much simpler comparison.

As you've probably guessed, those lines aren't supposed to be there.

While the lines are fixed here and in WWE12, no one really knows how to do this correctly.

This is a rather cool maintenance change that most will take for granted once everyone is used to it. Dolphin comes with a collection of INI files with default settings for every game, each linking to the game's ID. Starting up the NTSC Super Smash Bros. Melee causes Dolphin to check GALE01.ini for settings. The PAL version has GALP01.ini, and the NTSC-J version has GALJ01.ini. Even if all those files have the same exact same settings, all three INIs have to exist. If something is fixed in one and the INI needs to be changed, then all three must be changed.

When you consider Dolphin can run thousands of games in any number of regions, it quickly can become apparent that things can get lost along the way plus there are games outside of Dolphin's database altogether!

By allowing region independent INIs, Dolphin no longer needs multiple copies of the gameinis for each region! It makes the gameini system much simpler and makes future changes much easier on the maintainers.

There are a lot of features of the GameCube and Wii that are very difficult to emulate due to differences in hardware. In this particular case, the Embedded Framebuffer is shared memory between CPU and GPU. This means it can be accessed very quickly from either. This is not the case on our home computers, so even the behemoth computers of today can struggle when GameCube/Wii games rely on certain features.

The asynchronous events merge allows Dolphin to queue up certain GPU events instead of blocking the CPU on each and every one. This will make a huge difference in games that use EFB pokes for certain effects, especially loading screens.

In 007: Agent Under Fire this is the difference between a loading screen running at 2 vps and 50 vps! That's 25 times faster than before! Other titles won't be affected quite as much, but, the improvement is much needed and a huge step in making more games playable without hacks.

Note: Just because this says asynchronous does not mean it's less accurate. Asynchronous in this case just means that Dolphin doesn't block the PC hardware from doing other things while EFB Pokes and other now queued events are gathered. Also, VPS was used as a measurement because the loading screens are static.

Add netplay support for Virtual Console titles and you can imagine just how many great experiences are waiting to be taken online. As such, special care has been taken to make sure that Dolphin's netplay stay functional while gaining new features and becoming easier to use.

One of the biggest complaints is that Dolphin features peer to peer netplay. This means that hosts have to forward ports, manually transfer IP addresses, but the benefits are minimal latency, especially in two player situations. There is no server to go down and cause disconnects. Ziek pulled in some of the core netplay changes from Dolphin's ancient dualcore-netplay branch in how it enabled users to more easily to connect to one another while adding some key enhancements. Now users will be able to connect to a traversal server in order to bypass the need to port forward on most routers, opening up the door for people that don't have access to their routers to enjoy netplay. The changes this branch brings can be boiled down to a few key features...

Using the traversal server means you don't have to dig up your IP address for netplay. Everything is done through codes provided by the emulator. This should help those with dynamic IPs that are changing all the time from having to repeatedly look it up every time they want to play on netplay. It's simpler, easier and faster.

Customizable traversal servers allow users to host their own servers. Everything is open source, so users can experiment and make modification for friends, family, or even competitive ladders!

There is no increase in latency. The traversal server only gets users connected, the end games remain peer to peer to keep latency as low as possible. In the future, three and four player games can likely have their latency reduced a bit too.

No more forwarding ports! While firewalls can still get in the way, most routers will not need forwarded ports to be used on netplay. While there is a very high compatibility, it cannot be guaranteed to work with every router.

The old peer to peer method remains intact, so users can still trade IPs and connect entirely with P2P if they wish.

Because our traversal server was setup after it was merged, the UI still has the old IP based netplay set to default. If you wish to use our traversal server, in the netplay window click the button on the upper right (which by default says Direct) and change it to traversal. Set the traversal server to stun.dolphin-emu.org with port 6262. After that, happy netplaying! In future builds, this will all be set automatically by INI.

All normal netplay rules still apply. If you're using a GameCube game with saves, synchronize your memory cards, Wii NAND needs to be synchronized, and some settings (such as CPU Clock Override) must be either synchronized or disabled.

The developers that have worked hard on these features hope that netplayers greatly enjoy this big update to the netplay experience!

Something that's been mentioned before is Dolphin, and various GBA emulator's, GBA <-> GCN support. While the previous Higan implementation did not work out, skidau has been working on an updated VBA implementation that would give higher compatibility. Once it's finished we'll have more on that, but this is about a different aspect of the feature.

Testing GBA <-> GCN games can be a bit monotonous and difficult, with the setup, multiple emulators, multiple controllers and all the other little things to watch out for. One of our testers going through The Legend of Zelda: Four Swords Adventures wanted to get footage of multiplayer for the article. For this, he brought in his mother to control the second Link. While it was originally destined to be cut up for about 30 seconds of demo footage, the test audience liked it enough that the video was uploaded without cuts.