When I first named this website, I figured most of the content would primarily be cross emulator/console analysis of games. While that hasn't exactly worked out as I'd expected, I've still been interested in the analysis of cross-platform games and emulation.

I was inspired for this when investigating Tony Hawk's Pro Skater 4 back in 2014. PCSX2's hardware renderers and all of Dolphin renderers managed to run into the same bug.

The strange thing was that Dolphin was emulating the effect as it was on the GameCube whereas PCSX2's hardware renderers we're rendering it incorrectly compared to the PS2! As a note, PCSX2's software renderer handled the effect correctly.

I wanted to understand why and see what the game was doing to create a bug that was not only present in a PS2 emulator, but the GameCube version of the game. Over time, I've learned a lot more about emulation and how the target console shapes our favorite emulators.

What these consoles offer, how specific games take advantage of them, and how developers work around limitations all play heavily into how hard it is to emulate a particular title.

Since running into that with THPS4, I've kept my eye on cross-platform ports of games and always been interested the differences between the versions. Sometimes analysis gives a rather interesting insight into both the game's design, late additions made to the game, and how unique console features make the same effects different for emulation.

One particular game that that ended up rather interesting to me was Hyrule Warriors. Because it came out across two generations of Nintendo consoles and a handheld, each subsequent release of Hyrule Warriors saw significant changes. So let's dig in and see how the game plays across three different systems and three emulators!

What is Hyrule Warriors?

Hyrule Warriors was originally developed for the Wii U console and released in late 2014.  Built as a sort of Dynasty Warriors spinoff, it features gigantic battles against hordes of enemies with the world and characters from The Legend of Zelda games.

The Wii U version of the game holds up fairly well, with tons of enemies on screen and the gigantic battles still living up to their billing.  You'll be fighting thousands of enemies, capturing bases, and taking down bosses all while strengthening your heroes through upgrades and leveling.

The game has a "Legends" mode which amounts to a story mode.  While the writing leaves a lot to be desired, there are tons of cutscenes and missions throughout it. Additional missions and characters can be downloaded through updates and bought with DLC.

Outside of Legends mode, there is a free mode to let you take any character you want into the story mode levels. There's also a challenge mode which throws unique challenges at you that can be very difficult. The other main mode is Adventure mode. You're given a sprawling 8-bit map of a world with each tile representing a battle. There are 128 battles in the initial map that comes with the game, though more maps with greater rewards can be purchased through DLC.

One incredibly frustrating thing that I have to mention is that a lot of maps will have clear conditions based on rank. Frustratingly, the game never tells you what the A-rank requirements are for a map. By far the most annoying part of adventure mode is spending twenty minutes fighting only to miss out on an A-rank and an important unlock because you prioritized the wrong categories too much.

Adventure mode is still worth playing despite these problems. You can unlock new characters, new weapons, and stronger weapons that can help with tackling more challenging content. There's also some interesting challenges and battles that are completely unlike content in other parts of the game.

The game also features a challenge mode that you'll want your characters maxed out to get the highest ranks. In challenge mode, it's not about winning or losing, but accomplishing as much as you can within time limits. Higher level characters with stronger attacks, more special attacks, and more health are at a great advantage here.

As a very pleasant surprise, every single mode in this game can be played in local co-op that takes advantage of the Wii U's tablet. Each player gets their own screen and it can be fun coming up with strategies to beat each level as efficiently as possible. You can even take on some harder missions at a lower level than is possible alone!

Unfortunately, the Wii U itself limits the enjoyment of the game quite a bit. Load times are pretty lengthy to do just about anything and the framerate is inconsistent. Multiplayer is even worse, with the enemies seeming a bit sparser and the framerate dipping even in some of the smaller levels.

If you can ignore the faults, Hyrule Warriors on Wii U is a fun game with tons of content.  It's easy to see why it was a well received entry in the series of Dynasty Warriors style of games!

Emulating the Game on Cemu

Cemu is the most complete Wii U emulator in the Wii U emulation scene, thus it was my first choice for emulating this game. The other option was decaf, which while it can boot commercial games, it's not quite as robust. Most people people looking to emulate Wii U games will be using Cemu and it's going to give the better experience right now.

The first thing you'll notice on emulator is that loading times are greatly reduced compared to console. Booting up the game and loading the first mission takes ~30 seconds less in Cemu than on my Wii U, even with my games being stored over the network. Part of the reason may not even be the disc loading speed itself, but the fact that the slow Wii U hardware has to decode the compressed assets. Either way, Cemu is so fast that many loading screens barely have a chance to show up.

Your first time in-game will be a bit bumpy, especially at first.  There will be long pauses as Cemu has to generate and compile shaders. Thankfully, within a few missions the shader generation issues disappear almost completely. Even by the second mission, it was mostly gone.

While the game is playable, there are some visual issues that you'll notice right away. Upon killing enemies, if you're on a NVIDIA card you'll see a mess of black, white, and green on the screen. The game employs some kind of blending technique to discolor enemies as they die and on Cemu, this is rendered in a rather distracting way.

By asking around, I found out this is actually an interesting issue. Cemu relies on undefined behavior in shader code when handling NaNs in some instructions. AMD drivers do what the Wii U does, perhaps because the Wii U features an AMD graphics card, while NVIDIA drivers handle it differently.

If you're on a NVIDIA card, you're not exactly out of luck on this issue. Community made graphics packs or an emulator provided option to reduce shader mul accuracy can greatly reduce how much the issue impacts the game.

Right now, there's no way to completely fix this issue, but there is hope for a proper solution in the future. Patrons have early access to an incredibly WIP Vulkan backend.  While there are tons of other missing graphics and bugs, it does actually handle enemy deaths correctly like console.

Regardless of the visual issues, the game plays incredibly well in Cemu. On my Core i7-6700K + NVIDIA GTX 1070, the game game maintains a solid 30 FPS outside of shader generation, something definitely not true of the game running on Wii U.

I was having a blast as I played through the first level and was ready to start up on the next one when... the game froze.

Updates and Instability

One of the first things I typically do when I buy a game for emulation is to immediately dump it and then throw it at my emulator of choice. While this may work for GameCube and Wii, it wasn't a very good idea on Wii U. Because I didn't run it, I missed out on a ton of updates and additional content added to the game over time. Worse yet, version 1.00 hangs at the end of the first mission in Cemu.

Because I'm both lazy and curious, I tried everything to get Hyrule Warriors 1.0 working on Cemu. I tried playing through the stage with different timer settings, using Cemu hook for H264 decoding, and simply skipping the cutscene instead of watching it. Nothing worked for me, though there may be some magic combination of hacks and workarounds to get past it.

In the end, I finally listened to what everyone told me and updated the game to version 1.12.0 on the Wii U and dumped those updates so that they could be installed on Cemu. As a special note, even outside of the issue I ran into with Cemu, I highly recommend updating the game as it adds tons of quality of life changes and content that are worth having as soon as possible! With everything installed, I was able to pass through the first mission without major issues. I hope that someday the other versions of the game work, but for now at least there is something users can do.

Everything was going fine right up until the end of the second mission where I experienced yet another consistent hang when I was supposed to be unlocking Sheik. Thankfully, the staff at Cemu's discord server was able to figure out what I did to make the emulator unhappy fairly fast.

DLC and Patches

In preparation for this article, I purchased both a copy of Hyrule Warriors for Wii U and Hyrule Warriors: Legends on Nintendo 3DS. The back of the 3DS version advertised that it came with a code that unlocked a few characters for the Wii U version. Despite buying teh game used, the code worked!

This ended up being yet another fatal error on my part, as Cemu doesn't like the DLC in this particular game. While it usually causes a hang on boot, apparently my progress through the game caused it to wait until the next unlock to trigger the hang that everyone else was getting at boot.

The recommended workaround for this is a patch to change a few addresses in memory. That patch enabled all DLC since all of the DLC content was actually included in the updates and buying DLC was just to let the game know to unlock them. While I could see someone arguing that this patch is "piracy", I honestly don't see it that way. Cheat codes to unlock characters have been a thing since the beginning of gaming and the content was already in my possession. To add to that, I bought the Definitive Edition over a year ago and it includes all of the DLC.

Once I had the DLC patch enabled, all of my issues with the game hanging completely disappeared. I continued playing the game trying to see if it would crash again but it never did. I didn't even run into any of the supposedly random hangs reported by other users playing across the main story in Legends mode.

As an important note, the enemy death glitch takes on a much worse form in the second mission, causing all lighting to dim whenever an enemy is dying. Using the Shader Mul Accuracy - False doesn't help with the distracting lighting issues. Thankfully, the graphics pack workaround for the enemy death glitch completely mitigates this issue.

Multiplayer and Cemu

One of the things I like to do is read through the manual when checking out a new game. While I did know a later version of Hyrule Warriors had multiplayer, I didn't know about the Wii U's multi-screen multiplayer. That's because you need a compatible controller connected before it will let you know it exists!

Multiplayer in Hyrule Warriors on Wii U is a bit of a mixed bag. The framerate is a lot less consistent, enemies sporadically spawn (especially when players are far apart,) and the game looks blurrier in general. Still, cooperating with a friend and having a full screen to yourself is a blast! You can really optimize stages or take on bosses that may have been impossible alone.

Unfortunately, Cemu struggles a lot more with multiplayer, with some minor and major issues pertaining to graphics. Don't get me wrong, multiplayer on Cemu is playable, but it can be a bit of a pain.

A much worse issue with multiplayer in Cemu is that sometimes graphics will begin to flicker. Usually it's just 2D elements such as the minimap, but in some very rare cases the entire output would flicker.

My experience with Cemu was simultaneously incredible and frustrating. The game ran better than I could have ever imagined... which is where the disappointment comes in. It's so close to just being this perfect, seamless experience that anyone could jump into. If you read up and are willing to patch the game, then you can essentially avoid most of the issues. If you have a strong enough computer and are willing to risk hangs, you can even push the target framerate from 30 FPS to 60 FPS with a mod.

None of the hacks for the graphical issues are permanent solutions for correct emulation. That said, the overall experience was pleasant and my major gripe is that we need to use a few hacks and a specific version of the game. The core experience is emulated very well, making me optimistic that the rough edges will get smoothed over soon enough.

...On an aside, it would be neat if someday options were added that allowed for better simulation of loading times and GPU timings so that users could see how the game ran on Wii U. But that's something for the far future, and maybe even an emulator with different goals.

Hyrule Warriors Legends

After becoming one of the best selling games on the Wii U, Hyrule Warriors got a surprising port to the Nintendo 3DS in the form of Hyrule Warriors: Legends. Featuring tons of new characters, an additional story line based on the Wind Waker timeline, and the ability to swap between multiple characters during battles, Hyrule Warriors: Legends added a wealth of content on top of the Wii U base game.

Because the game pushed the Wii U so hard, I was incredibly skeptical that a port to a much weaker handheld device could capture the experience. As soon as I booted up the game, my fears were mostly realized. The graphical downgrade in the first mission is downright shocking if you've played the Wii U version.  As a note, I used Citra to get clearer screenshots of the game than possible on my 3DS.

In order to compensate for the loss in hardware power, the developers opted for a simpler style with outlines around models and less detail in general. On the first mission especially, it results in a markedly less epic feel as you're fighting under pleasant skies and open fields instead of a foggy battlefield befit of an otherworldly invasion. Most ancillary details are missing altogether and only the very basics of areas remain.

The game itself does play like the Wii U version. This isn't some port that feels like a completely different game. It's just that the visual downgrade is very hard to ignore when you've just been playing on the console version. Many of the special attacks that were so impressive on the Wii U were simplified or removed.  FMVs and audio have similarly lost some quality, with cutscenes playing at a lower resolution and framerate and character voices sounding particularly fuzzy when played over headphones.

For a game about huge battles, the biggest sin is that the original 3DS simply can't render that many enemies at once. Sometimes you'll be swinging at an enemy right in front of you and it'll despawn to make way for another enemy to spawn, and then respawn after your swing has already missed. This is a constant problem and the pop-in is outright distracting to a dizzying degree.

On the original 3DS, the game is constantly struggling with slowdown and choppiness. It's impressive they made the game work and didn't compromise on the story or stages... but a lot was lost in translation.

A Better Game and a Worse Game

Would it be weird after all of that to say that Hyrule Warriors: Legends has a stronger base game than the Wii U version? After you get past the stripped down graphics and shoddy framerate, you'll find that there were a surprising number of tweaks and new features added to this version. While some of the tweaks are simply to remove graphically stressful attacks, others seem like balancing changes. A lot of stages have new sections designed around the new mechanics not present in the original game.

As mentioned earlier, the biggest change is that you can now switch between hero units during most battles and even command them to do things when you're not in playing as them. This allows for much finer control of the battle and can allow you to work on multiple fronts at the same time.

Story missions are redesigned with new dialogue, side objectives, and rewards! This is important because while Hyrule Warriors on Wii U got some of the content as DLC, it didn't get this essential feature.

Hyrule Warriors: Legends is also home to a new mode called My Fairy. Throughout stages you'll find costumes and food items that can be used in My Fairy in order to power up a fairy companion to help you in your battle. From reviving you when you die, to giving you additional magic power, or protecting you from barriers, fairies can be essential to getting higher ranks and completing missions in time.

The new content does make a lot of the earlier missions more engaging. You have a reason to explore and try to find the new rewards instead of simply shotgunning to the end goal of every stage. The unfortunate thing is that Hyrule Warriors: Legends has a far inferior experience due to the hardware.

3DS Emulation to the Rescue

Emulation sometimes allows games to perform far beyond how they could on original hardware. While the preservationist in me wants an emulator that can emulate all of the lag and framedrops, sometimes it's just fun to have an emulator that truly unleashes the game.

That's what Citra is right now. Enhanced resolution and a superior framerate immediately makes it easier to play. According to the game database, this game requires a powerful PC to run, however I didn't run into any slowdown on my Core i7-6700K and GTX 1070 even when pumping the resolution up.

The side effect of upping the resolution is that it reveals just how barren and stripped down the environments are in parts of the game. The animated backgrounds of the Wii U version are left cut down and frozen. It's impressive that they managed to bring an approximation of the Wii U game to the 3DS, but a lot was lost in translation.

Interestingly, because some events are based on number of kills and there are less basic enemies, a few missions took a lot longer on 3DS. Adventure Mode missions that require more kills have time limits greatly relaxed to make up for the lack of enemies. Being able to switch characters mid-battle to find clumps of enemies proved necessary to get A rank in some Adventure mode missions, at least at my character's levels.

The one sticking point of the 3DS version is that even on Citra the game itself is limited by the 3DS hardware. The game won't spawn that many enemies and they're constantly despawning right in front of me.

Thankfully... there is a more powerful version of the 3DS, and Hyrule Warriors: Legends takes advantage of it.

Hyrule Warriors on New 3DS

Hyrule Warriors: Legends is a game advertised to be enhanced on New Nintendo 3DS hardware. After I tried the game out on my n3DS, I quickly saw that they were not joking. Most of my complaints with the original 3DS experience were actually addressed!

The framerate is much improved with slowdown more or less non-existent in the first couple of missions. Even when there is lag in larger battles, it tends to be rather mild compared to the constant drops that happened on the weaker handheld. And speaking of heavier areas, a lot more enemies spawned in than compared to original 3DS hardware and Citra.

This greatly helps the game feel like the Wii U version as the battles start to reclaim some of the grandeur they had in excess on the console edition. Don't get me wrong, terrain draw distance and enemy pop-in are both still fairly distracting. But here? It's a minor problem instead of something that you're constantly fighting with.

While it's an obvious graphical downgrade compared to the Wii U version, the new gameplay elements do make it a tempting choice to play over the Wii U version. Plus, if you're a fan of 3D effects, you can actually use the 3D screen when playing on New 3DS for added depth... and some slowdown. The effect is actually fairly impressive and can be fun to use in bursts.

This is where Citra ends up in a very strange place. Citra currently emulates original 3DS hardware, not New 3DS hardware. For Hyrule Warriors: Legends, the game itself is heavily downgraded when running on original 3DS hardware. Emulating New 3DS hardware is quite a pain for Citra as it wasn't designed for the multi-core nature that is the new 3DS. Scheduling and emulation of another CPU are required.

Despite this, developers have been hard at work on New 3DS emulation and allowed me to test some experimental changes with Hyrule Warriors: Legends. In these builds, Citra would report itself as a New 3DS and has modifications for extended ram and some other hardware differences.

And it worked!  Sort of.  The game did boot in n3DS mode as the game as the draw distance for enemies was lengthened and enemy animations were extended. However, it didn't do things quite right as the enemy density was unaffected.

Despite not quite hitting the mark, it is quite nice to see the game at least running in n3DS mode. It's a slightly better experience than emulating the game as if it were running on original 3DS hardware but nowhere near as good as real n3DS hardware.

Why is the game not running correctly? No one is sure quite yet. All there is to do is to keep implementing n3DS features correctly until the game starts working. Whether it is Citra or another emulator that gets this game right, I do believe that the n3DS version of the game is worth seeing if you're a fan of the other versions.

Graphical Issues on Citra

Beyond the n3DS issues, Citra does have a few minor problems emulating Hyrule Warriors: Legends. If you've played the game on 3DS, you'll quickly notice that character outlines that help make the game look more stylistic are missing. However, outlines around objects render over everything. This results in the game not quite looking up to par.

Neither of these bugs can be remedied using Citra's software renderer, making me believe there is a problem deeper in the emulator. Worse yet, software renderer even crashed on me in the main menu. Thankfully, I didn't see any crashes in the hardware renderers and was able to play through several stages unimpeded.

Whether you can stand playing the original 3DS version of the game or not determines if you can enjoy this game in Citra. There are less enemies, more pop-in, and graphical glitches as you play, but you also get higher resolution graphics and a much smoother framerate than possible on original 3DS.

