The Runup to bsnes v1.0

As a kid, I was lucky enough to have grown up during the Golden Age of console gaming. I am old enough to have played some Ataris and my older brother had a regular Nintendo Entertainment System when I was really young, but the first console I personally owned was the Super NES (or SNES).

The SNES was a pivotal piece of hardware in console gaming. Prior to the 16-bit era, hardware limitations in gaming consoles necessitated that graphics be highly representational and storage constraints were a burden on many developers. This all changed with the SNES, which could produce graphics that were good enough to not impede storytelling and which used cartridges that had enough storage to encapsulate some truly lengthy and epic games.

Early SNES Emulation

Just as the SNES heralded a new period in console gaming, the emergence of popular SNES emulators in the late 1990s changed the landscape of the PC console emulation scene. ZSNES and SNES9x pushed to the forefront of the scene with good compatibility for most popular, commercially available games through a variety of game-specific hacks and the ability to run full-speed on the prevalent hardware of the time (90 mhz Pentium IIs).

However, despite the compatibility hacks, these early emulators experienced a number of emulation bugs that range from minor to rather serious. For example, ZSNES runs games at approximately 140% speed and some games experience graphical glitches. Many games that use special hardware, such as SuperFX chips, run very slowly or not at all. Some more obscure games, such as Speedy Gonzales, experience show-stopping bugs that completely halt progress in the game. Nevertheless, gamers accepted these foibles and adoption of these early emulators was widespread. As time went on, though, the authors' enthusiasm for squashing bugs waned and development on these early emulators slowed to a crawl. Furthermore, the code behind these early emulators was esoteric and poorly documented, making a significant barrier to entry for potential newcomers to contribute to their development.

A New Challenger

Fast forward to 2004.

A ROM-hacker that goes by the name 'byuu' became interested in writing his own SNES emulator from scratch in his spare time, so he could better understand how the SNES works. Instead of focusing on speed, byuu focused on accuracy, debugging functionality and clean code. This shift in focus was revolutionary for several reasons:

1.) Compatibility would no longer require hacks. If the emulation of SNES hardware is perfect, it stands to reason that all games that work on real hardware should work on the emulator.

2.) The code would be self-documenting and would also document the hardware of the SNES. Someone reading the code could see not only that 'this is how the emulator does it' but that 'this is how SNES hardware does it,' which is of utmost importance to digital archivists and preservationists.

3.) System requirements would be extremely high, putting such an emulator far out of reach of older systems, even those that could run previous emulators at full speed.

The first public release of this emulator, dubbed bsnes, was in May of 2005. At the time, the code was completely unoptimized and bsnes still experienced a variety of issues that were not present in previous emulators. However, byuu made rapid progress and a number of other talented programmers, including GiGO--the author SnesGT, another SNES emulator--and blargg--the author of QuickNES--supplied components for cycle-level emulation of different pieces of SNES hardware.

Unfortunately, these early releases had very steep requirements to run (Richard Bannister's port of bsnes to Apple's OS X initially required a then-top-of-the-line G5 CPU to even approach playable framerates), and many early users were turned off by the project, assuming it was simply a proof-of-concept. Eventually, though, PC hardware advances and byuu's code optimizations met somewhere in the middle, with bsnes emerging as a playable, extremely accurate SNES emulator.

Soon, bsnes had become the first and only SNES emulator capable of full SPC7110 emulation, SPC700 cycle-level emulation and full Super Gameboy hardware emulation. Even cheat codes were implemented faithfully by emulating the way a Game Genie would interact with actual SNES hardware. Additionally, byuu's clean code and commitment to openness allowed bsnes to be ported to all major, modern operating systems, including MS Windows, OS X and Linux.

Modern Innovations

After reaching maturity, bsnes gained many of the features users enjoyed in ZSNES and SNES9x, such as software filters that would improve the look of pixelated SNES sprites on high-definition, flat-panel monitors, as well as some modern features that were not possible in earlier emulators, such as hardware-based shader effects.

By June 2010, bsnes had achieved 100% compatibility with all commercially released games while still being playable on standard, albeit modern, hardware, so byuu set out to tackle one of the final frontiers of SNES emulation: a dot-based S-PPU rendering core.

Up to this point, bsnes, like all other SNES emulators before it, had used a scanline-based rendering core, which would fetch and display data entire scanlines at a time. In contrast, actual SNES hardware would only fetch and display data one dot at a time. While this did not make much difference in a majority of games, some games, such as Air Strike Patrol, used dot-level calculations to show certain effects; in ASP's case, the shadow of the plane (using scanline-based rendering, ASP shows no shadow at all, which makes it really tough to accurately drop bombs on targets). Likewise, some games used dot-based effects to create a faux transparency, similar to the artistic technique of pointillism.

Unfortunately, using this new hyper-accurate rendering engine incurred a nearly 40% reduction in emulation speed, once again making full-speed gameplay difficult-to-impossible, even on state-of-the-art hardware (at the time of this writing, including Intel i7 CPUs). This left byuu with a dilemma: continue using the most faithful, accurate emulation code available at the risk of again alienating users and creating what amounts to an unplayable benchmark or sacrifice accuracy to maintain playability.

The Future of bsnes

This crossroads led to much discussion on byuu's message board, with some users suggesting he go with the most accurate code and just wait for the hardware to catch up, while others suggested he fork the code into two separate projects, an accurate emulator and a fast one.

Rather than compromise on any of his core goals for bsnes, byuu decided on a third option in which he would enable users to choose at runtime among three distinct processing cores for bsnes: an 'accuracy' core that focuses entirely on accuracy and is only intended for research purposes, a 'compatibility' core that maintains modest requirements with high compatibility (this core is similar to that of bsnes v0.067), and a 'performance' core that makes small sacrifices in accuracy and code readability to make bsnes faster than it has ever been (so fast, in fact, that it can run most games at full speed on an Intel Atom 240).

These three cores will be included in the upcoming 1.0 release of bsnes, according to byuu. UPDATE: The three cores were included in v0.068! Windows users can download it at byuu.org/bsnes and Ubuntu users can get it from my PPA.

While he has not given any estimated release date for version 1.0, he has already begun beta testing the cores against each other and against actual SNES hardware to spot any remaining bugs. Additionally, leading up to v1.0, byuu has solidified his API for libsnes, a portable core library at the heart of bsnes, which can be used to drive lightweight, platform-specific graphical interfaces created by the community.

If any Debian/Ubuntu users would like to try bsnes, I have builds of the latest publicly available code published in my PPA.

UPDATE (3/11/2015): heh, the 1.0 numbering convention never came to pass. At the time of this writing, we're at v095... libsnes has also been abandoned and then forked into libretro.