When it comes to judging the accuracy of emulators, most are ill-prepared for the task. You see, the vast majority of gamers tend to play the same 10-20 ultra-popular games, never venturing out to the thousands of other games available for the SNES. Because of this, extra attention ends up being paid toward fixing bugs in these games, even through the use of game-specific hacks where necessary.
So it is easy to see why, at first glance, accuracy is not that important. But when we take a closer look, we see just how much it actually does matter. Seeing is believing, and a picture is worth a thousand words.
So what are some bugs you can expect to see when you use an inaccurate SNES emulator? I'll show you, but please keep in mind, this list is nowhere near exhaustive! There are literally hundreds of bugs like this in the most popular SNES emulators. We can't even keep count of them all.
Games with visual anomalies will have two screenshots. The left (which will have a green border around the image) shows the correct behavior, whereas the right (which will have a red border around the image) will show incorrect behavior. You may also mouse over some of the images for additional descriptions.
Games that lock-up or have audio distortions cannot easily be demonstrated in pictures, these games will just have random screenshots along with a description of the problem instead. Some will have external links to show the problems in video or audio.
I did not want to name names when I wrote this guide, because I do not like the way that comes off. However, due to recent improvements I feel it is necessary to avoid confusion and give credit where it is due.
Almost all of these bugs exist in the latest ZSNES, version 1.51. Roughly 2/3rds of them also exist in Snes9X v1.52 and earlier.
However, Snes9X v1.53 has made amazing strides, and only roughly 1/3rd of these bugs still apply to it. While I still don't feel it has caught up to the compatibility of even bsnes/Performance, I am very pleased with the improvements. If the APU and game-specific hacks can be removed, a few more important bugs be fixed, and LLE support for DSPs be added, I would whole-heartedly recommend Snes9X as an alternative to bsnes/Performance.
Here is an example of a bug that you may not even realize is there. In Air Strike Patrol, a shadow is drawn under your aircraft. This is done using mid-scanline raster effects, which are extra-ordinarily resource intensive to emulate. But without the raster effects, your aircraft's shadow will not show up, as you see in the right screenshot.
It's easy to overlook, especially if you do not know that it is supposed to be there. But once you actually see it, you realize that it's quite helpful. In this game, your aircraft has the ability to drop bombs, and this shadow acts as a sort of targeting system to determine where they will land. The game is actually slightly more difficult without this seemingly minor shadow.
Some games push the limits when it comes to IRQ timing. Battle Blaze is one such example.
With bad IRQ timing, the title screen goes completely nuts. Not shown, the animation sequence after each fight is similarly broken.
I may be a bit biased here, but I believe this to be the finest example of a strategy RPG / simulation game on the SNES platform. A fantastic, branching storyline, where you can choose to fight for good, evil, imperialism, or go against everyone and forge your own future. Combined with an amazing soundtrack, this is a real gem of a game.
With bad DSP emulation, this game will frequently deadlock. Rather insidiously too. You see, Der Langrisser scenarios play out for up to 2-3 hours, and this deadlocking tends to occur after you've been playing for a long time. It is easy to lose an immense amount of progress this way.
Unfortunately, it's also a prime example of what you can expect when an emulator does not focus on accuracy. This emulation bug was first reported in 1998, and to this day, the most popular SNES emulator still has not bothered to fix it. Rendering this classic completely unplayable. A continuing tragedy.
So even when you do spot that bug in an inaccurate emulator and report it, you may find yourself waiting thirteen years or more for it to be fixed. Whereas with an emulator that strives for accuracy, you will receive immediate attention, with a typical turnaround time of two days to two weeks for resolution.
This game streams sound effect samples between the refresh period of each scanline. With bad timing, the end result is no sound effects at all.
Here is a fairly decent racing game which utilizes some tricky IRQ behavior to manage the head-up display. Get this wrong, and you may as well not have the HUD at all.
It is important to implement all of the SA-1 character conversion modes.
The SNES has not only a high-resolution display mode, it also has a variant called pseudo-hires mode. This mode is useful for creating true alpha-blending between layers on SNES hardware. Ignoring this mode results in layers completely obstructing others.
Please excuse the blurriness on the left-hand picture, I had to resize it from its native 512x224 down to 256x224 to fit on this page.
This game also takes advantage of pseudo-hires for translucency.
It can prove difficult to beat the forest levels when you cannot see your character.
The order of events that occur huring HDMA are important for timing purposes. Bad timing may cause the entire screen to flicker.
Here is a Japanese RPG that uses hires rendering for its text. Reading the text may prove difficult, even for fluent Japanese speakers, if your emulator cannot handle the text rendering properly.
It is important to implement all of the SA-1 character conversion modes.
While not in and of itself a game, this one is particularly telling. Nintendo wrote a test program which would query very basic hardware attributes to determine if an SNES console was flat-out broken beyond repair. Not surprisingly, less accurate emulators fail this simple test.
What's really sad is how such a simple set of tests has become some sort of holy grail accomplishment within the SNES development community. Passing this test is quintessential to writing an emulator, it is not an accomplishment which should be praised in and of itself.
This game uses an IRQ trick that is very similar to the one used in F-1 Grand Prix. What is supposed to happen is that the room slowly fills with water. Get this behavior wrong, and everyone might end up sinking instantly instead.
This is a great example of a niche game. It's actually a very good platformer, but few people have heard of it. It's a great example of why just because most popular games can run decently with inaccurate emulators, accuracy still matters. You never know when that slightly-less-common favorite game of yours may run into a bug like this.
In the below screenshots, you see a switch. When this switch is hit in any other emulator, the game deadlocks instantly.
What is supposed to happen is demonstrated in the subsequent screenshots: the switch is supposed to move a block into the middle of an electrical field. It is required that this is done to complete the level, and thus, the game.
What is particularly interesting is that this bug occurs in the very last level of the game. This game lacks save RAM, so you have likely spent about two hours making it thus far. Not that it matters, as you may discover that you are unable to complete the game at this point either way, if your emulator is not up to the task. And as far as that goes, at the time of this writing, bsnes is the only SNES emulator capable of fully playing this game.
Star Fox was released with the SuperFX coprocessor, used to draw the pseudo-3D polygons. Unfortunately, it was released with the first revision, which ran at half the clock-rate of the version used in Super Mario World 2.
This chip also has many caching mechanisms, and generally does not perform very well. But you wouldn't know that from other emulators, where Star Fox appears to run twice as fast as it should. Sure, it may be nice looking, but it isn't accurate. One should at least have the option to play Star Fox at its proper speed.
Like Star Fox, some emulators have a problem with speed. Specifically, battles tend to run twice as fast as they should. For a system with real-time battles, this makes the game a good deal harder.
Many emulators run into countless other crashing bugs in this game. It has erroneously given the game a reputation for being buggy. And while it is certainly not without its flaws, most of them are due to emulation errors.
I know what you're thinking ... the quintessential SNES game, Super Mario World?! Well, yes and no. The original game itself runs fine in just about any emulator. This is an example of the negative effects inaccurate emulation can have on not just individual games, but entire communities.
Enter SMW Central, a community built around hacking this classic game: designing new levels, new music, you name it, they've probably done it. It is a vibrant community boasting over a thousand hacks.
But at the time of this writing, there is a small war going on there. You see, half of the hacks they provide do not run on an actual SNES, let alone on accurate emulators. This is because of a flawed tool known as addmusic. It was designed to allow hackers to insert new music tracks, but it was developed with and tested against an inaccurate emulator. One that cheated when it came to DSP sound emulation. The echo effect of the SNES DSP works by writing previous results into RAM, in order to mix with them later. This addmusic tool did not know this, because the emulator did not do this. As a result, impossible values were used for echo buffer sizes, which on real hardware and accurate emulators, results in all of the APU's RAM (and thus, program code and samples), being overwritten—crashing the game.
Had this hardware feature been emulated properly initially, this situation would have never happened. Instead, people who actually want SNES games to run on the SNES (imagine that) are forced to fight with people too short-sighted to see tomorrow. Eventually, and inevitably, hardware will be emulated properly. Even if it requires the complete and total death of the x86 ISA, perhaps twenty plus years off, but it will happen. And all of these hacks will be rendered useless.
Now, some are complacent in this regard, and don't mind this. And neither do I. If an author doesn't have any care or respect for the quality of his own work, then why should I? The only thing regrettable about this entire situation is that it was entirely unnecessary. A tiny bit more attention to detail would have rendered the whole thing moot.
The map screen in Vs. mode has some very tricky timing behavior. Get this behavior wrong, and hope that you do not have epilepsy. Note that you will need GIF image animations enabled to see the incorrect effect.
Note: even the speed-focused bsnes/Performance core exhibits this bug. You will need to use the accuracy-focused bsnes/Compatibility or bsnes/Accuracy core for this game to run correctly.
We're having a sale! Here is two bugs for the price of one. First, audio runs twice as fast as it is supposed to with bad sound emulation. Second, the distortion of the ship in this inaccurate emulator is only applied horizontally. The effect is also supposed to be applied vertically, making it much more technically interesting.
You can see a Youtube video of this, courtesy of Ultimaximus, here.
What is it with inaccurate emulators and running things twice as fast as they should, anyway? It's creepy.
Look, I understand the appeal of speed-focused emulators. They serve a specific niche: running on cell phones and handheld gaming systems, and conserving battery power when playing on the go.
This article is not meant to say that inaccurate emulators are without merit. Instead, it is to say that accurate emulators do in fact have merit of their own. The system resources necessary for extremely accurate SNES emulation become cheaper and cheaper every day. Currently, a refurbished system capable of running bsnes at full-speed will set you back $99USD.
Perhaps you don't play any of the above games, and none of these issues affect you. That is fair enough. But why take the chance? You never know when an emulation bug is going to destroy your gameplay experience. So if you have the system resources, why not put them to good use, and demand accurate emulation? I'm not even saying it should be bsnes. Encourage other emulators to also care about accuracy, as I have been. Focusing on accuracy will not harm the people reliant on faster emulators, they are free to use the older versions of these emulators for as long as their old hardware remains functional. Catering to the unfortunate poor and the technological luddites should not hinder the progress of our entire community, is all I'm saying. The real SNES will not be around forever, and if we do not preserve it properly now, nobody ever will.
And please, the next time you hear someone espousing that the most popular SNES emulators are just as accurate as bsnes, ask them what drugs they are on for me, and link them here. Thanks for reading this.
Copyright © 2004–2013 byuu
Re-stored by Kawa.