If only there were a version of the game that combined the portable nature of the 3DS with the power of the Wii U...

Hyrule Warriors: Definitive Edition

Hyrule Warriors: Definitive Edition was released in 2018 on the Nintendo Switch. This is the version of the game I'm most familiar with and one of my favorites to play when I'm between other games.

Definitive Edition strives to be the best version of the game by combining both the Wii U and 3DS versions into one complete package along with some enhancements. The game features the Wii U's graphical style with the resolution bumped up and the target framerate pushed to 60 FPS.

But this is not just a port of the Wii U version plus DLC. The game has all of the modifications and enhancements developed for Hyrule Warriors: Legends. That means that you can switch characters, raise fairies, and play the more substantial 3DS versions of stages.

My Fairy has seen a complete visual overhaul and has been reborn with full 3D graphics. The functionality remains mostly the same; raise fairies to give you essential boosts to help you weather the storm of giant bosses and hordes of enemy captains.

Adventure Mode in Hyrule Warriors: Definitive Edition is actually almost overwhelming. When the game first launched on Wii U, there was only one map with over one hundred battles with many having secrets to find.  On Nintendo Switch you start with all of the adventure mode maps, including those only present in DLC exclusive to one version previously.

The developers rebalanced rewards and gave each map a difficulty to help you choose where to start. Easier maps can help you level up your characters, unlock new characters, and unlock stronger weapons.  Harder maps have better rewards, including legendary weapons that can greatly enhance your favorite characters.

My only major complaint with Adventure Mode is that they still don't tell you the A rank requirements.  Sometimes it's 1500 KOs, sometimes it's 1800 KOs, sometimes you don't need any number of KOs at all!  Do yourself a favor and find a guide that lists out all the A ranks unless you want to deal with a lot of frustration.

Another thing I noticed is that the missions in the map present in all versions of the game tend to be more like the 3DS version in the Switch version. Mission descriptions use the 3DS version's text and time limits have been relaxed on a lot of the earlier timed missions despite the enemy count returning to console levels.

Much like the Wii U version, this entire game can be tackled with a friend in a rather awkward to setup co-op mode. It feels tacked on, especially in the menus where you have to manually activate co-op on player 1's controller every stage. In this version, Player 1 also must select player 2's character, where as in the Wii U version the second player took control for those menus.

These problems don't actually matter once you're in game as this is the best multiplayer experience that you can get with Hyrule Warriors. The loss of a second screen for each player is a bit unfortunate but understandable considering the Switch lacks the Wii U's tablet.

On the plus side, multiplayer packs a much bigger punch in Hyrule Warriors: Definitive Edition. Multiplayer tends to run at 30 FPS, though it does sometimes hit 60 FPS in some of the smaller maps. Enemy count in multiplayer is much better than on Wii U and you won't find one of the players barren for enemies while the other is locked in a battle.

Another thing I need to mention is that the game's controls have been altered a bit compared to the Wii U version. All characters can turn much faster. While it doesn't change much, I just felt the need to mention it as I felt it's one of those things you only notice when bouncing between versions.

Definitively Buggy

While usually I'm a bug hunter within emulated titles or in games I speedrun, this is one of those games where just about everyone will run into a rather severe issue if they play it long enough.  It's easy enough to work around and isn't very dangerous, but it's a bug I need to mention as part of the experience.

Because the Nintendo Switch allows you to sleep games without ever turning them off, it's very easy to end up unintentionally cause this game to go haywire. The longer it's left on without rebooting... the more things seem to get messed up over time. All of the following glitch demonstrations are taken directly from console. These are not emulator bugs.

The screenshot above is from last year when I first got the game and was shocked to see it break so spectacularly. I didn't know what caused it back then or how to reproduce it. Once the game crashed, it was gone.

While tons of other people have reproduced this bug and captured footage of it, one of my goals coming into this article was to try to and figure out what was going on myself. Unfortunately, despite my contacts in the emulation community, no one was able to give much of an answer.

Despite that, I continued testing and finally got the bug to start happening again. With my capture card always recording, I recorded a ton of footage of the issue hoping to make some sense of what was going on. In the end, I did figure out what was going on with multiplayer, but I still don't know why the game breaks the way it does.

As one last note, despite how severe this bug is and the fact it will eventually crash the game, I have not seen anyone lose any progress because of it. If the game is going to crash, it seems to do it on stage load before you've accomplished anything. And, with the game's generous autosaving, even if it did crash during a stage, you'd rarely lose more than ten minutes of progress.

The Experimental Switch Emulation Scene

While Cemu may claim to be experimental, it's much closer to what I'd call a general use emulator at this point. I had a few issues learning the ins and outs of graphics packs, installing DLC, dumping my NAND and all of that, but the emulator itself is incredibly impressive and the game is playable. The Switch emulation scene is more along the lines of what I'd call experimental.

yuzu and Ryujinx are the most complete Switch emulators available right now. At most, I just hoped one of the emulators could boot the game. Anything beyond that was a bonus. Thankfully, yuzu provided me with a pleasant surprise.

Let's get one thing out of the way right now: yuzu requires a lot more power than the other emulators and is much earlier in development. 2D graphics displayed fine outside of FMVs, audio worked, and honestly I was impressed the the core game played correctly. While it took me a several hours due to the game running at ~5% speed, I did beat the first two missions in yuzu to capture some footage.

Don't let yuzu fool you, while it may look like a bunch of the graphics are missing, it's actually rendering everything quite well. If you manage to get the right group of effects to line up, you can see that all of the models are fully present and textured correctly.

Active Development

So that's it with yuzu, right? Not quite, as developers gave me a heads up that maybe I should wait a little longer before etching my thoughts in stone. So I waited for the September Patreon build to see what they had in store...

I got a preview to look at some of the improvements they were making and was astounded. The game looked recognizable was pretty close to working. Then I got told to wait again.

So I waited. A few days later, I got an update that the coloring issues would be fixed. However, along with that fixed seemed to be a lot more!

In just a couple of days the game was transformed. Not only was the game rendering in the correct colors, shadows now rendered, water now rendered, and most of the other missing graphics were now present.

If not for a few minor issues with transparency on objects, it'd be incredibly hard to tell yuzu apart from console in some of the screenshots.

While these improvements over the course of just a couple of days is incredible, I must stress that yuzu is still not a substitute for playing the game on Switch like Cemu and Citra are for their respective versions of the game. Performance is still incredibly slow and FMVs still don't render. Regardless of those minor issues, yuzu shocked me. When I started writing this article, I never imagined the game would look recognizable by the end of it.

Conclusion

The Emulation

After spending a lot of time in all three games, it's clear to say that Hyrule Warriors is in a very good place when it comes to the emulated experience. Both Citra and Cemu can easily replicate their respective target hardware's experience with some nifty enhancements. Just remember to update the game and enable the DLC hack on Cemu so you don't run into the same problems as me!

Citra doesn't have any of those issues and the game runs right away. I do highly recommend dumping the update data because it gives you additional content and plenty of quality of life changes to the base game.

If you're willing to deal with some minor graphical issues and spend some time setting things up, both Cemu and Citra are solid options if you want to experience Hyrule Warriors in an emulator. The only unfortunate thing is the lack of full n3DS support, which is the biggest disappointment I have.

On the Switch end of things, there are different expectations and the current Switch emulation scene exceeds them. Before the Patreon previews, I was already impressed that the game booted and was behaving correctly, but now I just don't know what to say. The game is rendering mostly correctly and it seems like the future is incredibly bright. Performance is a problem, but developers are aware of what makes it so slow and are optimistic that future changes could greatly improve the performance of this game.

The Games

As someone who played Definitive Edition first, it was very interesting to go back and play the earlier releases. Unlike typical cross-platform games spread out between consoles of the same generation, Hyrule Warriors had successive releases on Wii U, 3DS, and Switch.

Despite the changing target hardware, developers seemed to care about improving the game with each release. As much as I gave Hyrule Warriors: Legends some flak for the way it looked, it's an incredibly ambitious port that attempts to bring the Wii U game to an underpowered handheld. It has tons of content and even takes advantage of New 3DS hardware to improve the experience further.

In terms of mechanics, the 3DS version also added things like My Fairy and character switching that dramatically changed how you could play the game.

But it's hard to choose either of those over Definitive Edition. It has the best graphics, the most enemies, the most content and sports all of the features from both versions of the game. The only two arguments you could make is that the first stage feels more dramatic on Wii U and the multi-screen multiplayer using the Wii U tablet. Even with those in mind, Definitive Edition is just a better product with faster loading times, more content, and better graphics overall.

The decision between playing the Wii U version or playing on n3DS is a lot harder. Mechanically, the n3DS version is little better than the Wii U version and the 3D depth the screen can add is very impressive. It's close, but I have to pick the Wii U version due to the stronger hardware and bigger battles. If you have a partner for cooperative play, it just makes the decision a lot easier.

Regardless, of nitpicks, they're both far, far, beyond the original 3DS version that doesn't even allow for use of the 3D screen.  That's about all I can say about these games. I hope everyone enjoyed this look at these games and someday I hope to do more writeups like this!

By the time the Xbox 360 came out, my interest in modern gaming had already started to wane. While I did own an Xbox 360, I didn't have many games on it and mostly used it for playing with friends online. I don't have an incredibly strong attachment to the Xbox 360 nor its library, but I do appreciate emulation and have wanted to give it a shot.

Xenia is the dominant Xbox 360 emulator, and has been making gigantic strides. At this point, many popular games can boot and some are even in-game. How playable they are varies from game to game and how fast they run heavily depends on the strength of the host machine. It's unreasonable to expect perfection in games, but some are running quite well.

When I look to test an emulator and report bugs, I like to start with games I have a lot of experience with as early candidates. It helps me stay grounded and have a direct reference point as to what correct output is without having to know much about the emulator. I also wanted to choose a game that was likely to run well.

That led me to try out Castle Crashers and discover a rather fascinating rabbit-hole surrounding Xbox Live Arcade games.

A Short Demo of Xenia

Upon loading up Castle Crashers in Xenia, the game played pretty much how I remembered it. Xenia itself showed some nifty details in its presentation. I particularly liked how the Windows task bar would show an icon for the game that's currently running instead of the Xenia logo.

Xenia only supports XInput controllers, but they work well and don't require any configuration whatsoever. On my PS4 controller, everything worked without any trouble. It was actually a bit surprising for rumble to be working without me having to go through any kind of configuration menu. For those without a controller, there are keyboard controls as well, though it is not quite as natural as using a real controller.

The one major problem I ran into is a rather common one in emulators: the text was garbled. According to footage of older builds, this wasn't always the case.

As someone experienced with other emulators, I know how tricky it can be to get text rendering properly. This wasn't any real cause for concern and I wouldn't be surprised if it wasn't weeded out with other rendering issues across other games in the future.

Considering that this was the only major issue I had run into, I was incredibly impressed... until my session came to an abrupt end during the first boss fight.

To make things a bit clearer, here's a screenshot grabbed from someone playing the demo on console.

Considering that the game was playing perfectly fine outside of minor graphical issues, this was rather frustrating. After looking at various documentation and asking around, I found out that an Xbox Live Arcade game and its demo are the same file. The only difference is that you need a bit set to make the game run outside of demo mode.

I figured that Xenia not setting this mask was some kind of anti-piracy measure in order to prevent users from downloading the demos off of their Xbox 360 and then running the full version on Xenia. That wasn't actually the case; while most titles are still available on the Xbox Live Arcade, Xenia devs claim that this is not a piracy issue.

I couldn't believe that was the real public response, but it truly appeared to be the case. People within Xenia's discord echoed that and that's how I received that screenshot. I was rather upset that the emulator was being limited for what seemed like such as nonsensical reason.

However, Rick showed up and answered my questions directly, giving some incredible insight into the reasoning behind the decision and how things developed the way they did.

The license mask policy. For context, this dates back to before Xenia provided any sort of "official builds" (which we do now, via AppVeyor).  There's two parts to this:

Core contributors (then, this would be benvanik and myself, maybe DrChat - don't remember if they had write access to the repo yet) agreed that we wanted a way to get people making their own builds. At the time there were third party builds being distributed by, let's say, less savory, sources which was adding an increasing amount of nonsensical noise to the project.  Also at this time, Xenia was only really booting XBLA titles in any functional state. (side note: many XBLA games at this time were also breaking in non-demo mode.)

The license mask defaulting to cause non-disc games to end up in trial mode was chosen as an easy 'out': "Game is in trial mode!".  My response: "Make your own build". Later this changed to: "Make your own fork". If they don't - user isn't here to help contribute. Still appropriate I'd say.

Its entire purpose was (and still is) to weed out people only here to just play games in Xenia. And it's done that spectacularly.  Xenia wasn't, and still isn't ready for users, IMO. Which is why I've been stubborn about it being changed.

Configuration:

A global setting for the license mask doesn't help anyone. Every game is different.  Suggesting that you run every game with a license mask with every bit set is flat out nonsensical (which is what people have been doing).  If the only way for license bits to get set is via controlled mechanisms (ie, via the developer/publisher and Microsoft), then having unexpected bits set could easily lead to undefined behavior at the fault of Xenia.

I've wanted for awhile to tie license stuff together in a way that makes sense, ie: user profiles and content that is "installed". It's been on the backburner for awhile. I've spoken with specific people in the past who were interested in working on this problem but they haven't gotten around to it, nor have I (very low priority for me).

Finally, everything made sense. While I don't entirely agree with all of the reasoning and methodology, I can at least understand the purpose and ideas behind what they were trying to accomplish. As Rick explained, simply hacking it the other way isn't a real solution, so Xenia itself did need to catch up a bit before it could really be fixed.

I disagree primarily with the fact that creating hurdles for general users is a good thing. As annoying as some users can be, they're an important part of testing and maintenance. More users means there are more headaches, but it also leads to regressions being caught quicker, more obscure games being tested, and people like me with little coding expertise being able to more easily contribute. In this case, it just depends on the developer if the extra noise is worth it, and they determined at that time that it wasn't.

With games like Halo 3 and Red Dead Redemption running in modern builds, having this limitation didn't make sense from the standpoint of limiting the community. And in the above quote, Rick agreed, saying that he was open to changing it if it was implemented in a reasonable manner. And things quickly seem to be heading that way as developers seem poised to allow the license mask to be customized on a per game basis thanks to Xenia's improved configuration infrastructure that didn't exist back when these decisions were made.

A Relic of the Past

I came into this article because I was frustrated, in the end I learned a lot more about Xenia than I expected. I got to play a game I hadn't tried in years, learned about how demos worked on Xbox 360 and got a much fuller picture on what happened. Honestly, the whole situation has made me more invested in Xenia than I would have been otherwise.

When I initially started writing this article, my only knowledge of why Xenia was running the game as a demo came from screenshots and out of context quotes of Rick. It seemed like the actual purpose and meaning behind why Xenia was doing what it was doing was lost in translation. I'm happy to have learned the history behind it and the true reasoning.

Soon enough, it may not matter as the latest builds of Xenia will have the ability to run Xbox Live Arcade Games accurately depending on how the license mask is configured.

Emulator development has never been simple, but contemporary emulators face a tremendous set of challenges created by the modern era. Having witnessed some of the trials developers have gone through personally, I feel it's necessary to try and give an idea of what I've seen and my perspective on the situation. Some of the following topics are rather touchy, so please try to keep an open mind while reading.

My Short History Within Emulation

I joined the emulation development community mid-2013. Compared to many of the stalwarts of emulation I've met throughout the years, I'm a mere toddler. I'm not a coder and I'm definitely not a genius. I'm just a busy body that tests games and likes to write articles.

What invited me into emulation was Dolphin and the idea of fixing up netplay so that we could get games like Super Smash Bros. Melee working consistently on netplay. With help from my brother, who is an accomplished software engineer now, we worked on netplay issues, asked developers questions, and even released our own modified builds with the goal of eventually getting our changes merged into master.

Our branch was never fully finished, but others joined the cause and netplay saw great improvements from many developers. Nowadays, the situation is far beyond my wildest dreams, and I can play pretty much any game I want on Dolphin's netplay. There are entire communities built around Dolphin's netplay, including websites like smashladder which are far beyond the ambitions I held back in the day.

During my work on Dolphin netplay, I realized I really enjoyed working on Dolphin and testing these games. There was something cathartic about digging into a game and figuring out what it was doing, how it was doing it, and how Dolphin was emulating it. The feeling of accomplishment when you finally get it and figure out what's going wrong is incredibly powerful.

Through constant testing, I began to build up my now encyclopedic knowledge of weird game behaviors and how Dolphin handles them that I have today. That knowledge would then come into play as I became one of the writers on the Dolphin Progress Reports. Thanks to the patience and kindness of developers, I know Dolphin well enough to write full length articles on hardware, how games take advantage of that hardware, and what makes things more difficult to emulate.

It may not seem all that surprising nowadays, but back then I never thought it'd be possible to contribute to an emulator as a non-coder. But other skills come into play, and I've contributed to projects like Dolphin, mGBA, Citra, yuzu, RPCS3, and others. Dolphin itself has definitely influenced the community on the whole as the idea of Progress Report style monthly updates and blog teams have become fairly common.

The Core Emulator Team, Open Source and Forks

Since the Nintendo 64 and PSX era, emulation development has become about collaboration. The paradigm quickly shifted from plugin based emulators to open source emulators and that's where things have mostly settled for over a decade. After all, open source offers what one would think to be the ultimate advantage of allowing anyone with any skill set to look at the emulator and modify it.

Regardless of how many contributors a project has, there tends to be a core emulation team that manages the project. Some are more active in development than others, but they all care deeply about the project and will often weigh in on decisions and fight against or for particular changes. While everyone wants to improve the emulator, the core team can deeply affect the direction of the project.

A strong core team and good decision making is the key to keep a project maintainable and active. Considering that the master branches are the ones that most people contribute to and fork off of, it's especially important to make responsible decisions for the health of the emulator and community on the whole.

There are actually thousands of forks of Dolphin that are based off of this master branch. While the core developers are very careful about what gets merged into master, people can do whatever they want with their own fork, resulting in many specialized versions of Dolphin.

When open source works, the results can be incredible. Anyone can fix, create, or implement anything while having unparalleled access to the internals of the emulator and the software it can run. You don't even need programming experience to contribute, with many people contributing through services like transifex to help translate and increase accessibility of emulators around the world.

A New Generation of Open Source Emulation

I was introduced to Citra long before its initial public release. Since developers worked with me for the blog, I had a bit of an inside line on things they were working on. So imagine my excitement when one of the developers showed me the beginnings of a 3DS emulator as it booted its first game!

At this point, Dolphin's Progress Reports had become extremely popular with users and this new emulator, Citra, wanted to do a similar thing. For me? It seemed like a match made in heaven. Unlike Dolphin where I joined it as a fairly mature emulator, I'd be with this one from day one. I was one of the only non-coders within their development channels before the initial announcement.

Everything at the beginning was exciting with Citra. It felt like this new project with new games to test and new bugs to discover, report, and write about. The first few months went by at a crazy pace, with performance, compatibility, and feature-set expanding at an incredible rate.

Yet, something was off about the project. I didn't know exactly what, but, I didn't have the same devotion toward it that I did Dolphin. Part of the problem actually had to do with me. I had become specialized to how Dolphin worked through years of testing and working with developers. I didn't put forth enough effort to learn about Citra and developers were too busy still discovering new things about the 3DS to waste time walking someone like me through concepts that would normally be far beyond me.

In the articles and videos that I did make, I was rather vague because I didn't quite understand how things work. I would constantly compare things to how Dolphin worked, because that was my only frame of reference.

If things had proceeded normally and Citra stabilized like Dolphin did, I probably would have adjusted and eventually figured things out. Unfortunately, I didn't last quite that long with the project.

A Userbase At War with Developers

One core thing to remember is that developers care about their projects. While some of the minute details may vary, in the end most of the people working in emulation are working to preserve hardware and/or games in their own ways. It doesn't matter if that means working on the ultimate enhancements, pixel perfect accuracy, or improving performance - they all care.

Some users don't seem to understand that. They seem to think that these emulators are purposefully crashing or too slow just to frustrate them. That their Pentium IV is newer than a GameCube, and thus should be able to emulate a GameCube regardless of what these people who have worked on this emulator for decades say.

That isn't to say users are bad. Users are necessary as many of these emulators support giant libraries of games. They report bugs that developers would never know about otherwise, and some of those users fix the bugs themselves and join the project as a new developer!

I know it's wrong, but, I've lost my temper many times when working within the support forums. I understand that many of these users just want to load up their favorite game and have it work. When you deal with thousands of reports, even if only 10% of them are problematic, they start to weight on you.

Working on Citra's social media and forums was an absolute nightmare because it seemed like everyone hated us. The desires of the userbase and developers shifted so far apart that it bred vicious malcontent and distrust. Before you could even answer a question on a thread, another user would have already replied that the developers don't care. It didn't matter if it was on reddit, facebook, chat logs, or anywhere else, it felt like users hated us.

What caused this massive divide? Because users wanted to play Pokémon now. Okay, that's a slight exaggeration, it wasn't just Pokémon, compatibility with a few popular games was slow in Citra due to some rather difficult features to emulate that they relied on. Pokémon fans only stood out because they were the most vocal of the annoyed fanbases.

Early on in Citra it started out with just asking for the games to boot, but the longer things went, the more tense things became. Simple questions became more annoyed as they disregarded the projects efforts until this one, single, thing was supported.

I don't know if they thought that downplaying everything they didn't care about would move developers toward something they wanted, but it had the effect of making it harder to work on anything.

Third Party Builds, Licenses, and the Placebo Factor

At this point, I was already distancing myself from Citra. So much of support on the forums was just banning people for downloading games or telling them Pokémon didn't work yet. It's not exactly fun to play the bad guy, and while some users understood, others absolutely didn't. Compared to working on a project beloved by users like Dolphin, working on Citra was stress I didn't want in my life. I still stayed around the development team though, as my issues weren't coming from them.

From a distance, I witnessed as things went from bad to worse. If you've followed Citra closely enough, you probably already know about the "third party" builds. This isn't talking about every fork, but a specific kind of fork with a very specific purpose.

They were designed to prey upon an impatient userbase and violated Citra's open source license without any repercussions. By taking incomplete features posted by developers for review/testing and mixing them with egregious hacks that would make others cringe, these third party builds created a reputation among users as being "fast" builds. It started with HLE audio support but quickly spiraled out of control with any unmerged feature becoming open game.

This put extra emotional strain on the authors as they watched these forks get credited for changes that they sometimes spent months or even years researching and implementing. Some of these changes were incrementally put up in smaller chunks over the course of months in order to maintain a clean history, which as we mentioned above was incredibly important for the master branch.

These good development behaviors gave third party forks the opportunity to get these features much earlier than master, even if they were buggy and incomplete.

So of course developers disparaged these builds and told users not use them. Other than being hack builds, they violated Citra's GPL license by modifying the emulator and distributing binaries without releasing the adjusted source code. But here's where it gets a bit fucked up. Users trusted these builds that violated Citra's license over Citra's core development team. It was incredibly easy to see on the forums, as users would constantly recommend these builds with faster audio or the new CPU core. The weird thing is that they knew how buggy it was, and always have to give extra instructions on what games didn't work or how to bypass various bugs, but it didn't matter.

To them, these third party builds were the ones made by people who really cared about the users, unlike the core Citra team.

It was an incredibly difficult trend to stop. Third party build developers would link to videos with obviously faked performance and resynced audio whereas the core developers obviously could only use real results and footage.

There were even experiments done, by Citra developers posting builds with no changes at all claiming they were built with similar techniques to the third party builds. Unsurprisingly, they claimed it had fixed all of their issues. To make matters even worse, some opportunists took advantage of users' willingness to download third party builds and packed their own variants with malware.

Striking Back With Bleeding Edge and Canary

The core Citra team had to go on a huge campaign to restore their image within the community and combat the third party builds. Changes began being developed in secret in order to make sure the official builds were able to get the feature before anyone else. This effort was incredibly taxing, but necessary in order to keep the main builds relevant.

In the end, the entire infrastructure behind Citra went through a radical overhaul. A complicated system was devised to automatically merge together important pull requests and automatically make them available alongside standard development builds. This started out "Citra Bleeding Edge" and eventually was replaced by "Canary" builds. By allowing users to test these builds before they were merged into nightly builds, they were effectively able to get the jump on third party builds.

This system took a tremendous amount of effort and time, but eventually allowed the project to stabilize to where it is today.

But what most people don't realize is that things almost went in a very terrible direction. Imagine if these third party builds had worn down developers further. Imagine if the future of 3DS emulation was suddenly stopped by these people who had no idea what they were doing, didn't care about anything else but making a single game run better.

Some users don't realize that these third party builds were 99.9999% work done by the core developers and some minuscule, broken changes done by someone who didn't have much of an idea what they were doing. Without Citra's team, these builds would also die out. Citra can exist without the third party builds, but the third party builds cannot survive without Citra remaining active.

The scars of this battle linger with many of the developers who worked on Citra. A lot of the same principles and protections exist in yuzu to prevent a similar situation from happening.

Nowadays I think back and wonder... was there a better way to handle things?

Rise of the Closed Source Emulator

October 13th, 2015, a Wii U emulator showed up that would shake the emulation community to its core. Unlike many other emulators of the era, Cemu decided to make itself as a closed source emulator while also giving out builds early over Patreon.

This threw up a bunch of red flags, and I was particularly very critical of this decision. I vowed to do what I could to help decaf, the open source Wii U emulator, while disparaging Cemu every opportunity I got at first.

I've said a lot of mean things over the years and I honestly regret them. So to the developers of Cemu and the people that enjoy the project, I apologize. I can't really justify my actions or words as I think back on them and I can't take back what I've done. All I can do is try to explain why I now believe Cemu's position as a closed source emulator may not be harmful toward our end goals of preserving gaming history.

Unlike Citra, which had to constantly battle with third party builds and hack builds, the Cemu team controlled their brand extremely well. While I do think it's a bit excessive to have something like anti-piracy for week early builds, considering the amount of effort Citra had to put into combating third party builds, it doesn't seem quite as ridiculous.

When Cemu was announced, I really couldn't figure out any good reasons why you'd want to be closed source. How that could ever be better for emulation and preservation?

My conclusion was that it was purely for greed. To reinforce my opinion, Cemu turn out to be one of the most lucrative emulators ever with its Patreon reaching well into the tens of thousands of dollars per month. But is that really a bad thing? Perhaps if emulation suddenly stopped after Breath of the Wild was mostly emulated, but the emulator has continued to make strides.

At this point, Cemu has become an excellent emulator with high compatibility, performance, and even online support that are going to assist with preserving the online features of Wii U games. Patreon has become a staple of most modern emulators with yuzu even going for a similar early release model to Cemu.

Despite being an incredibly strong emulator, Cemu still faces a ton of hatred and vitriol. A lot of this is directed toward the fact that it's a closed source emulator. Much like how third party builds derailed conversations about Citra, Cemu's release posts end up plastered with mean spirited comments about it being a useless closed source emulator.

I remember being a part of that and feeling like I was totally justified. Now I feel like I was just being a jackass. Even if you disagree with what Cemu is doing, is that how you convince someone that another way is better? If anything, it makes the people calling for them to go open source look bad.

At this point, Cemu's popularity has died down a bit as some users have moved onto newer emulators. That said, it still remains the fastest and most compatible Wii U emulator by a sizable margin over decaf. Despite the fact that people (...including myself in the past) have tried to pit the Cemu and decaf developers against each other, they don't seem to carry malice toward one another.

Going up against a titan can be frustrating, and decaf developer exjam has expressed frustration about coexisting with a closed source emulator targeting the same console. Fortunately, both teams have been willing to share information and it's fairly clear both care about emulation and the Wii U console because of their continued dedication toward their projects.

Here's one last thought on Cemu's position. Some of the currently dominant emulators like Dolphin and Project 64 started out as closed source projects before going open source. In fact, even Dolphin was closed source for longer than Cemu has been around at this time. Maybe it isn't such a bad thing for an emulator to be closed source while it establishes its identity. Then once the early development, structuring, and userbase is established, the project is more capable of fending off any malicious third parties.

Much like with other emulators, there's no saying Cemu can't go open source later on. I really do hope Cemu goes open source in the future, decaf has already proven useful to Dolphin with some of its documentation on Wii U behaviors that ended up true about the Wii as well. Even beyond that, Cemu is an incredibly popular and versatile emulator that should see use for many, many years to come. I don't think anyone wins if the emulator ends up locked to obsoleted platforms because no one can maintain it after development has ceased.

But that is purely the responsibility of the Cemu developers. Right now, we have two Wii U emulators that can boot retail games very early on in this era where games quickly update and services die out faster than ever. So, to all of the developers of Wii U emulators and those that have supported the projects, I thank you for your efforts and contributions toward emulation.

Emulators in the Modern Era

Whether or not we like it, the situations with both Cemu and Citra have greatly changed the landscape of emulation. Cemu is an incredibly successful closed source emulator that has given other projects a template to follow toward becoming successful. Citra is an incredibly successful open source emulator that has shown both the difficulties of open source emulation and the resilience of developers.

Every project is going to have its own trials, challenges, and decisions. mGBA isn't going to have people trying to leech users with third party builds, but it's also a second generation GB/GBC/GBA emulator with many alternatives. There isn't nearly as much demand from users for a new emulator.

However, some older emulators do run into similar problems as new demands come up. PCSX2 has its own third party, closed source build problem stemming from users wanting the emulator on a new platform. The situation is even more annoying than Citra as these developers are selling this closed source fork on the Play store with zero repercussions.

In these cases where a fork is problematic, there's really not much in the way of recourse. Some of the biggest open source projects like Firefox can actually defend their trademarks and copyright, but they're the exception. An emulator is often times already considered a legal gray area and very few people care to stand up for their rights. Even if an emulator was in position to fight, most developers I know would rather just work on emulation than deal with superfluous problems.

Going closed source does almost entirely mitigate the existence of third party builds. However, it doesn't ensure that you're able to establish yourself freely. For as long as I've known, there have been fake websites popping up to try and siphon ad-revenue from legitimate software. Even Arisotura, the developer behind many emulators, including melonDS and BlargSNES, ran into that issue frequently with their earlier projects! It's surprisingly common - when I was researching my melonDS 0.8 article, figuring out which website was the official DeSmuME website was rather annoying!

Regardless of the choice, developing and establishing an emulator isn't a trivial task.

At a Crossroads

For the longest time, I was certain that going open source was the only reasonable option. When Cemu arrived as a closed source emulator, it challenged everything I knew and I reacted with extreme negativity. It took emulation in a direction I didn't like. But all things said, Cemu has absolutely thrived and perhaps that alone justifies the developers for taking things in that direction.

Cemu has undoubtedly had a huge effect on the emulation community at a larger scale. Their use of Patreon is now commonplace among most emulators. Citra's situation has also affected other projects, as I've seen a lot more caution and secrecy within projects regarding new features.

One of the premiere Switch emulators, yuzu, has been undoubtedly influenced by both projects. As its developed by some of the same developers from Citra, they use the Canary system to combat potential third party builds from getting the jump on the newest features. In addition to that, they also allow even earlier access to specific features to patrons through Patreon builds, which seems to be inspired by Cemu's Patreon builds.

For me, this is all a very precarious position to be in as I've criticized many of these projects over the years for their decisions. In all honesty, things are much more complicated than I original gave them credit for and there oftentimes is not a completely correct way to do things. Every project and situation is unique.

Because of that, I'm done being upset with developers for their choices on where they take their projects. These people put a huge amount of time and effort into emulation and their work is worth its weight in gold. Right now, they deal with tremendous amounts of stress and many still show so much patience in spite of it all.

We might not be able to fix everything, but we can make the emulation community a better place if we're more respectful to one another and to the people that dedicate their lives toward the emulation and preservation of games.

Two years ago, I declared that Nintendo DS was entering a golden age with several new emulators ready to challenge the established normal.

While I'm by no means declaring the other emulators I mentioned in the article as losers, one of them in particular has truly become a force within the Nintendo DS emulation scene: melonDS

On May 31st, melonDS 0.8 released and put the rest of the scene on notice: this emulator means business.  Featuring a brand new OpenGL renderer that maintains high performance even at increased internal resolutions while maintaining superb accuracy, melonDS has a compelling case to be your main Nintendo DS emulator.

A Worthy Rival

When it comes to desktop DS emulation, DesMuME has been the king for many years.  While there are specialty emulators and a graveyard of projects that have since been abandoned, DeSmuME has thrived as the dominant emulator.  Featuring high compatibility, performance, tons of customization options, filters, enhancements, and more, this is a fully featured flagship emulator.

melonDS on the other hand feels empty in some ways.  There aren't many options, but most of the important ones you'd expect are available.  You aren't going to be able to modify every aspect of emulation as you would in DeSmuME, but you can still do things like change the screen layouts and customize the gap for games that have gameplay go between screens.

The real meat of melonDS starts once you boot up a game.  melonDS has always been a high accuracy emulator, but before there was a huge sacrifice to performance.  This time around, the gap in performance between DeSmuME and melonDS has closed.  In fact, melonDS runs at the same speed on my computer regardless of whether it's at native resolution or at 8x internal resolution!

Do note while the above data is accurate, there are tons of speedhacks, frameskipping, and more than can achieve higher framerates in DeSmuME.  I used the default settings.  

melonDS's new OpenGL renderer is the biggest reason to use it over other emulators. Because it's so fast, there's no reason to not have it set to the maximum resolution right now if you even have a mid-range gaming computer.  

The one thing that DeSmuME does a lot better than melonDS is provide options to mitigate and minimize the effects of slowdown.  There is a plethora of settings I could use if my computer was weaker to make the emulator run even faster by sacrificing accuracy.  Even if there is slowdown, it's a lot harder to notice in DeSmuME unless you have performance metrics enabled.  That's because audio is emulated off thread by default - asynchronous audio.

You can change this in the settings, but I found it bit odd this was the default behavior when I was doing performance testing.  I'm very biased on this matter, but, I really dislike this being the default setting.

It's a bit refreshing that in melonDS I don't really need to worry about any of this.  I can say that because all the games were running full speed for me... but if you need that extra performance or are suffering from slowdown, it might be a bit frustrating that there is nothing you can do about it.

While I did have a great time with melonDS's renderers, it must be noted that high resolution support can be a bit wonky in games that render 3D to both screens at the same time.  Specifically in the Zelda games, I ran into issues where every other frame would be native resolution.  It doesn't look good in motion, but, you can get some rather nice screenshots!  This will likely get fixed in a future update, but it needed to be mentioned.

On top of the new OpenGL renderer,  melonDS still offers one of the best software renderers I've ever seen.  It's considerably slower than OpenGL, but, in most games I was still reaching full speed.  And considering how ridiculously accurate it is with even the most minute effects, sometimes it's worth using just to see if you're missing anything.

In the case of The Legend of Zelda: Phantom Hourglass, melonDS's software renderer is the only renderer I've seen that correctly emulates character outlines.

Extra Features

One of the main reasons I couldn't recommend any of the newer emulators back in the original article was that they all lacked important features.  melonDS isn't exactly what you'd call fully featured, but a lot of the important features that you'd expect are already there. Controller configuration is simple but works, savestates are much appreciated, and there are some necessary additions such as closing the DS and microphone that are used in some popular games.

Perhaps the most exciting feature that melonDS offers is local WiFi support for playing multiplayer games together.  This feature is extremely experimental and doesn't work all that great in many popular games.  Yet, there's just something incredibly nostalgic to see things even beginning to work.  Some games even work right now, such as Burnout Legends on DS.  Even features like Download Play are almost working.

Comparisons

Has melonDS improved since the initial article?  Of course!  Let's take a look at some of the games that were broken in 0.2/0.3 and compare them to how they look in 0.8!

Testing the games that once gave problems to melonDS proved that Arisotura wasn't just focusing on enhancements.  The base emulation quality is incredibly high and already feels like an emulator that has been around for decades.

Problems

Trying out melonDS 0.8 is what inspired me to write this article, so you already know that I absolutely loved what I saw.  Unfortunately, there are quite a few problems right now, some of which will likely be fixed sooner than later.  I ran into quite a few crashes with changing graphics settings before booting a game, and the software renderer with OpenGL rasterization appears bugged.  There's also a lack of scaling on HiDPi screens, meaning that some of the render modes don't work well.

In terms of usability, it's a lot less plug and play than DeSmuME as well.  Unlike DeSmuME, there isn't a way to HLE the BIOS or generate a firmware.   This won't be a problem forever, as long term there are plans for a BIOS replacement and firmware generation that won't require as much setup.

And obviously, some features don't entirely work quite yet, such as local WiFi emulation.  Overall though, the problems were rather minor considering how many new features have been added.

In Conclusion

If I haven't made it abundantly clear already, melonDS is a worthy addition to the Nintendo DS emulation scene.  While it may not have quite the feature set necessary to be the only thing you need for desktop DS emulation, it's definitely going to be my first choice going forward.

Was I right about the Golden Age of DS emulation being upon us?  I can't say I was correct in my supposition, but DS emulation feels like it has a bright future.  While DeSmuME hasn't changed much, it's still being worked on and No$GBA has also continued to push the boundaries with DSi emulation.  In another two years, I could easily see melonDS being the dominant emulator, or, perhaps, another emulator will make a huge leap.  Speaking of other emulators...

What Happened to GBE+ and Medusa

While melonDS has flourished, the other emulators are still around.  While not as well known of an emulator GB Enhanced+ has continued to add support for tons of obscure accessories across the GameBoy era handhelds.  I'm excited to say that GBE+ has hit the milestone of finally booting commercial DS games!

Considering the unique features that GBE+ already has, it will definitely be a welcome addition to the world of DS emulation as it matures.  Right now, it's in an extremely experimental state.  Even if its DS emulation isn't ready for the casual user, everyone interested in emulation will get something out of Shonumi's articles on their blog.  You can find everything from progress updates to feature articles that detail obscure hardware that most of us have never heard about.

Medusa hasn't changed much since my last article, but that's not necessarily a terrible thing.  The project hasn't been abandoned, it's just that endrift has been busy perfecting mGBA.  I highly suggest that you read endrift's series of articles on "Holy Grail" bugs.  They're incredibly interesting and show just how hard it can be to emulate every game in a library.  That said, I strongly doubt we've heard the last of endrift's foray into Nintendo DS emulation.

Sometimes I buy random shovelware from the store and then play it in Dolphin as part of verifying that the emulator isn't messing up. Sometimes I find hidden gems that the developers put serious effort into and are genuinely fun, sometimes I find mediocre games that don't bother me, and sometimes I find hilarious, amazingly awful games.

Transformers: Revenge of the Fallen is perfectly mediocre. In fact, if I hadn't been testing Dolphin I would have never bothered with it. For some reason I ended up beating this game in Dolphin over the course of two days so now I get to complain about it.

Shoveled onto the Wii

Some games are brilliantly designed for the Wii and take advantage of what it can do. Wii Sports Resorts is a game that I had to hook up a Wii in the living room for her to play occasionally for years. And who wouldn't hop in for a quick game of bowling every now and again? It was family event, and everyone enjoyed it.

Shovelware on the Wii usually consists of developers who have no idea how to use the Wii Remote trying to use it for things it cannot do. Transformers: Revenge of the Fallen isn't the worst kind of shovelware - it's just a lackluster port for the most part, but it decides the Wii version of the game has to use infrared and motion controls for everything it possibly can. And this game gives you no option to use the classic controller for a more traditional control scheme.

Motion Sick

Transformers: Revenge of the Fallen is one of those special games that use separate motion controls for both the Nunchuck and Wii Remote. This is particularly annoying because the Nunchuck is plugged into the Wii Remote so when you try to swing the Wii Remote to attack, the extremely sensitive Nunchuck dodge controls kick in and you end up rolling into the enemy so they can hit you instead of you getting to melee them!

The pointer aiming works well enough at first glance, but the games linear nature quickly betrays you. For the most part, enemies only spawn in front of you so this isn't an issue if you kill everything as you go. But this game has a weird lock-on system (probably controlled by a button on the Xbox 360/PS3 versions) so if you had enemies both in front of and behind you, sometimes you'll have trouble attacking the threat you want to hit.

When flooded with more enemies, aiming behind you can be an issue thanks to the camera.

Dolphin's emulated Wii Remotes can make things easier if you very carefully customize them for what this game needs. In order for nunchuck commands to work correctly, you need to use 5.0-8443 or newer. This feature wasn't available when I was playing this so I opted for USB Passthrough with soldered Wii Bluetooth chip via USB. This let me use a real Wii Remote/Nunchuck with identical behavior to a real Wii.

Also, I have to mention that between every third person shooter segment there tends to be a really drawn out on-rails segment. Whether it's Starscream flying around an arctic base of Optimus Prime falling out of a plane they tend to be too easy and way too long.

Ah yes, an on-rails shooting gallery, the best first impression for every experience.

Getting attached to the character you're playing? Now kill them!

Note: Potential story spoilers to the movie if it's based on this shitty game at all.

The story is a mess. You constantly swap between various characters. In one very annoying scene, you trudge through the city as an autobot (good robot) chasing a decepticon (not good robot), and right as you catch them, it switches perspective. Now you're playing as the decepticon and have to escape. Thanks for the whiplash.

I haven't seen the movie, but I've read enough about it to know the story isn't exactly well loved. In a video game, it's really hard to get attached to particular characters if you're constantly switching characters and having to fight them. Any potential tension in the story is ruined as you're playing both sides of it. It sucks. The opening level has you start off as Optimus Prime and then abruptly change perspectives right after a lengthy on-rails shooting gallery. Even at HD resolutions I can't tell who I'm playing as...

Based on the level name, I think this is apparently Ironhide?

The worst case I've seen is that you have to fight through this GIANT (~90 minute) long stage as Bumblebee (autobot guy) and then at the end, you switch to Megatron (main bad guy) and go to fight Optimus Prime (main good guy) who you played earlier. It can be a pretty cool thing to play as the main bad guy and defeat the good guys, but here it comes off as annoying. I didn't go through that whole base just to switch sides at the very end!

This boss battle is terrible. It's very annoying and drawn out after going through a 90 minute level that was mostly just clear rooms of enemies to open the next door. Your attacks do almost no damage to him, he recovers health midway through, and you die very fast to his attacks. Thankfully you respawn at the midpoint of the battle if you die on the second half, but it still can be hard!... Until you realize you can infinite combo poor Optimus Prime.

So after all of this, you're triumphant over Optimus Prime. So what do you do? Monologue over his dying body and... leave. Guess what, Bumblebee is able to rescue him because YOU LITERALLY JUST LEAVE HIM THERE.

I hope that was in the movie because it's honestly so bad it's hilarious. I get the trope of not checking to make sure the good guys are dead, but I've never seen it done so blatantly and so stupidly.

Emulation of the Fallen

I played this game on three separate computers in an attempt to make it run better. I started out on my i5-3570K paired with a GTX 760, but, performance was bad with my preferred settings. Sure, I could have turned on Dualcore or something like that, but, I'm testing a game. I want determinism and stability, not the chance for a random crash.

Out of curiosity, I also ran it on an i7-7700HQ, where it ran full-speed for the most part (demanding scenes would dip to ~76%) while making the fans scream. I eventually ended up doing a majority of the playing on my bigger gaming computer. The i7-6700K erases most of the slowdown and makes the game run really well despite me not using dualcore. But it begs to question, why is this game more demanding than games like Super Mario Galaxy and even Xenoblade Chronicles? Does it require Storing EFB Copies to RAM? Nope. Does it have really strict GPU timings? Nope, in fact, this game is perfectly stable on dualcore! Does this game require MMU emulation? Nope. This is a perfectly vanilla Wii game.

The reason why Transformers: Revenge of the Fallen is so slow is that Dolphin lacks proper GPU timings. On the Wii, the game is a shitty port of a Playstation 3/Xbox 360 title that used those more powerful consoles to push a higher framerate and polygon count. Instead of making a special Wii version, they just ported it over cheaply, cut out any effects they couldn't figure out, and let the framerate suffer dramatically. The game often drops to 10 FPS during action sequences with lots going on when playing on Wii!

Dolphin doesn't have GPU timings though, so, it sees all of these polygons and just pushes them right through. That's right, Dolphin will run a solid 30 FPS regardless of what is happening on screen! This actually makes the game a lot more playable on Dolphin - if you have the processor to handle it. My i7-6700K had a few framedrops here and there, but that was godsend compared to the absolute slog it was to play on Wii. Just deal with the framedrops in Dolphin and turn on audio-stretching if you must.

And remember that Dolphin supports higher internal resolutions. 480p on Wii makes the game's assets hard to appreciate where as Dolphin lets you see some very muddy textures at high resolution mixed in with some decent models here and there. As a note, FMVs start having small issues at 5x IR or higher, so you may want to keep the resolution to 4x IR or lower.

Slight FMV corruption is the only bug I found, and that only happens at higher internal resolutions.

If you want to make the game lag more like console, you can set the Emulated GPU Clockrate to ~17% and that'll make it somewhat like console. Note this number is arbitrary since Dolphin's GPU timings are so bad, and hopefully going to be different someday in the future.

Final Verdict

This was actually one of my more expensive shovelware experiences at $7 plus tax. Transformers: Revenge of the Fallen is a 7 hour story with the main campaign full of annoying segments and little fun. The two player mode is a simple arena that you won't enjoy either.

I've played a lot of shovelware in my day that is worth buying for some reason or another: Maybe it has hilarious box-art, poor writing, terrible art assets, a weird premise, or is outright broken in amazing ways. Transformers: Revenge of the Fallen plays it safe in every way and ends up so much worse because of it.

With little play value to begin with, suffice to say there's no replay value. Even at the cost of "free" I'd recommend avoiding this game.

I don't even know what to say about this game. The Wii version of, NASCAR The Game: Inside Line is one of the most interesting games I've ever played. It cost me ten dollars used at GameStop, yet I probably got over 100 dollars worth of enjoyment out of it. I bought it primarily to test Dolphin, but I quickly took a liking to it and kept it in my rotation of games. As I played it longer, I realized that I was no longer testing the game. No, the game was clearly testing me.

What exactly happened at the end there? Well, I'll get to that and much more in this Tales Through Emulation.

Third to last frame before the crash.

The Breeze Flowing Through Your Hair

On the surface, NASCAR Inside Line is an arcade racing game with all of your favorite NASCAR drivers like Danica Patrick and Juan Pablo Montoya. You drive around a bunch of the NASCAR circuits and race up to 42 other cars at the same time.

Unlike the previous Wii incarnation, NASCAR 2011, NASCAR Inside line is absolutely amazing. Unlike most yearly increments, Inside Line uses an entirely new engine, new physics, and has almost nothing in common with NASCAR 2011 (Wii). The 2011 release is a mediocre arcade racing game with none of the crazy stuff that's in Inside Line. Every single car on the track seems to have the full physics engine applied to it. The work they put into it pays off as racing alongside opponents feels just right. Compared to 2011 (Wii) where the AI cars were glued to the track, this was a huge improvement.

What exactly brought forth this huge shift?

Inside Line appears to be a port of the PS3/360 version of NASCAR 2011. While there is a PS3/360 version of Nascar Inside Line, there are certain issues in this game that make me believe it's more heavily based on the 2011 iteration.

Thanks to being a HD to SD down-port, the game looks fantastic on Dolphin when run at higher resolutions and decent on the Wii. Unfortunately, something went seriously wrong in development and the game was released in a very incomplete state. This results in one of the most memorable experiences I've ever had with a video game.

How Do You Test a Buggy Game on an Emulator?

One of the reasons that NASCAR Inside Line stood out was that I was using it primarily on Dolphin. I test Dolphin a lot and report bugs, so when a game itself is actually buggy, it makes my life a lot more difficult. I have to worry more about hardware verification, transferring save files, recording console footage, and more. Usually most big graphical bugs in games only happen in Dolphin.

NASCAR Inside Line decided it wanted to bring the party to the Wii. This game is full of incomplete features, graphical bugs, and game bugs that forced me to constantly switch between Dolphin and my Wii. You'd think something like missing car textures would be an emulator bug... but...

Some teams struggle to get sponsors. And numbers, apparently.

Nope, when upgrading the game from 2011 to 2012, they just forgot to replace some of the textures. You could probably transplant the appropriate files and rebuild the disc image to fix this if you have NASCAR 2011 (Wii/PS3/360) and appropriate file converters. The game doesn't use archives, so, maybe someone who cares could try this in the future. Considering the game developers didn't, I don't think I should hold my breath, though.

I could show several more examples of downright egregious oversights, but, I'd rather talk about them alongside the game itself rather than spoiling them all upfront. It's very difficult to play this game without running into bugs. Before we get to that, let's actually look at the main difference between playing this game on Dolphin and on the Wii.

The Difficulties of Being an Emulator

For the most part, Dolphin runs NASCAR Inside Line perfectly. Too perfectly. On Dolphin, given a strong enough PC, this game will always maintain 60 FPS no matter what's on screen. This lets NASCAR Inside Line on Wii rival the 360/PS3 versions of the game visually!

When I moved over to console to verify some bugs, I had a lot more trouble driving and it was very difficult to judge speed. Why? The game runs at a dynamic frame rate, and can drop down to 15 FPS when a lot of cars are on screen.

Dolphin's terrible GPU timings allows the game to run at a much higher frame rate than console. When someone eventually does tackle an option for more accurate timings, this game will be one of the testing candidates. While having a better frame rate is desirable to just play the game, it's important that someday Dolphin have the ability to get the correct results as well.

NASCAR Inside Line as a Game

GameCube Controller Support

This game supports GameCube controllers! On the PS3/360, you could use the R2/L2 for analog braking and acceleration as if they were pedals. On the Wii, because the triggers of the Classic Controller are digital, they didn't bother to support analog triggers on the Gamecube. You only get a digital press out of it, which gives you slightly less control than on the other versions.

Caution Flags

This is one of the dumbest things I've ever seen in a game. When a yellow caution flag happens, you almost immediately get a loading screen. A lot of times, an accident won't fully play out because the loading screen cuts it off and suddenly any sideways cars are now just fine.

After that, the game replays the accident that led to the caution. Considering that sometimes the crashes do not involve you at all, this isn't that big of a deal outside of it leading to another loading screen.

After that loading screen, you're under the caution flag driving toward pit lane. You have no control of the car, and depending on your position in the field, you have between five and 30 seconds to choose to pit or not. If you decide against pitting, you get another loading screen and a chart of where everyone is at position-wise.

Finally after all of that, you end up on the front straightaway and have to wait until your car hits the start/finish line to continue driving.

In the Dolphin demonstration above, the caution flags averaged just under a minute long without a pitstop. Depending on the course and your position they can take even longer, too. In multiplayer, if one person is leading the race and the other is in last, a caution flag can take well over 90 seconds due to both players getting the opportunity to pit!

As a kicker, because the cars are brought close together for the restart, you're more likely to get a second caution right after one ends.

My biggest problem with the game is the annoying loading screens that break up the action. If it's a simulation game, let me drive during the caution and actually plan my pit strategy. If it's an arcade game, streamline it more since I have no control over it anyway!

While NASCAR 98 didn't have quite the level of sophistication of these new games, the one thing it did well was actually make cautions work in terms of being a videogame.

No loading screens! A crash happens, the caution flag comes out and gets the field together. As soon as everything is together it's green flag. While this isn't realistic to how NASCAR did it back then (or now,) NASCAR 98's cautions have a similar effect as the cautions in a real race while making them work in a game.

Cautions frustrated me in Inside Line to the point where I turned on Dolphin's Speed up Disc Transfer Rate option and switched off the frame limiter just to try and hurry up these annoying speedbumps. Thankfully, NASCAR Inside Line gives you the ability to turn off caution flags which makes the game infinitely better.

Career Mode

This is the main meat of the game: a career mode where you can earn sponsorships and money for upgrading your car! ...Except that if you win the first race (the Daytona 500,) you get enough money to almost completely upgrade your car and turn the rest of the game into a cakewalk.

Though you have the weakest possible car, it's possible to win even on the highest difficulty. The 1080p60 demonstration was that exact case. Though I did get a bit lucky with the AI making a boneheaded mistake at the end, in the past I've won it without needing such shenanigans. This game isn't very well thought out. If it was, I wouldn't love it so much.

Challenge Mode

This mode is an utter disaster and I can't imagine why they didn't just disable it before shipping out the game. I'd normally recommend never touching this mode, but the fact it's so broken makes it a joy to play. Certain cars are "scripted" and have no physics, meaning that they follow their racing line and never diverge from it. This allows for some crazy stuff to happen.

Their lack of physics can be abused for all kinds of crazy stunts and sometimes you can gain a lot of height off of crashes or get pinched between multiple cars. This is something that'd be fixed in a day one patch nowadays, but on the Wii we thankfully didn't have that.

Multiplayer

For a change of pace, what multiplayer they did decide to include is pretty well done. The first negative is that they didn't dare try to attempt online play with this engine. Instead, they opted for splitscreen. Two players can race together with a full 43 car field if you're willing to play at an incredibly low frame rate.

The multiplayer experience is actually way better on Dolphin! If you have a powerful enough computer, you can play with a full field and two players at 60 FPS, versus running around, at most, 20 FPS on console. Three and four-player modes limit the number of cars to make things easier, but Dolphin still provides a much nicer frame rate.

In terms of functionality, multiplayer is very bare bones. There's no season mode, no multi-race championships, nothing special at all. All you can do are single race weekends. Still, you can set all the options, qualify, and go through a race weekend. The main issue with multiplayer is that the game's engine is already held together by toothpicks and rubber cement, so adding more players to the mix just makes it even more likely to break in unexpected ways.

On Bristol Raceway, there are two pit areas because the track is so short every car's pit can't fit on one straight away. There was a huge wreck in front of the correct pit area, so the AI drove around it on the track slowly. I had now lost control of my car as it went around the track to try again. During this time the second player crashed out... and for reasons I've never been able to reproduce again, the game forgot I needed to pit. It just kept driving and driving and driving. And then it ran out of gas. While I was just playing the game casually at the time and not recording, I managed to grab the aftermath of the glitch when I realized I was watching something special.

Now all of these bugs are fun... but this game managed to take my attention for the better part of a month as I hunted what appeared to be an extremely problematic emulator issue.

One of the Strangest Bugs I've Ever Hunted

I've played a lot of games in Dolphin. A lot of really terrible games. Every so often one of those games are so fascinating that I play them more than necessary. NASCAR Inside Line was a genuinely enamoring game - every single race something completely batshit insane would happen and make me want to keep playing. Sometimes it was bugs, sometimes it was crazy AI, sometimes it was just the scenarios the physics could conjure up. I was hooked. Every race was special.

This came to a head when I was playing at 6AM in the morning after getting off work. I had set the game to 100 laps on an oval track and things were actually being mostly normal. Then two big wrecks happened roughly halfway through the race damaging most of the cars on the track. This is to be expected and happens most of the time.

Then, in the sky, I saw a racecar flicker out of existence followed by Dolphin spitting out invalid read errors. Shocked, I carefully pushed through each error and then the game continued as-per normal.

I drove around the track a few more laps in a lackadaisical manner as my crew chief urged me to push harder. Unfortunately, my heart was no longer in it and I soon retired from the race. I only had one question on my mind.

What the hell just happened?

I played the game for six more hours that morning in a vain attempt to see if I could get more of these strange invalid reads. It never did, and I ended up wasting my whole day on it. After work the next day, I returned to the game and continued messing with it, and eventually, I managed to trigger it again during another big crash, this time my car was the one flying through the sky as the "Race Over" dialogue was on screen. There were two options:

• This is one of the greatest Dolphin bugs I've ever seen.
• This is one of the strangest game bugs I've seen in a while.

After over 20 hours of experimenting, I had found that it had something to do with big wrecks. Over a week later, I stormed onto IRC and ranted to people that I had managed to track it down through sheer force of will.

Max Damage State

NASCAR Inside Line is an exceedingly lazy game when it comes to damage. You can't really break parts of the car aside from the engine turning red after front-end hits, but that doesn't seem to do anything anyway.

Instead, it seems like the game has a health bar, and once you run out of health and hit "Max Damage" your car will breakdown when it comes to a rest. Except, Inside Line doesn't mandate that your car actually stops - you can continue to drive it as long as you want and actually pit to repair the damage. The normal way to actually crash out is that you hit max damage state during a crash and slow to a stop while trying to recover from a spin or getting trapped against another car or wall.

Thanks to Dolphin and savestates, I was able to attain Max Damage state and test it over and over again. Considering that there is no visible health bar, this proved invaluable to making testing easier. Here's where things get interesting: max damage state applies to AI cars as well. This essentially makes the game a ticking time bomb to crash, especially on longer races.

Car Reset Crash

When you enter pit road normally you can repair your car. BUT if you enter the pit road in an invalid manner, things go very wrong. Let's go over what happens when you stop normally with max damage state.

1. Stop the car.
2. Respawn car in pit road and mark the car a DNF (did not finish).
3. If a player's car is DNF, the game over dialogue is showed.

What happens when you enter pit road in an invalid manner without max damage state.

1. Stop the car
2. Respawn the car somewhere outside pit road and give the player control.

Both of these things work fine on their own, but, if you enter pit road in an invalid manner while in max damage state... well...

While I haven't reverse engineered the code to see what's actually going wrong, I have a feeling it's trying to respawn the car twice into two different spots causing it to fly out of bounds and potentially crash the game. The spot where you enter pit road along with the speed you hit pit road seems to affect just how violently your car flies away.

While this may seem like a harmless and fun bug to pull off, it's actually quite problematic as the AI can enter max damage state and crash into pit road. That means they too can trigger this strange game state, which in turn explains the car I saw flying through the sky. It's easy to see how testers missed this - enabling cautions means it's much harder (though still possible) to end up in a state where this can happen.

As the video at the top of the article spoiled, this glitch does indeed happen on console complete with the loud BZZZZZZZZ many Wii gamers have run into over the years when dealing with unstable games. With full MMU emulation enabled in Dolphin, you can get the correct behavior and crash the game there, instead of seeing invalid read messages. After solving this bug and proving it happened on console, I was finally free of NASCAR Inside Line.

Conclusion

I have played hundreds of games in Dolphin, and NASCAR Inside Line is one of the top five most memorable for me. I don't know how this game happened, but it is an absolute joy to play if you're in the right mindset. The base racing is actually solid, which adds to the fun when everything around it goes to absolute hell every single time I play it.

If you're looking for a great simulation of NASCAR, look somewhere else. For people like me that love spectacular disasters, NASCAR The Game: Inside Line should be remembered as one of the best. Unfortunately for the developers, their very next game would be remembered as one of the worst games of all time. In some ways I feel bad for them, as NASCAR Inside Line has definite effort and feels like it could have been good if it were completed. The developers would then stick mostly to NASCAR as the company has seemingly fizzled out.

I'm not a big Sega person, but when I saw a SegaCD unit for cheap in a Goodwill, I had to grab it. I had this vision of playing all those weird FMV games I've seen so much about but never played. Alas, it was broken and I was forced to return it. But with the cash on hand, I snagged a Sega Saturn the very next day, and after replacing the cmos battery, it was as good as new!

While I keep up with gaming pretty well, all I really knew about the Saturn was that it was Sega's entry into the Playstation/N64 generation of game consoles. As such, that's about where I set my expectations.

Saturn First Impressions

The Saturn made an excellent first impression. It has a pretty nifty BIOS screen, and the cheap games I bought with it oozed 90s nostalgia. Daytona USA screamed 90s with the music and menus and it just made me smile!

The BIOS is aggressively 90s.

The cheap sports games I bought alongside it were just as amazing, jam packed with low resolution FMVs and a mix of (mostly) 2D and 3D assets. Loading times were atrocious, the games were simple and I was loving it! The Sega Saturn controller is a bit strange after using modern controllers for years, but it did a well enough job at letting me play the games.

Hands on with the Saturn

Once the initial burst of 90s wore off, the limitations of the Saturn quickly came into focus. To get a good look at the Saturn, I spent way more than I'd care to admit at getting a decent library of games.

• Daytona USA
• Daytona USA: Championship Circuit Edition
• Wing Arms
• NFL Quarterback Club 96
• Grand Slam
• Nascar 98
• Virtua Cop
• Center Ring Boxing
• Mega Man 8
• Virtua Racer

Just as a clue in terms of pricing - Mega Man 8 cost almost double of all the other games combined. If you're going to be buying complete Saturn games, be aware that many of the cases are broken.

Buyer beware online - many sellers will say their game is complete, but not mention the broken hinges.

The bottom tab seems to be broken on almost every Saturn game I bought, sometimes from the front cover, sometimes the actual hole is broken off of the main part of the case. To get a case without damage costs almost twice as much for most games!

The Japanese Saturn games I have (not used in this article) do not suffer from this problem, as they use the same style jewel cases as the PS1 and Dreamcast. My best guess is that these cases are some kind of marketing disaster holdover from the SegaCD.

Saturn Emulators

Nitpicking aside, this article is mostly about the games and emulation. There are three main emulators for the Sega Saturn that I'll be talking about some level throughout the article.

• Yabause and uoYabause
• SSF (unofficial site)
• Mednafen

While SSF is considered the best by many guides, I'm not using it. It requires the use of a CD emulator that contains adware/spyware, and while I could probably defuse the program, I'm choosing not to. If the emulator doesn't care enough about its users to avoid an adware riddled program, then why should I go out of my way to use it? Is it too much to ask for some form of ISO support like almost every other emulator?

To be fair to it, I did try to use a standard CD emulator, but it doesn't support the features that SSF needs. So, I couldn't get any games running on SSF, but I did at least throw the Saturn BIOS at it. Emulation of that seemed solid enough but there obviously wasn't much to look at.

With SSF disqualified, I went forward with Mednafen and Yabause (along with uoYabause). I've had some exposure to Mednafen, though it was many years ago and mostly for netplay purposes. Since then, Mednafen has added many more cores, including an extremely popular (and accurate) PSX core and more recently a highly touted Sega Saturn core. It's actively developed and recently added features like savestates to the Saturn core along with bug fixes and other nifty changes.

To checkout mednafen, follow this link!

Yabause I have little experience with either. My only time using it was to run it on Dolphin because I'm dumb. Yabause itself is dedicated Saturn emulator that's been around for a long-time and has several forks. It's usually recommended as a secondary emulator after SSF or Mednafen.

To checkout yabause, follow this link!

Regardless of what emulator I used, I had a difficult time getting them to load anything! If you dare give them a completely valid dump that you verified works on another emulator that they don't want, be prepared to try and guess what's wrong.

• Mednafen just says the file size is too big for the disc image, which is at least a clue toward what's wrong.
• Yabause runs the bios and acts like you've inserted an invalid CD, which makes sense if it can't detect it, but isn't especially helpful.

My only recourse is to maintain two sets of dumps, one for each of the emulators. I find this utterly ridiculous, especially after the troubles I went through with SSF. Talk about a bad first impression! I nearly abandoned the emulation part of this article before booting a single game. To assist users who maybe having the same problems as me, Yabause wants a single .bin alongside a single .cue style ISO. I have not yet gotten a multi-track .bin file to work in Yabause.

Mednafen is the opposite. It wants multi-track cue/bin files, with some being split into dozens tracks. If you feed it one with all the tracks combined into a single .bin, it will refuse to load it. In Mednafen's defense, this is how redump recommends ripping Saturn games, so I consider the ones dumped like this to be my "official" collection, and the other set to be temporary for testing Yabause.

With all of that finally out of the way, let's get to the meat of things and look at the games.

Daytona USA and Daytona USA Championship Circuit Edition

Daytona USA was a must play for me. The family owned bowling center I all but grew up in had a Daytona 2 arcade cabinet, and after putting in countless quarters I discovered the panel on the back was loose and I could hit the switch to insert credits without money. As such... I played it a lot before it was replaced with a less interesting game.

During that time, I got really good at the game, memorized all the tracks and could win on any of them. I still remember finally beating the combined super course after weeks of trying and sitting exhausted as the credits played out.

Compared to the thrill of sitting in that plastic orange seat, holding onto that heavily worn down wheel and flying through the (then) beautiful courses, Daytona USA for the Saturn was a bit of a disappointment. That doesn't mean I didn't enjoy it, as there was still arcade goodness to be found!

Daytona USA is a port of the original arcade Daytona USA. The Super Model 2 Arcade Unit was much more powerful than the Saturn, thus the people porting the game had to do quite the job to get it running. The graphics have been stripped down greatly in every regard.

Daytona USA - Arcade

Daytona USA - Saturn

Not all is lost! The soundtrack is still fantastic and the game does bring the arcade classic to your home console, even if it's hard to see with such a terrible draw distance.

You can even see a floating object rendering at the edge of the draw distance.

The draw distance and frame-rate actually make the game a lot more difficult, as the more complicated tracks will have a lot of blind turns that are fully rendered far ahead of time on the Arcade version. At 20 FPS, judging speed and distance is a pain, and it's still liable to lag even more when there are tons of cars on the screen.

Championship Circuit Edition released a year later and was a second port of Daytona USA. Many of the biggest complaints I had about Daytona USA were fixed, with a much improved draw distance and frame-rate. As an added bonus, you get more tracks, multiplayer, and other features to keep you coming back.

A third variant also saw store shelves and added networking support so players could race with their own screens. While I'd have loved to give that a try, setting it up was far too expensive to justify. If you're interested in it, there are some videos online showing it in action.

Daytona USA - Bridge Ends Ahead!

Daytona USA: CCE - Look at the extra details and draw distance!

Daytona USA: Championship Circuit Edition is an easy recommendation if you want a fun game to pop in once in a while to show off the Saturn to friends. While the Dreamcast has a far superior port of Daytona USA, I actually find it more interesting to see the multiple efforts to squeeze it onto the Saturn's meager hardware.

Emulation

We're going to get into a bit of a touchy subject with these emulators right away. Daytona USA is a launch title, and both Yabause and Mednafen more or less take care of business. There aren't any graphical issues, sound issues, or anything that most people would say are flaws...

But, neither of them accurately bring the full Saturn experience to my computer. The frame rate is much higher on the emulators and loading times are cut down to nearly nothing. Now this would be fantastic as a feature to make the games play better, but after digging through the emulators I couldn't find any way to make the timings more accurate. While many people won't care, I definitely do.

In terms of undeniable bugs, Championship Circuit Edition does have a notable, if fairly minor issue in both emulators. The cars are slightly offset of the track map.

This would look better if these cars were designed for offroad racing.

Console manages to render it right, confirming the emulator bug.

For those who want performance, Mednafen wiped the floor with Yabause, able to maintain more than full speed on all of the tracks while Yabause struggled. Yabause does have the option of using OpenGL to greatly increase performance, but it ends up losing some graphics, such as the car shadows.

The shadows are missing but the performance is way up.

NFL Quarterback Club 96

This game is really something else. I let two AIs go at each other for a full game, and they managed to accumulate negative 216 yards in a 7 - 0 snooze fest. Running the ball is useless, making the game very unbalanced.

This feels like it could be a genesis game except for a barely 3D field, football, and goalposts. Even with just that, the Saturn likes to lag when it zooms out to show the field.

The best part of the game are FMVs that will interrupt most plays to show a referee's call on the play. While the game does allow you to disable them, features like these show how desperation to use the Saturn's full abilities could actually make a game worse. They are worth a pretty good laugh, though.

I also discovered a neat game bug, where if you put the camera too far into the end-zone, you'll encounter some garbage graphics that randomly spawns out of nowhere! This only seems to happen on console.

The underrated sequel to Angels in the Outfield - Ghosts on the Gridiron

Emulation

Yabause had significant issues emulating this game, but nothing that made it too unplayable. The sprites would have some garbage around them and the end-zones had some texturing issues. Also, if you need performance you're out of luck this time, OpenGL falls flat on its face with the field getting a mind of its own.

On console, the flipped endzone graphics are not rendered back there.

OpenGL may not be very accurate, but it gives life to a fairly boring football game.

Mednafen fared much better, with only some annoying flickering during some of the intro FMVs.

This would be a much more disturbing sight if it were a censor bar rather than an emulator glitch.

Grand Slam

Much like with the football game, we have 2D players on top of a 3D field. Honestly, this game looks way better than the football game with more detailed sprites and much more detail in the stadium and backgrounds. The game does look pretty good in spots.

This game actually has an early form of modern sports game commentary, with a play-by-play announcer. Aside from an Intro FMV, the game also has animations play on the Jumbotron when certain things happen in-game, which is a lot less annoying that the referee showing up every other play in Quarterback Club.

Emulation

This is a game that works fine in both emulators, but at the same time is problematic due to their limitations.

I highly recommend you play this game on console because both Saturn Emulators have a lot of input latency. Consider that playing the console through my capture card was less latency than either emulator.

I've seen recommendations on r/emulation to use a different frontend to reduce input latency, but, I'm not going to increase my scope any bigger for the purposes of this article. Of the two emulators, it seems like Mednafen has lower latency, but I didn't do any actual measuring. It just was easier to time the pitches overall there.

Center Ring Boxing

I thought this game was going to be terrible. The first time I played it, I got frustrated and gave up after just a few minutes. Later on, I played it more, learned what it wanted me to do and still disliked it. Strangely enough, after a while I got into the flow of a match and found it to be pretty tolerable.

I played this game with a friend watching and in this case our opinions differed. I thought the game looked really bad, but he thought they did a great job on the character models considering the limitations of the Saturn. I'll leave it up to you to have an opinion.

The game opts for full 3D characters, something most titles avoided.

Even if you think the character models are decent, it comes at the cost of pretty much any other graphics. The crowd is pretty much non-existent, most of the background is a solid black, and the framerate can still tank if everything manages to get on screen at once.

The controls are the biggest problem. Movement is difficult, moves have incredibly long warmup and cooldown frame windows, and the button combinations are a bit awkward to hit to access some of the stronger moves. The easy control scheme helps a bit, but, even when all the moves have their own button it's still a chore to play. As a neat aside, the game does feature a ton of different camera angles, including my personal favorite, Crotch Person View

I have no idea why they programmed in this camera view, but I'm very happy they did.

Joking aside, the game actually works and sometimes the fights manage to have a nice ebb and flow, forcing you to switch strategies depending on who has the advantage. It's more than I can say about most of the boxing games I've played over the years.

Emulation

The emulators do a pretty serviceable job once again. There are no obvious visual glitches, and because the game didn't lag much on console, it behaved roughly the same overall. I recorded a fight in emulator and it honestly looks pretty spot on with how it played on console.

The only noticeable thing was weird graphics on the main menu. If you haven't played the game on console you may think the flickering untextured characters were a glitch, but no. That's actually how they look.

I took this screenshot on console just to be sure!

Wing Arms

Wing Arms is probably the most interesting of the games I got.
It's better than the sports games by a healthy margin, but still a very flawed game in some respects.

This game has a ton of pre-rendered footage, and honestly it's great. These eye-popping, awkwardly animated scenes look so silly yet it's fun to imagine 90s gamers thinking they looked badass back in the day. And nonsensically enough they decided not to pre-render one scene and it turned out even better. Enjoy.

I don't know how something like this happened, but I'm eternally grateful that it did. Aside from that, the game actually looks damn good for a Saturn title. The draw distance is absolutely fantastic compared to the competition and the framerate is solid most of the time.

The game has an impressive draw distance.

But even in this thumbnail you can see just how many details load in as you get closer.

Upon closer examination, you start to see the sacrifices developers made in order to achieve those merits. The objects in the distance are untextured and made of very few polygons. This was a problem in games of the era, but, what makes it so frustrating here is that it impacts the gameplay, too!

The bases that you're periodically asked to attack have weakpoints on them. These weakpoints do not render until you're extremely close. You can shoot the base all you want and not do any damage unless you hit the turrets placed around it.

Even this close and you can't see the five targets on the base I'm supposed to be shooting.

After you figure out where the turrets are placed, the bases are easy to take out.

In terms of scope, the game actually has three separate terrains: Mountain, City, and Ocean. No matter what map your on, the base terrain is flat and all that's added are some details on top of it. City ends up looking the best because the lack of detail is harder to spot. Mountain... well...

City looks pretty cool and has gigantic super bombers and many small planes shooting at you.

The Mountain is flat and the walls pop in roughly two feet from your plane most of the time.

If you're looking to show off the Saturn, Wing Arms is an excellent tech demo and not all that horrible to play. As a game to seek out and buy, it's hard to recommend. While there are multiple planes, each campaign is exactly the same and only lasts 40 Minutes assuming you don't run out of lives. On the positive side of things, if you have a Sega Saturn Flight Stick, you're in luck, as this is one of the few games to support it!

Emulation

This is a game where I really have to bring up timings again. The game on console is almost constantly running slower than it should be. During the final boss fight, it regularly tanks down to single digit frames per second!

On an emulator, while the game does slow down during a few of the boss fights, it's not nearly as much or as often as on console. If you're just looking to play this game without caring about console accuracy, this probably thrills you. For me, it's a bit disappointing, and I'd love to now if there was a setting to bring me closer to the console timings.

In terms of glitches, Mednafen had some garbage on the edge of the FMVs, but did a very good job overall.

Yabause has the same garbage on the edge of the FMV as Mednafen, but overall looks fine... until you get in game.

The garbage in the skies makes it very hard to see and the lack of a clear horizon makes keeping yourself steady hard.

While it may look like it's raining, that's actually a ton of visual garbage and it's extremely hard to see or play the game. The game doesn't crash, but it's still left completely unplayable. While I should have just moved onto the next game, I kept messing with the emulator hoping to at least affect the glitches.

After exhausting Yabause's options, I decided to give uoYabause a spin and see if maybe the improved OpenGL rendering there would prove key. While uoYabause is designed for phones, featuring an ARM recompiler and an improved OpenGLES backend, I was hopeful that maybe it'd be able to run this game.

Despite low expectations, it managed to do even worse than I expected. Nothing 3D renders, meaning that many scenes are left broken. The game doesn't crash, but with no enemies to shoot, no sky or ground rendering, you're left flying blind.

uoYabause's software renderer fails to impress with this game.

After some poking around, I realized that uoYabause has more or less left the software renderer to rot. After testing several games, I came to the conclusion that it's a broken pile of garbage they don't really care to maintain. Much like Dolphin's software renderer.

Instead, they have put all their eggs into the hardware rendering basket, and to their credit it performs better than the OpenGL backend in mainline Yabause. That's not saying much.

The entire squadron was deployed for one more battle, unfortunately, they stood no chance.

Just to verify, this is how it's supposed to look on console.

After that amazing sight, I was hyped to see how uoYabause would fare in-game, but it disappointed me one last time for good measure and crashed before loading the actual level.

I really can't recommend uoYabause for anything outside of Android. It's a lot buggier, it likes to have audio errors when switching games, and the increase in performance doesn't matter much when the games don't really work. I know I only showed Wing Arms here, but I did try it across the rest of my library and found these kinds of situations were common.

Changing Things Up

Now for the most expensive (and hopefully illuminating) part of the article. We're going to change the rules a bit; we're no longer going to be comparing just console and emulator. Now we're mostly going to be comparing Saturn games to their Playstation counterparts, while still noting any emulation issues along the way.

While we already know how history played out, can the multi-platform titles of the day stand tall on the Sega Saturn?

NOTE: Because this article is primarily about the Sega Saturn, I will not be using any Playstation emulators. All Playstation footage was recorded from a PS2 using component cables, only because my composite cables were giving me significant interference on the signal. I bought S-video cables for my Saturn to try and make the signal quality gap as little as possible.

Mega Man 8 - Anniversary Collector's Edition

Mega Man 8 is a game that looks and feels like a legitimate console game. It avoids all of the pitfalls of being a game released on Saturn, mostly because it doesn't require a ton of 3D horsepower to run!

Mega Man 8 - Sega Saturn

Mega Man 8 - Sony Playstation

Mega Man 8 - Sega Saturn

Mega Man 8 - Sony Playstation

Ignoring some signal quality differences, the Playstation and Saturn versions of Mega Man 8 more or less look identical. While there are some loading time differences here or there, it's not enough to really affect the experience.

While the Saturn controller has a different layout than the Playstation controller, the game plays fine regardless. You can even customize the controls a bit in the options if they don't suite you, so there's not much of an advantage to either console here.

In terms of graphics, one of the most commonly cited weaknesses of the Sega Saturn is its inability to do transparency. In Mega Man 8, it's obvious that developers were forced to work around this limitation by using checkerboarded empty dots on things that were meant to be see-through.

Mega Man 8 Energy Bar.

Except, I took that screenshot from the Playstation version. While the Playstation version was technically released first, Sony was strongly against 2D games on the PS1, especially in the western market. Perhaps sensing the friction, it seems that the Saturn version saw a bit more love.

Mega Man 8 doesn't rely on anything that would compromise the Saturn version against the PS1 version. Transparent smoke flickers instead of fading away, explosive bits flicker, and UI elements are checker-boarded on both versions of the game.

On top of that, some features were made exclusive to the Sega Saturn version. Some music differences were present, but that's only notable because the Playstation version ended up being so dominant. I honestly prefer the PS1 soundtrack after playing through both. There's some bonus concept art missing from the Playstation version and two hidden bosses are only available in the Saturn version.

The extra boss fights are nice...

But the bonus menu made the price worth it.

Because the Saturn flopped so hard, it's extremely expensive to pick up a copy of Mega Man 8 for Saturn. If you have the money to burn, it's a neat collector's item and a very slightly better version of the game. And considering the limited library on the Saturn, it's one of the better titles you can get.

Emulation

As a note - Playstation emulators do a fine job on Mega Man 8.

Saturn Emulators also do a pretty good job on Mega Man 8. The only nitpick is that the image is so clear, the fake transparency used throughout the game is a lot more obvious than on console. That's not exactly the emulators problem, and can be solved with some filters if you're into those.

The other note is that there is a bit more input latency than I'd prefer for a game like this. It's still very playable, but the infamous "Jump Jump, Slide Slide" section can be annoying. Using a controller can help with latency (a common thing in emulators on Windows, mGBA shares this trait.) That brings it to slightly more latency as my capture card, which I previously measured as roughly three to four frames of latency when working on a project for Dolphin.

Just be warned that some of the more difficult platforming challenges may be a bit awkward in emulator.

Nascar 98

Head to head in a 3D title put out by EA sports in the 90s, could the Saturn stand up to the Playstation?

Nascar 98 Saturn

Nascar 98 Playstation 1

While it puts up a pretty good effort, the Saturn just can't compare to the Playstation in a 3D title. It's immediately noticeable the Saturn is going to struggle - on the Playstation, the menus are crisp and responsive while on the Saturn, they are choppy and regularly miss inputs. Loading times end up a lot worse on the Saturn, sometimes taking over twice as long as my Playstation 2 (without the speedup loadtimes feature for PS1 games.)

While that may just be developer incompetence, the actual game does work and plays about the same on both consoles. In fact despite its limitations, Nascar 98 is one of the nicer looking 3D Saturn games I have.

In terms of features, the Playstation heavily relies on transparency for much of the graphics. Saturn version is forced to either drop these elements or completely black them out.

No transparent box on the Saturn version.

PS1 version has a transparent box around the flag.

You can't see through the Saturn speedometer.

You can see details through the Playstation speedometer thanks to transparency.

On the other side of things, Nascar 98 is an average looking PS1 title at best. The Saturn version has less polygons, a worse framerate, and missing transparency effects. But it does have all the features, even the multiplayer mode! To do that, it strips down the game to the bare minimum for graphics.

You may not immediately realize it, but number 24 is actually upside down and you can see it has no bottom and flat wheels. To get multiplayer running, cars are made of very few polygons.

Emulation

Nascar 98 is a port, so, it can run at a much better frame rate on the Playstation version with more power. Thus, it shouldn't come as a surprise that the Saturn emulators unlock that same potential, bringing us a solid 30 FPS no matter how much lag it'd have on console.

Loadtimes are also way too fast. Loading typically takes 27 seconds on console, where as Mednafen usually loads a track in 8 seconds.

I did not notice any visual or audio issues in my time with this game, and it is fairly well emulated other than those timing issues.

My Thoughts on Saturn Emulation

After spending nearly three months with the Saturn, I can confidently say that it's not worth going out of your way to emulate Saturn games. Unless you have something you absolutely must play, there's just too many hurdles and difficulties to recommend it. Experienced users who are more than willing to bang their heads can get some value from it because the actual emulators are actually pretty good once you figure everything out.

You're going to want a fairly beefy machine. My Core i5-3570K had no problems running the games full speed most of the time, but, considering when I disabled the frame-limiter, I was maybe hitting 150%, I could see many user's computers struggling here when they can run other emulators of more modern consoles.

Mednafen really impressed me with solid emulation overall and clearly outclassed Yabause in my test cases. It also supports the disc format that redump.org considers correct and is even faster than Yabause in the games I did experience slowdown. It's under active development and has even improved soundly since I started this article. I definitely recommend giving Mednafen a spin if you're going to get into Saturn emulation.

Yabause isn't a pushover though, and definitely has a more pleasing UI for casual users. The problem is that Yabause's performance and accuracy didn't live up to expectations. On top of that, tons of features didn't work as advertised. Full-screen cut off a ton of graphics, touching anything while a game was running risked crashing the emulator and it doesn't even support the disc format recommended for archiving.

That said, Yabause isn't a bad emulator either and I can definitely see using for spot cases when the other emulators fail.

uoYabause on the other hand is not ready for mainstream use. If you're looking for a great way to play Saturn games on the go, look elsewhere. If you understand that this is a work-in-progress and you will run into issues, then you'll probably be able to get some enjoyment out of it, especially on phones.

The fact it runs as well as it does on Android devices is very impressive, and if they manage to make things more accurate, it could potentially be an option for people on weaker computers. The potential is there for something special, it's just yet to be seen if it will attain it.

My Thoughts on the Saturn

With inferior graphics, a lackluster library, and a high price, the Sega Saturn bombed without much fanfare. Everything good about the console is just offset by how weak it is compared to the rest of the generation. It feels like the power it has is wasted because it's not strong enough to really do full 3D adventures like its competition.

I just didn't get what Sega was thinking making a console like this... until a friend pointed me in the right direction.

Since the Genesis, Sega had been making incremental improvements to the console with add-ons. The Sega CD gave it CD Music and FMVs, the 32x gave it more power to do visual effects like scaling and output better 3D graphics! The Saturn puts those ideas together with a bit more power, able to do basic 3D, CD music and FMVs fairly well. If we look at Virtua Racing, a game that came out on the Genesis, 32x, and Saturn, you can see them slowly make their way toward modern graphics.

Virtua Racing on Genesis

Virtua Racing Deluxe on Sega 32x

Virtua Racing on Saturn

The problem was that while Sega was busy taking baby steps, Sony and Nintendo made the leap. Thus, the Saturn was left behind as the 3D age took hold of gamers across the world.

RPCS3's Patreon account may not have been suspended or shutdown, but a huge blow was dealt to the emulation community. Atlus, the developers of Persona 5, have used threats to RPCS3's cashflow in order to get the team to remove any mention or media of Persona 5 removed from their website. Patreon stood up for the project in this case, and did not shut down the account. But, they did recommend all Persona 5 media and mentions were removed from their Patreon and their site. RPCS3 complied, and thus the Patreon page still stands, albeit censored of content thanks to Atlus.

“The PS3 emulator itself is not infringing on our copyrights and trademarks; however, no version of the P5 game should be playable on this platform; and [the RPCS3] developers are infringing on our IP by making such games playable” - Atlus

While this is a disappointing turn of events, it's not exactly shocking. Atlus was extremely protective over how people streamed the game, not caring if people were enjoying it, but how they were enjoying it, too. As someone who has bought games from Let's Plays and listening to music online (including Etrian Odyssey 1 - 3, another Atlus property...), this kind of behavior is frustrating. I've literally bought their games brand new specifically to use in emulators.

The best response to this I've seen was from one of my friends, "If you don't want Persona 5 to run in PS3 emulators, don't release it on PS3." And I'll take it a step further - don't release it on PS4 either. What if there's a PS4 emulator in the future that lets it run on PC? Hey! That solves two problems at once - now you don't need to worry about streaming, either.

In fact, stop making your games altogether; that way you'll really get back at all of those people who love your games and tried to support you, too! Everyone loses, just like they do thanks to your actions today.

Repercussions

Whether or not what Atlus is claiming is true (spoiler: it's not), all emulators are now in danger. By bowing to the pressure, all publishers now have a blueprint on how to attack emulators on Patreon. It's an old-school tactic; if you don't like what someone is saying, don't attack the person, attack their livelihood.

The disappointing part to me is that RPCS3 caved. Money is important, but it feels like they were more than happy to throw away their rights in order to keep taking in their (admittedly substantial) income from Patreon. That begs the question: at what point is it not worth it?

What if Nintendo says the same about cemu and Mario or Link? They go crying to Patreon that cemu infringes their IP, even if it's not illegal. With how much money they make on Patreon, they'd be forced to do whatever the site wanted in order to keep the revenue coming in. There are tons of emulators on Patreon, from mGBA, MelonDS, cxbx-reloaded, to frontends like Retroarch.

While it's unlikely any one will bother an older emulator, with the way emulated titles are now being sold again by Nintendo (and yes, Sega and Sony with their classic lineups), there's a definite danger to any emulator or project.

This could deal a major blow to emulation. As a (small) part of Dolphin, one of the things I thought about was "What if Dolphin had a Patreon, what would the project be able to do with the money?" The answer was - maybe more infrastructure stuff? But ads on the site already cover the buildbots, hosting, automated tests and much more. There really wasn't anything to be gained by joining Patreon. And now, I'm extremely happy the project doesn't have something like this hanging over it.

If I'm an emulator that needs Patreon money to survive, I'm worried right now. Patreon didn't cave to Atlus, but what happen if Nintendo suddenly decides, "Hey, this emulator infringes on our IP because it says the name of our console on its website." If you're relying on Patreon related income, that's a serious problem, and I don't know what happens. Hopefully, it never gets to that point.

Where to go from here

Gaming takes a blow on this day, not just fans of emulation. Preservation efforts, mods, and other gaming projects survive on Patreon. If a big company doesn't like what you're doing, they can cut off your revenue. It may come as common sense, but, it seemed that for a while Patreon was this magical way to get more money from users without any backlash.

Now it appears this dream is over and the harsh reality has set in. Patreon is now a means to control emulators. I'll leave this here for everyone else.

RPCS3 can run Persona 5 at higher resolutions than even the PS4 version. I highly recommend you play it on PC instead of on console.

Every time there's a huge feature merged into Dolphin, I always say in the dev channel, "I never imagined X would work in Dolphin before Red Steel." Ubershaders, Dragon Quest X, Majora's Mask (VC) and even the Wii Shop Channel have all been conquered. Yet this 2006 Wii Launch title remained unplayable until... now.

Dolphin 5.0-5395 brings compatibility to Dolphin. Feeling that there was some importance to it, I kept a running diary going as Leoetlino began his dive into a game that has baffled developers for years.

The Ballad of Red Steel

A Symbolic Gesture

Some of the easiest games to debug come with symbol maps. These symbol maps allow developers to look inside at what would be a mess of instructions and addresses and see actual functions and names to what they're doing! For a game without a symbol map, the hardest part of debugging difficult bugs can be figuring out what the game is actually doing.

Red Steel includes no symbol maps and the executable is stripped, meaning that we have no clues for figuring out what the game code is actually doing. Nintendo has an awesome habit of including symbols with a lot of their games, and that has made debugging games like Wind Waker much easier in the past. To go at a game without symbols increases the difficulty tenfold.

In one of Dolphin's first articles, delroth thanked Nintendo for including a symbol map while debugging Wind Waker's heat effects! Click here to go to Dolphin's blog and read more about how he reverse engineered a texture bug.

Before You Know It: ES Launch

The second most annoying thing is that Red Steel immediately ES_Launches a second executable right after booting. This is because their .dol is too big for the default apploader.

Red Steel also uses ES_Launch whenever loading any of its demo videos strangely enough... but it ends up booting the same dol that was already running. Huh.

ES Launch is a huge problem for debugging on hardware as Gecko Dot Net loses all hooks after an ES Launch. As amazing as all of the debugging options we have available are for GameCube and Wii games, ES Launch is one of the few things nothing seems to handle that well.

This is a fairly difficult situation to handle, but there is a feature designed to help.

Neogamma is one of the few loaders that support both alt-dol and Gecko hooks.

Alt-dol lets us use a different dol to boot various discs, and in most loaders we can just tell them to directly load the main game! While Gecko OS doesn't support this, Neogamma does and is how I previously had dumped OSReport messages from Red Steel earlier this year.

Power Off!

Thanks to analyzing other executables on the disc and a blind guess, we got the idea that maybe Red Steel was writing streaming audio files to the NAND and then streaming them from there.

Because Red Steel was developed on an earlier devkit, it's possible that they had designed their game to take advantage of GameCube features like DTK audio that no longer work on the Wii due to it having encrypted discs. As such, a potential work-around for this would be to copy the music to the NAND and stream it from there!

What the game would do is copy it to the tmp folder, so all we'd have to do is load the game and check the tmp folder, right? Wrong.

The tmp folder is cleared whenever IOS resets, meaning by the time the system menu is loaded the next time around, it's gone. Even turning off the console would cause it to clear! So how do you get it?

By unplugging the Wii and using a boot1 hacked Wii, we can manage to dump the NAND before the tmp folder is cleared. By dumping the NAND and checking it on our computer, we can see if Red Steel has copied any music files to the NAND for streaming. Unfortunately, this bared no fruit, all that was there was the Home Button Menu that pretty much every game would put there.

It seemed as though we were out of options on this route...

A Look to the Past

Leoetlino then came up with an exception. We couldn't be sure, what if the game copies the file to NAND, loads it into memory, and then deletes it. That would mean that we couldn't be sure that the game wasn't doing it.

Then, an ancient post on hackmii explained we could see the last 16 file operations of a NAND! Because we powered it off and could boot right into bootmii, the last few operations should be Red Steel's history!

After analyzing the NAND, we concluded almost that Red Steel is not streaming audio from the NAND. We were again out of options after having so much hope on a potential lead.

Leftovers

A ton of games have left over content on them from development. The Cutting Room Floor is full of various content. Some of that content has been extremely interesting. Pikmin includes a Windows executable that can run the game on standard PCs, albeit with some content/effects missing!

Red Steel didn't appear to have much interesting until leoetlino took an extremely close look at it and took a shot in the dark. There were some other elfs on the disc that did have symbols, but they were unused. The symbols within the executables looked as though they could be for the main game, so could it be possible to hook them back up to Red Steel?

The first attempts were failures, and then a Dolphin bug caused more issues, but eventually he managed to get one of the debug executables to load!

The 1.97.2 Debug Version has tons debug info not in the release version.

And remember, this debug executable was complete with symbols! If we could get in-game with this, we could look at the code the game was running with function names and other information intact. Unfortunately, it freezes just as it's loading the main menu due to missing files. But the NTSC version had three executables on the disc... would the third try be the charm?

Retail PAL Version     - 1.97.3 Release
Retail NTSC-J Version  - 1.97.3 Release
Retail NTSC version    - 1.97.2 Release
WarefareRevoRetail.elf - 1.97.2 Debug (within NTSC Sys folder)
WarefareRevoReader.elf - 1.97.1 Debug (within NTSC Sys folder)

Interestingly, because the PAL and Japan releases came out later, the debug executables are gone on those discs. They also use a newer version of Red Steel's engine than the NTSC version.

With the 1.97.1 debug version being the last hope, Leoetlino tried one last time. Luckily, this executable would not only boot, but we could get into the main menu and to the point of the hang without issues!

When monitoring this executable in Dolphin, it was very apparent that it had a lot of left over content. Stuff like player statistics, port numbers for online play, as well as the messages displayed for kills/suicides in Unreal Tournament are within the strings. These symbols meant we had a chance to examine the game code and see what was really going wrong.

A Game That Has No Idea It Failed

With symbols in hand, Leoetlino dove into the Red Steel's core, examining how sound worked. Unfortunately, Red Steel is poorly coded with nonsensical design, making it difficult to figure out what does what.

He was forced to patch Dolphin in order to dump the relevant data from the game, eventually figuring out a workflow.

game -> UDareAudioSubsystem -> DM subsystem -> ??? -> SND -> AX

DM Subsystem seemed to be working correctly upon examination, and so was SND, which left the step in-between. Examining what the game was doing led to the realization that the game had no idea something was going wrong. There were no extra errors thrown, none of the systems were failing. It was proceeding as if everything was working correctly... which made it much harder to track down where things were going wrong!

A Ray of Hope

After another two straight days of debugging and going through exactly how Red Steel handled audio, leoetlino had reached the point where he was understanding the nonsensical programming of this rushed launch title.

This is as far as the game could ever get in Dolphin. She'd wait for you to turn around... forever.

He discovered that the game thought 4 audio files were playing. Two of them we could hear - her footsteps and the footsteps of a waiter walking by. The other two weren't sure on until we listened to it on console. One of them is the woman's voice, and the other is the hum of a fishtank behind you. Those do not play correctly on Dolphin.

This meant that the game thought they were playing. With no clue what was wrong, we decided to take another angle.

Homebrew to the Rescue

The Wii has a wonderful homebrew scene with tons of tools. When I was getting into emulation and attempted to do testing for PCSX2, one of the things I wanted to do was get homebrew running. While I did succeed, the homebrew sucked and it the process of testing things was incredibly annoying. Without good homebrew support, fixing games correctly is a pain in the ass.

The Wii has incredible homebrew support. To run a homebrew, I don't even need to do anything. A boot1 hacked Wii with BootMii can boot into the homebrew channel, then I can connect to it directly with TransmitMii or another loader over Wi-Fi. Then the homebrew runs directly on the Wii without me touching a controller.

The Homebrew Channel is so well designed you could easily mistake it for an official Wii application.

Unfortunately the Wii I received for my birthday in 2006 stopped working during testing this, and I had to use a Wii without the boot1 exploit. That meant booting the Homebrew Channel from the Wii Menu, meaning I had to setup a sensor bar and get batteries for my Wii Remote. Nintendo not allowing me to use the GameCube controller in the system menu has probably cost me fifty dollars in batteries over the years...

One of the things I purchased a long time ago with a Shuriken USB Gecko clone. The USB Gecko is the ultimate tool for debugging on the Wii and GameCube. You plug it in through the memory card slot, and then can directly hook into games! Using Gecko Dot Net, I can view the GameCube/Wii memory, place breakpoints, and even get screenshots directly from the embedded framebuffer!

With access like this to the game along with symbols, we would stand a chance of solving this ancient bug.

This is where we hit a bit of a hitch - Leoetlino was debugging from the debug executable, while I could only use the retail executable using alt-dol. I tried using one of the elf files, but Neogamma scoffed at the idea of using those.

For some reason, alt-dol just doesn't support elf executables. Without the ability to hook into the game were were again stuck just looking at the output in Dolphin and hoping something looks incredibly wrong.

If it Doesn't Exist, Make it!

Unlike me, Leoetlino is a very capable coder. This is where someone like me would have to give up, but he decided to hell with that and started working on his own loader. By modifying Tinyload and using pieces of Dolphin, he created Simpleload.

Simpleload is a very simple loader with the additional feature of being able to load .elf files off the SD card instead of the game executable. With this tool, we checked out the debug version on console and made sure everything was working right. With the music and the cutscene confirmed to be working on console, Leoetlino decided to look at it in Dolphin for a bit longer before trying to implement Gecko Hooks into his loader.

Two full days of work later (sometimes 10+ hours straight,) Leoetlino finally invested a full day away from staring at assembly to add Gecko hooks to simpleload.

Unmasking Red Steel's Secrets

Thanks to Dolphin's fairly decent accuracy when handling homebrew, Leoetlino was able to do much of Simpleloads testing from Dolphin and after one failure to launch, we were able to get Gecko.net hooked into the debug executable.

What followed from here was not fun times. I had the easier of the two jobs, I just had to carefully follow Leoetlino's instructions and relay how the game responded. He had to actually determine what the game was doing and look for differences that mattered. Working tirelessly every day, leoetlino fed me countless addresses to breakpoint as we searched for a key difference.

Sometimes it seemed as though we were looking in the wrong places. Everything seemed to be just fine, and any differences between console and emulator ended up not mattering in the least. Very late into the second night of debugging over Gecko.net, we both felt lost. There wasn't very much hope.

I had a long night at work that night, and by the time I got home leoetlino was already up and at it again. I fell asleep before we got anywhere, but the idea was that it had to be somewhere in shared audio code between DSP-LLE and DSP-HLE in Dolphin. The bug was happening somewhere on the lowest level of the stack.

The First Breakthrough

The next day started off after a short six hours of sleep. He had addresses ready for testing and my Wii was still set up and ready to go. We did some preliminary testing and some of the breakpoints and things already were starting to turn sour. We needed to try and understand what we were looking at.

Leoetlino turned to an unexpected source of information on AX - decaf! The Wii U still uses a lot of AX, and while some of it has changed, there are enough similarities that decaf's documentation could come into use. Without decaf's excellent documentation on AXVoice, there's a chance debugging would have taken much longer or possibly failed. While decaf isn't the big Wii U emulator on the block and lacks the compatibility of cemu, it had the one important trait we needed on this day: being open.

With the AXVoice documentation in hand, we were able to know what the inputs and parameters should be, meaning we could tell where audio was being loaded. And to our surprise, the address differed between Dolphin and console!

A quick hack to point the game to where it was going on console gave promising results.

Now the question became... where was Dolphin going wrong? The game was finally working, but at the cost of all other audio breaking. Not just in Red Steel, but pretty much every game.

With this new information, we kept analyzing console, finally figuring out how exactly the behavior differed.

Hijacking A Game as a Hardware Test

For the music, voice acting, and other sounds, Red Steel was reading from around 0x48000000 in memory. Dolphin assumed since it was trying to read from 0x48000000, that it'd be reading from 0x48000000. That ended up not being the case!

Even though we gave it 0x403837C2 as the start point, it read from 0x003837C2 to 0x00383822!

Red Steel was trying to read from 0x480xxxxx, but was that was silently getting masked to 0x080xxxxx by the DSP! Dolphin was reading a completely wrong address.

This is where it gets insane - leoetlino came up with a method for us to poke our own values into Red Steel's voice function! By using this methodology, he was able to determine a basic masking behavior in the DSP accelerator.

* 0x00000000 - 0x3FFFFFFF masks to 0x00000000 to 0x3FFFFFFF
* 0x40000000 - 0x7FFFFFFF masks to 0x00000000 to 0x3FFFFFFF
* 0x80000000 - 0xFFFFFFFF crashes audio in Red Steel

By adding this masking to Dolphin, leoetlino was able to fix both Red Steel and Far Cry Vengeance. These two ubisoft titles, despite using completely different engines, are the only two known games to rely on this behavior.

With Red Steel Unmasked (or really, masked correctly,) users can finally check out this unique launch title from the comfort of their computer. With all of the debug information discovered by leoetlino, it's very likely that there's a ton to be learned about this game's development. Even though the story of getting Red Steel to work in Dolphin may be over, who knows what secrets are yet to be found.

Cleaning Things Up

While Red Steel's story ends here, Leoetlino did not stop. He spent the next week working his ass off on a more complete hardware test built from the ground up. His dedication to this resulted in even more edge cases being found and more accurate emulation of the DSP accelerator overall. Values over 0x80000000 may have crashed Red Steel's audio, but in his homebrew he was able to verify that they were valid input. While it's very unlikely to affect any games, Dolphin now reacts just as console would.

The finalized fix was immortalized in Dolphin 5.0-5395.

Foreword Tales Through Emulation is a series of articles about playing through games on various emulators and sometimes alongside console. Not only will I judge the game, but the experience the emulator provides for the game. Thank you and enjoy.

As I detailed in a previous post, I have been waiting to play the Etrian Odyssey series for quite some time only because I really liked the soundtrack. I have a hard time diving into games without justification, so, I'll be testing both melonDS and Medusa throughout this playthrough.

I know there are other DS emulators on the up-and-coming list, but, these are the two I feel the most comfortable with after testing on them and reporting issues in the past. If I get recommended another one that's coming together, I may add them to the list.

Why not DeSmuME/DraStic?

After trying out Etrian Odyssey, I can confidently say I would have had a easier time on DeSmuME. There were some quirks and problems I ran into that a more mature emulator wouldn't have had.

I didn't choose DeSmuME for my playthrough simply because I know it's been tested and the project is mostly stagnant at this point. It is what it is for the most part. Meanwhile, Medusa and melonDS are both active and I can easily report bugs to the developers.

Despite being a much more mature emulator, DeSmuME does have quite a few bugs with Etrian Odyssey, particularly in the software renderer.

"Gaps" and "Lines" in textures are common in DeSmuME's software renderer due to floating point issues.

DraStic would also a viable choice, but, since I don't have an Android device (with a touchscreen) worth a damn, I'll have to pass on it. I know I don't have to justify why I chose the emulators that I wanted to use anyway, but, I figure a look into the thought process may give you an idea of my expectations.

Onto the game!

A Foreword Before Diving into the Labyrinth

If you're hoping for a detailed review of Etrian Odyssey, you won't get it from me yet. This is my first time playing the game and I didn't exactly make much progress. While I do plan on giving a verdict at the end of the game, you'll have to wait. Some basic details about the game is that it's a first person, turn based dungeon crawler. Where Etrian Odyssey differs is that the main draw of the game is that you must draw and maintain your own maps using the Nintendo DS touchscreen!

The quality of your maps determine how hard or easy your journey through the labyrinth will be!

One of the nice things about melonDS and Medusa is that they both use raw save files. Switching emulators is as simple as booting the other emulator. A quick note though, if I do run into a serious problem in both emulators, DeSmuME can also import raw savefiles to get me past any potential crashes or impassable areas in the new emulators.

Hopeful First Steps Turn to Tragedy

I chose to start off with melonDS first. The titlescreen greeted me with poor performance on my i5-3570K, running at around 85% speed. For the most part in game is full-speed or close to that. A few spots in the labyrinth's dip a bit when there's a lot on screen, but I wouldn't consider it a serious problem. More annoyingly, the game chugs pretty bad within loading screens on melonDS.

Considering that melonDS uses an interpreter, this isn't especially surprising. In the few games that run mostly full speed in Dolphin's interpreter, loading screens tend to be very slow compared to the actual gameplay. Perhaps the interpreter can be optimized more in the future, as both DeSmuME and Medusa's interpreters don't seem to slowdown during loading screens.

Going through the opening on melonDS was fairly pleasant. I created my guild with a bunch of characters along with sometimes goofy character portraits to give them a hint of personality.

She really don't look like a Wanda in retrospect.

An inexperienced medic may have been a poor choice...

While I'm not familiar with Etrian Odyssey, I am familiar with RPGs in general and immediately invested some of my starting money into basic equipment. I decked out my front-line of units with better weapons and tougher armor. I also made sure to save. While I didn't know much about Etrian Odyssey, I had been warned that it's very hard and my friends did recommend savestates. Unfortunately for me, both melonDS and Medusa lack savestate support in their current versions.

Tragedy Strikes Fast

Before I did much in the Labyrinth, one of my characters died. At that point I (mistakenly) thought the game had permadeath - usually when a game says "Character has died," and full-healing your party doesn't fix it, they're gone for good.

I recruited some new members and kept pushing further in the labyrinth and ran into another set of enemies that ended up killing my whole team and giving me my first game over.

melonDS attempts to detect what kind of savefile a game uses through heuristics. The savefile on melonDS was 8KB while after checking out a proper savefile, I found out it should be 64KB

I reported issue 89 to melonDS issue tracker. Unfortunately for me, my safety save was left completely useless and I now had to start anew.

Moving to Medusa

Medusa also uses save-type detection heuristics, but thankfully it got the right answer and made a 64KB file. The first thing I did was close Medusa and reload the save to make sure it worked. Once I confirmed the savefile worked, I continued on my quest to get back my lost progress.

Unfortunately, things seemed a little off, so I loaded up melonDS with this new savefile to get a comparison shot.

melonDS 0.4

Medusa

Medusa had some text rendering issues not present in melonDS. If you can't see it, check out the "O" in organize. Text issues with this game aren't surprising: DeSmuME has a hack for Etrian Odyssey to address text rendering issues.

The issue in Medusa is different; both Medusa and melonDS use integers for texture coordinates much like the DS, whereas DeSmuME's renderers uses floats. The hack simply rounds certain texture coordinate floats to integers.

As with all the issues I'll run into here, I reported the issue the emulator's bug tracker in an issue report

A small text rendering issue wasn't game breaking so I proceeded into the labyrinth. While nothing looked completely wrong, I couldn't help but think that it looked different from melonDS. It bothered me enough that I took screenshots from both emulators to get a better look at things.

melonDS 0.4

Medusa

And thus issue 784 was born. If you look closely, you'll see a light-bluish-green fog in melonDS that's missing in Medusa. It's actually difficult to see in screenshots, but more obvious in motion. Why? The fog helps integrate the colors of the 2D backdrops with the 3D that pops in as you explore the labyrinth. Without the fog, the pop-in was extremely jarring and I just didn't remember it being so bad on melonDS, which is why I investigated.

If I had been playing this in an single emulator, odds are I wouldn't have noticed.

Performance wise, Medusa is better and worse than melonDS. Loading screens don't hit it nearly as hard, but, the labyrinth is much slower, only hitting full speed in a few select areas rather than most of the time like melonDS. It wasn't so bad that I couldn't play the game, but it was definitely noticeable.

That wasn't the end of my problems with Medusa, though. When I got into a battle, I had finally seen enough. Or had I?

Enemies do not render on Medusa, making the battles look particularly silly. While it's still playable, it's not exactly enjoyable. I reported the issue, but failed to see that it was left overs from a more severe issue reported some time ago.

Thankfully, Medusa did give me a proper savefile, and now I could proceed in melonDS. Even with a working emulator, the game did not show mercy and continued to beat me down for a good hour. With the morning sun shining through the window, I finally raised the white flag and closed the game.

I'd have to return to the labyrinth another time...

End Thoughts for the Night

Etrian Odyssey

To say anything conclusive about Etrian Odyssey 1 would be jumping the gun when I'm still stuck on the first floor flailing about. Plus, I enjoy a challenge so I'm not really disheartened by failure. I'm having fun trying to figure out how I'm supposed to play the game, and I'll know if I like the game or not if I find the game fun once I know what I'm doing.

The one aspect I will point out is that you do get some opportunities to make choices within the labyrinths that can have negative consequences. It establishes that you need to take calculated risks to survive, and I appreciate that.

melonDS

Outside of creating the wrong type of savefile, melonDS did a fantastic job. There were no visible graphics issues and while it didn't run full speed at all times, it was reasonable enough to play. There were no emulator crashes to halt progress either.

Reported Issues - issue 89

Medusa

Medusa was a mixed bag for this test. It was both essential for me to stick to only using the new emulators for this run, but at the same times very difficult to use outside of very basic comparisons.

Medusa's save heuristics managed to create a proper savefile, which was great! The myriad of graphical issues were not so great, and performance was sometimes better and worse than melonDS. While the enemies not rendering was the worst, little details like the missing fog and slightly worse text do add up to hurt the experience. On the plus side, I never ran into any crashes or stability issues within emulation itself during the time I spent in Etrian Odyssey on Medusa.

Hopefully the issues within Medusa clear up so that I can use both emulators for a majority of this run.

Reported Issues - issue 782,issue 783 and issue 784, which was a duplicate of issue 573

Part 2 will continue once I've managed to get through the first major boss of the game.

The Nintendo Wii is infamous for being built off of its predecessor, the GameCube, with a few extra features added on. Most of the new hardware and features can't be accessed directly by the PowerPC processor and was instead silently regulated by the Starlet co-processor, running IOS.

Throughout the development of the Wii, IOS kept evolving. Online functionality, USB 2.0 support, and many other big additions did not exist in the launch IOS version.

On the flip side of things, some features were never finished or were scrapped! Leoetlino stumbled upon an incomplete feature of IOS that was meant to regulate games and channels!

Leoetlino has spent the past year working on Dolphin, primarily in IOS emulation. One of the noteworthy things about how he's taken up this task is that he's been willing to emulate things that serve little or even no use. Tons of unused (or at least not known to be used,) behaviors are now emulated in Dolphin thanks to his work.

In the case of this timer, it's not even used on the Wii, though the functionality does still exist! Through further investigation, he discovered a bunch of ways to regulate a game being played! While most of these no longer exist, because IOS's source code was accidentally open sourced, we can see what even the timers were going to be, even the completely unimplemented ones!

• Duration - How long a game can be played before it is disabled.
• Absolute Time - A game starts (or stops?) working upon a certain date.
• Number of Launches - You would only get so many chances to play this game!
• Number of Titles - Title stops working... if too many titles are installed?
• Elapsed Time - Just a guess, but perhaps how long you've played a title in a single session.

Despite the impressive list of strange limitations, only duration and number of launches are actually implemented in IOS. No one has ever seen them used because nothing released for the Wii actually uses either of these features.

It may sound like the story should end here - there's not much else to do but think about what if, right?

Leoetlino decided to take it a step further. Because he knew that duration and launch count should technically still work, he went through effort of modifying a title to use them so that he could test out this feature in Dolphin.

After an hour of working on it and trying to implement it, things started to come together.

Once time's up, you're returned to the System Menu with this message.

After which, you can no longer access the channel.

Do note that this isn't from a final implementation - properly implementing and testing everything will take much more time, but it does show that this functionality does indeed work and that Dolphin can emulate it!

While we don't know exactly what these features were for, we can assume they could be used to regulate demos. A lot of demo content (including the masterpieces included in Super Smash Bros. Brawl) actually contain the whole game, but are limited by a timer. Another possibility that comes to mind is that they could have been used as a parental control. Alas, it never came to be and only a fragment of what they were planning was finished.

Even when Dolphin does implement this feature, don't expect to ever run into it. As said before, no official titles use it! However, any homebrew or game mod wishing to take advantage of this functionality will be able to test it in Dolphin once Leoetlino's implementation is completed.

Just remember: it isn't especially hard to work around the timers in an emulator anyway!

More information on the initial discovery of this functionality can be found on The Cutting Room Floor.

For more information on IOS, please checkout WiiBrew.org

NEW INFORMATION

Thanks to a point-out from booto, I now know at least one title did use this, but it's ironically already something from homebrew! An early version of the Homebrew Channel had a 10 minute time limit and a 1 launch limit, making use of both of the completed modes.

As we've seen happen before, there are sometimes multiple generations of emulators for a single system. One of the most obvious examples of this would be the SNES. The early days of the SNES saw two behemoth emulators take over, ZSNES and Snes9x. They lorded over SNES emulation until bsnes showed up.

Because of its higher accuracy that relied on the power of modern computers, it became the standard for SNES emulation. But, this changing of the guard wasn't immediate - it took quite some time for the community to catch up to the SNES emulation golden age. The result? We now have multiple emulators with near-full compatibility with the SNES library.

It's the Nintendo DS's Turn For its Golden Age of Emulation

When people think about flourishing emulation scenes, Nintendo DS may not be the first one to come to mind: cemu is making blistering progress on the Wii U, Xenia and RPCS3 seem to be hitting their stride, and Cxbx seems to be making progress on fan-favorite Xbox titles.

But Nintendo DS may be in an even better spot to make leaps over the next year. There's a ton of documentation alongside a crop of capable Nintendo DS emulators right now.

• The Android behemoth DraStic provides unprecedented performance and runs many DS games full speed with good accuracy even on phones.
• The PC stalwart DeSmuME is a tried and true emulator with a big userbase, lots of features, and high compatibility.
• And we cannot forget No$gba and the extensive documentation done by its creator. No$gba is probably the closest emulator to DSi Support as well, but isn't usually the best option if you're just looking to play various games without issues.

And those are only the tip of the iceberg! But what makes the Nintendo DS emulation scene so exciting are the next generation of emulators. Just in the past year or so, three new emulators have thrown their hat into the ring.

• Medusa - by endrift
• melonDS - by StapleButter
• GBE-Plus - by Shonumi

While there emulators are young and not quite ready to challenge for the crown of go-to DS Emulator, that doesn't mean they lack value! I took a look at all three of these emulators as they are now just to see how they stack up to the current DS emulation solutions and where they may be going in the near and distant future.

Note: I mostly focused on emulation quality when looking at these emulators. Don't expect a lot of extra features. This includes some features essential to emulation of the DS, like microphone support, and other amenities like savestates. With GBE-Plus, you'll also want to be very familiar with how to compile an emulator without additional instructions.

On with the show!

melonDS (0.2 and 0.3) by StapleButter

I didn't know anything about melonDS before heading into this article. I had never used it nor did I ever plan on using it. It's the true definition of zero expectations. melonDS made a very poor first impression with a bland, empty UI that's awkwardly broken up into three different windows.

This is what shows up when you open melonDS for the first time

All you can do is setup the BIOS, firmware, and whether you want to boot to the DS's system menu. I decided to boot up Super Mario 64 DS as the first test on melonDS. I was hit with some pretty poor speeds; the main menu wasn't quite full speed, and in game seemed to hover around ~80% on my Intel Core i5-3570K. Switching to a second PC, a Core i7-6700K, alleviated most of the lag, but isn't an option most users will have.

Lag will be the experience for most people in 3D-heavy games. Unless you have an absolutely top-tier CPU, don't expect full speed in melonDS yet. Games that don't rely as heavily on 3D, however, require much less power. Advance Wars: Dual Strike ran near-perfect on the i5, and that was the case for pretty much every 2D game.

Despite the performance, I ended up very impressed after my time with melonDS. It may not have all the bells and whistles, but the core of the emulator feels solid. It's a good feeling when I trust the emulator to do its job without any fear of crashing or game-breaking glitches as I play.

Advance Wars: Dual Strike

The Legend of Zelda: Phantom Hourglass

Mario Kart DS

Metroid Prime Pinball

Mario Party DS

Mario Hoops 3 on 3

That isn't to say my time with melonDS was perfect. I did run into a few games that had problems with save files and other nagging issues.

melonDS seems incapable of generating a valid savefile for Metroid Prime: Hunters

The one severe visual error I found resided in Burnout Legends, but it was already fixed during the writing of this article with the release of 0.3!

MelonDS 0.2

melonDS 0.3 Test Build

You can actually see the outlines of prominent details within the static while driving in 0.2.

Future Goals

Performance. StapleButter assured me that improving performance without compromising accuracy was a huge goal going forward. The main bottleneck right now is graphics rendering, especially in high polygon scenes, which makes sense considering what I ran into while using it. The future does look bright, though, as an experimental build I stole borrowed with threaded rendering ran almost everything I had at full speed even on the i5-3570K. This didn't mean everything was perfectly smooth, as loading screens and transitions seemed to still have slowdown.

In terms of features, melonDS has some very lofty and interesting goals. Near the top of the list are some fan-favorites like Wi-Fi support, alongside important preservation goals like better homebrew support and cartridge timings. While Nintendo's Wi-Fi servers for DS are long dead, third party servers still exist, and tons of game supported local Wi-Fi play!

I came into melonDS knowing nothing, but, just seeing what it is now makes me excited for its bright future.

Medusa Alpha 2 by endrift

The brainchild of endrift, Medusa is a DS emulator built upon the multi-system emulator mGBA, which already supports the Game Boy, Game Boy Color and Game Boy Advance.

That means Medusa is already an excellent emulator of the older handhelds and carries over a lot of the nice features. You'll have archived ROM support, video-dumping with audio and other features you wouldn't expect from a new DS emulator.

The Legend of Zelda: Phantom Hourglass

Metroid Prime: Hunters

Bomberman Story DS

Puyo Pop Fever

StarFox Command

Sonic Rush

A lot of games look and play well in Medusa already. When I was testing Super Mario 64 DS, there were moments that I forgot I was using an early alpha of a DS emulator.

That's because the visuals looked near perfect and Medusa was able to run full speed without any drops. While Super Mario 64 DS isn't a particularly taxing game, Medusa is able to run quite a few games full speed on my i5-3570K right now. That isn't to say everything is perfect; high polygon scenes in games still make it struggle. Moving over to the i7-6700K quelled the slowdowns in more strenuous games like The Legend of Zelda: Phantom Hourglass.

On the sound side of things, some audio modes seem to be unimplemented in Medusa. This results in some sounds not playing in certain games, such as the red coin effect in Super Mario 64 DS. The good news is that an unimplemented feature is much easier to handle and fix than an incorrectly implemented feature, so expect this to be sorted out without too much of a headache.

With Medusa, most of my problems weren't actually related to emulation, but instead with user experience. Controller support is bad. If you select the window while a controller is configured, the controller won't work properly. The solution is to click off of the emulator window, which is less than ideal considering you have to use the mouse to click on things for touchscreen controls.

I also had some crashes show up here and there, mostly between resetting and switching games. The worst offender for causing crashes is that if you disconnect your controller while the emulator is running, it will crash.

endrift notified me that these issues were mostly a consequence of merging in an experimental update to controller support that wasn't quite ready for primetime, but was necessary for DS input. As such, these issues should get ironed out as the new interface matures.

Future Goals

As a branch of mGBA, the eventual goal of Medusa is to be merged into mGBA proper. Considering that mGBA is one of the most accurate GBA emulators around, that sets a high bar for Medusa going forward.

GB Enhanced Plus (with DS support) by Shonumi

This is the quintessential experimental DS emulator. There's no release build, and the instructions to compile are pretty much "it should compile." Considering that much more detailed instructions haven't been enough for me, I wasn't successful compiling GB Enhanced Plus.

What is GB Enhanced Plus?

Like mGBA, GB Enhanced Plus is a multi-system emulator featuring the Game Boy, Game Boy Color and Game Boy Advance alongside now experimental DS support. From what I’ve heard, it doesn’t run any commercial DS titles yet. Once it does, I plan on taking a much longer look at it.

GBE-Plus is most notable for how it makes it easier to colorize and modify various Game Boy titles. The goals of the emulator seem to be more or less tied to what Shonumi wants to do, so there’s a definite chance that some exciting and unique features found nowhere else could hit within the DS side of the emulator. This one is worth keeping an eye on despite there being so little to see right now.

Comparisons

Now we get to the fun part: pitting the emulators against each other to see where they differ. I'm not going to be really getting into which emulator is better because that's pointless at this stage and heavily depends on what you want out of the emulator. What I am going to do is look at how they perform in a few games to give you an idea of where they are at and how they compare to current emulators.

Mario Hoops 3 on 3

This is a fun one because both Medusa and melonDS have their own set of issues. We're going to zoom through these quickly with some examples of both emulators having their own issues.

Medusa Alpha 2

melonDS 0.3

Item objects near the court render fine on Medusa, but render behind the court on melonDS.

Medusa Alpha 2

melonDS 0.2

The transparent backboard does not render on Medusa.

Characters will flash when you take control of them or the AI takes control of them. Both Medusa and melonDS get this correct, so, this time we'll bring DeSmuME in for the comparison.

Medusa Alpha 2

DeSmuME

melonDS 0.2

Something to note is that melonDS flashes bright colors, and Medusa flashes darker colors. DeSmuME renders this correctly. In melonDS 0.3 (unshown) the colors are closer but still incorrect.

Madden NFL 2006

While most users probably aren't clamoring to play the DS version of Madden 2006, it actually has been one of the more interesting test cases on these new emulators. melonDS and Medusa don't handle it very well.

Medusa Alpha 2

DeSmuME

MelonDS 0.2

MelonDS and Medusa both have severe issues, while DeSmuME again shows us what it should look like. In melonDS 0.3 (unshown) the missing polygons are fixed but the character models are still black.

While DeSmuME shows us how the game is supposed to look, many other emulators still fail in this strange title, including No$GBA.

What is Madden NFL 2006 doing? Well, that's up to the developers to figure out!

Burnout Legends

While I showed a graphics issue with this game being fixed earlier, Burnout Legends needs a second mention here as well. This game is more playable on Medusa and melonDS than DeSmuME!

Why? DeSmuME suffers from some severe timing issues that make driving a pain in the taillight.

If you watch closely, you can see the game's pace plummet throughout the turns.

Don't go calling Medusa and melonDS more accurate yet, though! The reason why the game runs better in those emulators could be a case of even worse emulation! On real hardware, the game employs some kind of frameskipping in order to avoid slowdown. During those areas, DeSmuME incorrectly slows down instead of skipping frames, while on melonDS and Medusa, the game maintains a solid framerate at all times.

So even though this game runs better on Medusa and melonDS, it is likely a consequence of them being less accurate than DeSmuME.

Overall, both Medusa and melonDS exceeded my expectations. The examples above were cherry-picked because both emulators had issues. In most titles, there weren't many serious visual issues.

Emulator Performance

Before this project, I wasn't really familiar with Nintendo DS emulation outside of playing a few of my favorite games. I was initially very surprised that a DS emulator wouldn’t run full speed on my i5-3570K, even if it was unoptimized.

The reason for this is simple: Medusa and melonDS use software renderers and a CPU interpreter. If you tried running Dolphin on those settings on the same PC, you'd be very lucky to see ~1 FPS. While the DS isn't as powerful as the GameCube, without those optimizations, performance takes a pretty big hit.

Notes - I kept DeSmuME in as accurate of settings as I could. With OpenGL + Dynamic recompilation, you can make it go faster. I also excluded melonDS's 0.3 and its threaded rendering, as it's still a bit experimental and Medusa currently lacks the feature anyway. melonDS 0.2 and Medusa Alpha 2 feels like a much closer comparison as to how far along they were.

Conclusion

After testing two dozen games, including popular titles such as Pokémon Diamond and Pearl, The Legend of Zelda: Phantom Hourglass, StarFox Command and many more, I can confidently say users looking only to enjoy their favorite Nintendo DS games on PC should probably stick to one of the more mature emulators. They're going to be better right now.

These new emulators do present an opportunity for people looking to test though. If you don't mind running into issues or dealing with subpar performance, there's a lot of games untested in these emulators and bugs that need to be reported! The developers have been very friendly toward bug reports and usually have the simpler ones fixed within days!

While I greatly enjoyed trying out melonDS and Medusa, I'm not ready to write off GB Enhanced Plus yet. While we always strive for accurate emulation, isn't there space for an emulator with all kinds of wild and wacky enhancements too? Considering the feature-set of most DS emulators, I'd say something like that would be welcomed by users if it was done well enough.

Now you may be wondering: Do these new emulators spell the end for DraStic, DeSmuME, No$GBA and the rest of the old guard? I don't think so - after all, I used DeSmuME for my header image. Even if the new emulators keep improving, that doesn't mean the older emulators will lose their prominence in the scene. We can look to the SNES emulation scene and how it turned out as an example once again. While most people would consider ZSNES to be a relic of the past, Snes9x has managed to improve itself over the years and find its place as a modern SNES emulator.

And that's really the best way to look at this. These new Nintendo DS emulators can only help the state of the scene. And because of that, I'm excited to see what features, enhancements, and compatibility these emulators bring to the table.