Beginner's Guide to SF4 Skinning

There are several tutorials floating around for skinning in Street Fighter 4, namely those by Providenceangle and hornyyoshi, but they were both written fairly early on and have not been updated to reflect new, easier methods. So, here is a definitive guide to creating new skins in SF4:

1. Collecting the Tools

First and foremost, you'll need a painting program. Photoshop is obviously quite common but also very expensive. GIMP is a free alternative that works quite well (it's what I usually use) and you can download it free from here. This tutorial will mainly focus on Photoshop, but I'll include some info for GIMP when possible.

Next, you'll need a plugin for your paint program to allow you to open/modify DDS textures, which are used by SF4. For Photoshop, you can use Nvidia's free Photoshop plugin, available here. If you would rather use free software, GIMP has a DDS plugin available here. I'm not going to cover installing the plugins, but you should be able to find documentation at the respective sites.

You'll also want to download Nvidia's free Windows Texture Viewer tool, which will give you some valuable information about the DDS textures you will extract. You can download it here.

Finally, you'll need to download the latest version of piecemontee's Asset Explorer, which greatly simplifies the whole modding process, from decompressing files to identifying, viewing, extracting and injecting textures. It does it all and you can download it from here.

2. Some basic information

SF4 uses two main files to control the appearance of a character:

A. The cos file (stands for costume), which is designated by the character's three-letter name abbreviation (ZGF for Zangief, RYU for Ryu, etc.), a number delineating which costume (01 for original, 02 for Capcom's alternate), the file extension (cos) and the compression container (emz). So, Zangief's original costume will be named ZGF_01.cos.emz.

B. The col file (stands for color), which is similarly designated by the character's three-letter name abbreviation, a number designating which cos file the color goes with (i.e., original costume or alternate), a number delineating which color slot the file occupies (one through ten), the file extension (col) and the compression container (again, emz). So, Zangief's first color for his original costume will be named ZGF_01_01.col.emz.

The cos files primarily contain the 3D model and other embedded files used by the engine to display the body that you see in-game. I won't cover editing any of these files here, but I wanted to mention it anyway.

For simple skinning, you will be entirely focused on the col files, which contain embedded texture files stored in DDS format (hence the need for a DDS plugin).

3. Using piecemontee's Asset Explorer

The Asset Explorer is the cornerstone of the modding process and it takes the place of offzip, Dragon Unpacker and Infuser, all of which are difficult to use and can be scary for would-be modders.

So, just open up the Asset Explorer and drag a cos file and a corresponding col file which you wish to edit into its left-hand pane.

Now, expand the entries for the cos file until you see and entry that says #EMO (HND_01.obj.emo) (HND will be replaced with your character's three-letter abbreviation) and highlight it. As you can see, the program will then load the costume model, which will appear spooky and gray (this is the ambiant occlusion map; nothing to concern yourself with, but I thought I'd mention it for completeness):

To see the col textures applied to the model, use the pulldown menu in the middle of the window to select an option that displays 'texture' (the one at the bottom, 'Shadowed + Ink Shader + Texture + Normal Map' looks the closest to what you would see in-game):

Throughout the skinning process, you can use this to preview your work without loading up the entire SF4 program just to check a small detail.

4. Extracting Textures

Back in the left-hand pane of the Asset Explorer, expand the col file structure (and the entry labeled #EMB (HND_01_01.col.emb)) until you see one or more entries named 'DDS.' If you click on it, the preview window will change to display the texture file:

Once the desired DDS is selected, if you right-click on the DDS entry, you'll see a contextual menu with an option to 'Extract...' Choose it and you will be offered a chance to save the extracted texture as a standalone DDS file. This is what we'll be editing in our paint program and then re-injecting later, so I like to name it something that will tell me its position in the DDS order later, such as "ryu-bag-1.dds" or whatever. At this point, I also like to make a backup of the original DDS texture for future reference.

5. Painting Your Skin

When you open your extracted DDS texture(s) in your paint program, be it Photoshop or GIMP, it will bring up a dialog box asking you some questions. It's fine to skip loading MIP maps and to 'Load Using Default Sizes.'

I won't go over how to use the paint programs here (that's up to you to figure out), but some things to keep in mind:

A. Straight-up 'painted' textures usually look like crap. You're often better off using the hue/saturation tools to change the existing textures (there are obviously plenty of exceptions to this, so try things out and see what you like).

B. Some, though not all, textures include transparency, via what is known as an 'Alpha Channel.' I won't spend much time on it in this tutorial, but it is the cornerstone of another modding trick, known as 'col-based transparency.' I just wanted to mention it here so you're aware of it.

C. Since you'll be applying these textures to curved, irregular models, what looks like a straight line in Photoshop does not always look straight in-game. Frequently check your work in the Asset Explorer to ensure everything looks right and save yourself time and effort later.

6. Saving

Saving is a little more complex than hitting ctrl+S. After you name your file and choose its destination, a new dialog will pop up with a bunch of esoteric options:

We need our new texture to have exactly the same filesize as the original or the game will choke on it and crash. So, we'll want to 'Generate MIP maps' and make sure we select the correct DXT compression from the pulldown menu. Remember that backup I suggested at the end of Step 4? To find out which DXT compression to use, take your backup and open it with Nvidia's Windows Texture Viewer tool:

Along the bottom of the window, we can see the format, in this case, DXT5, so that's what we'll save our new texture as.

7. Injecting Your Texture Into the Col File

Now, back to the Asset Explorer. Navigate to the DDS textures and select the one you wish to replace. Right-click to bring up the contextual menu and, this time, choose 'Inject...' and browse to your new texture. If it complains about the filesize being incorrect, you have messed up something, probably in either resolution or one of the saving options, so go back and try to find your error. If not, you can click back on your model and see how it looks:

That's it. You've made your first skin. Congrats!

Once you feel comfortable with this process, you can move on to hex-editing the col file to create transparency effects or material swapping, making custom Normal Maps and directly editing the 3D mesh model.

Read More

How to Extract SSF4 Data From an Xbox 360 ISO

For people who want to get into using files from Super Street Fighter 4 on Xbox 360 with their PC version of vanilla Street Fighter 4, you have to go through a number of steps that have never been appropriately documented, so here goes:

1. Collecting the right tools for the job

First off, you need a copy of SSF4 in ISO format. I don't want to know how you get it, but I recommend purchasing it and then ripping it to your PC using the 'hot swap' method.

Next, we need a copy of isoextract, which extacts the data from the 360 disc image. You can download it here or here.

We also need QuickBMS, a script-based file extractor written by Luigi Auriemma, as well as a script to use with it. You can get QuickBMS here and the extraction script here or here.

2. Extracting the ISO

Open up isoextract and you should see this screen:

Using the buttons on the upper-right, click on 'choose ISO-folder' and navigate to the directory where your SSF4 ISO is stored. Next, click on 'choose destination' and select a directory where you want your extracted files to reside.

Then, just click the big button marked 'go' down in the bottom right.

Now, once it's all finished, if you navigate to your extraction directory, you'll find it has created a directory structure from the disc. Go to archive > battle and you should see a file named 'battle.eaf.' This guy has all of the goodies, so we gotta get them out using QuickBMS.

3. Extracting the files

Open QuickBMS and it should pop up a console window like this:

It should also automatically pop up an explorer window, which you can use to navigate to the QuickBMS script we got back in Step 1.

Next, it will pop up another explorer window, which we will use to navigate to our battle.eaf file.

Then, it will pop up a final explorer window, which we will use to select our output directory. I just chose that same 'battle' directory.

Now, back in the console window, you should see a whole bunch of output stream by, listing the files that are being extracted.

That's it. You're done. You should have a complete file structure available now, with access to all of the proper files, including character and stage data. Most of this can be opened with the latest version of piecemontee's Asset Explorer, using the new support for big-endian files.

Read More

SF4 Beginners Guide to Material Attribute Swapping

Credit for this tutorial goes to alekqz, I just cleaned it up a bit.

This tutorial will show you how to give a body part a reflective, metallic look, but a similar process can be used to grab other materials, such as Akuma's glowing eyes.

1. First, open a *.cos.emz file using piecemontee's Asset Explorer and look for the body part you wish to modify, in this case, Zangief's upper body:

Take note of the name used to reference the body part, in this case, 'body.'

2. Next, open a decompressed *.col.emz file in a hex editor (I use the free Frhed, but any hex editor will work) and search for that body part name:

Below the name, you will find the material type attribute, usually something like SpcBumpBrush with some more letters and stuff after it, like this:

3. Now, we want to overwrite that material type with 'SpcEnv_W.' In hex, we want to paste in (53 70 63 45 6E 76 5F 57 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1E 00 00 00).

As with all hex-editing in SF4, it's very important that you overwrite because the resulting files must be *exactly* the same size as the original or the game will crash. It should look like this when we're finished:

4. Next, we need to scroll down to the bottom of that section, just before the next section starts, and look for BrushA, BrushB and BrushC, like this:

We want to replaces those Brush entries with ReflectCoeff (52 65 66 6C 65 63 74 43 6F 65 66 66), ReflectFresnelBias (52 65 66 6C 65 63 74 46 72 65 73 6E 65 6C 42 69 61 73) and ReflectFresnelCoeff (3C 52 65 66 6C 65 63 74 46 72 65 73 6E 65 6C 43 6F 65 66 66), respectively (forgive the typo in the pictures; it's Fresnel, not Fesnel):

5. Finally, in the case of metal effects, we have to choose how reflective we want to make the material (also known as 'specularity'). This is controlled by modifying the spaces after the Reflect* entries. For a chrome-type effect, change the last 2 numbers in each section to @ symbols (40 40), like this:

For an enamel-type effect, the last 2 numbers after ReflectCoeff and ReflectFresnelCoeff need to be a Euro symbol and a question mark, like this (the last 2 after ReflectFresnelBias should be blank--or 00 00 in hex):

For a polished effect, the last 4 numbers of the sections need to be changed to the hex code of (CD CC CC 3D), (CD CC CC 3D) and (66 66 66 3F), respectively, like this:

Save your file and you're done!

These are the only 3 metal effects known so far, but there may be more, so be adventurous! Experiment!

Update 10/18/2010: sensibeat tracked down 3 more metal effects:

metal_gold (less reflective):
ReflectCoeff ÍÌL= (CD CC 4C 3D)
ReflectFresnelBias .×#< (0A D7 23 3C)
ReflectFresnelCoeff ÍÌÌ= (CD CC CC 3D)

metal_silver (more reflective):
ReflectCoeff €? (80 3F)
ReflectFresnelBias ÍÌÌ= (CD CC CC 3D)
ReflectFresnelCoeff €@ (80 40)

crystal (highly reflective, mirror-like):
ReflectCoeff ÍÌÌ> (CD CC CC 3E)
ReflectFresnelBias 333? (33 33 33 3F)
ReflectFresnelCoeff ? (3F)

One word of caution: you'll want to modify the DDS textures to look like whatever material you're trying to mimic but don't make it too dark, as the reflection can make it hard to see.

Read More

Refutation of G4TV's Metroid: Other M Review

I just got done reading a review of Metroid: Other M by g4tv.com and had a number of disagreements with the author, so I thought I would address them here.

The author takes the stance that, not only is the game technically bad and unfun, but the story presents Samus as a childish, vulnerable brat pining for male validation, thereby shattering her image as a tough, feminist role model, unique amid the sea of helpless-princess-bimbos in video games.

From a technical standpoint, I thought the game was fun and felt like a real sequel to Super Metroid, which the Prime series was never able to do. I agree that the IR-driven scanning/missile dynamic is a little frustrating at times, but I thought it was a decent way to sort of bridge the first-person Prime series and the traditional sidescrolling entries.

The missile/health regeneration dynamic is also a little strange in the context of the series, but it's just a fact of modern combat games, in my opinion. I don't like it in Halo/Gears of War/Modern Warfare/Generic SHOOTAN GAEMS either, but I can live with it.

As for the storyline, this game was much more story-driven than previous games, which often featured no dialog (or really even characters) at all. Now, this is an important point: in previous games, Samus was a (nearly) silent protagonist and it was largely up to the player to decide whether her silence was stoicism or something else entirely.

First off, the g4 reviewer takes issue with the fact that Samus doesn't discover her weapons throughout the environment as she did in previous games, and instead is holding them back on order of her former commanding officer. While the reviewer described this dynamic as "painfully stupid," I find it less so than it would have been to find a bunch of suit-compatible Chozo artifacts scattered around the game's setting, which is just a Federation ship and not an ancient planet. I guess a more satisfying (to me) option would have been for her to decide on her own when she needed to use the items, but that wouldn't make much sense either (why would she *not* use a super missile to open a stubborn door and thus ruin the whole 'metroidvania' mechanic?).

As for the story, I have some significant disagreements with the reviewer's interpretation. She seems to want Samus to be a butch, emotionally void ass-whupper--of which there is no shortage in video games--with her sex being the only discernible difference from Halo's Master Chief. I think this view is belied by previous games, though, where she shows compassion for the baby metroid and allows it to cling to her rather than just blasting it when she has the chance.

Likewise, the reviewer interpreted her deference to Adam Malkovich as weakness, where I saw it as an effort to show respect when she previously had not. She left his command to become a bounty hunter in the first place, so--when she encounters him and her former squadmates at the start of this game--she follows his commands by her own choice. In the cutscenes, we see that she didn't follow his orders very well when she was a cadet, so to follow his orders of her own volition shows maturity, not childishness. Plus, part of the story is that she is reliving painful events from her past in a sort of brutal alien Groundhog Day, which causes her to reexamine her youthful indiscretions.

The reviewer states, "Confronted by her longstanding nemesis, Ridley, [Samus] is spliced into flashes of a little girl, crying and afraid, despite the fact [that] she has already defeated Ridley at least FOUR times already, once when he was a powerful robot." I took issue with this statement because, in an earlier cutscene, Samus mentions her relief that her nemesis was killed in the blast that destroyed Zebes. And then, when she finds Ridley resurrected, she is naturally taken aback and experiences a moment of paralysis as she experiences flashes of her childhood encounter with him. This does not seem out of place to me. Perhaps out of character, but as I said before: she never really had any character to begin with, except what we projected on her from our own imaginations.

In Metroid: Other M, a partial reboot of the series, we get a view into the backstory and motivations of gaming's baddest bitch, but it turns out she's not as badassed as some people thought or would have liked. Perhaps this insight into her mind/feelings was a bad choice on the part of her developers, akin to giving Gordon Freeman a bland voiceover and cornball catch-phrases, but I didn't think it was that bad. Instead, I thought it provided a modicum of motivation to see the story progress rather than the same ol' mindless backtracking to pick up that just-out-of-reach missile pack.

I will concede that I thought the "military obfuscation" aspect of the story was just kinda dropped for the most part toward the end of the game, and I would have liked to see it explored more fully, rather than focusing so much on Samus' feelings. Nevertheless, I found the entire experience to be satisfying and a good, faithful addition to the series.

It's interesting that Nintendo catches a lot of flack for not pushing their games into new directions, yet every time they try, they get slammed for destroying people's preconceived notions of the characters. However, these characters were created at a time when any personalities had to be inferred due to technical limitations, and--as we've all seen with book-to-movie conversions--the "Hollywood" version never stands up to our own imaginations.

Read More

Ubuntu Maverick on VirtualBox

The third alpha release of Ubuntu 10.10 Maverick Meerkat was just released, so I figured I'd give it a shot in the ol' VirtualBox VM.

The Pros: Mouse pointer integration is built-in, so you don't have to deal with reinstalling Guest Additions every time you do a kernel update.

The Cons: Since Maverick started using a new X-Server (1.9), Guest Additions no longer do their acceleration and resolution magic. This includes manually adding resolutions to the xorg.conf, so until something changes, it's 800x600 all the way...

UPDATE (9/30/2010): Looks like the open source edition of VirtualBox has us covered now. Just open up a terminal and type (all one line):

sudo apt-get update ; sudo apt-get install build-essential linux-headers-$(uname -r) ; sudo apt-get install virtualbox-ose-guest-x11

Thanks for the tip, Anonymous!

I'm putting this here for my own reference, but if you want to automatically mount your host's shared directory in your Linux guest OS, you can edit /etc/fstab thusly:

[host's name of directory] [mount point] vboxsf defaults 0 0

which, for me, translates to:

vbox_share /media/vbox vboxsf defaults 0 0

No more tedious mounting and no mucking around with startup scripts running as root...

Something else I've encountered, not specific to Maverick, but I figured I'd share it here anyway:

I decided to give BTRFS a shot, so I formatted my partitions with it (it still won't support booting, so I had to make a small boot partition with ext4, but / and /home are BTRFS). Unfortunately, there is a hellacious bug somewhere that causes apt-get update/upgrade to be godawful slow (like, 4 hrs. for a big-but-still-reasonable upgrade) with this FS. However, I came across this blog post that suggests using a patched copy of dpkg, which is available from this ppa, which specializes in BTRFS-optimized packages. To add the PPA, add it to your sources in Synaptic or open a terminal and type:

sudo apt-add-repository ppa:brian-rogers/btrfs

Then just update/upgrade as usual. The package comes with a pretty scary warning about how it can hose your system, so you should take frequent snapshots (that's why you're using BTRFS anyway, right? Right??). Unfortunately, this didn't really fix my problem, so it's back to ext4 for me. :(

Once perk of reinstalling using the latest Beta release package is that I got to check out the new installer. It looks really nice and they've done some really smart things with concurrency whereby it starts installing your system before it asks you all of the time-consuming personalization questions. All in all, installation was easy and fast, fast, fast!

Everything else appears unchanged since Lucid.

I'll update this post as I find anything else out. If anyone has anything to add, feel free to leave a comment.

Read More

Ubuntu 10.10 Maverick Meerkat on Acer AspireOne

One caveat before you read any further: my AspireOne is old as hell (9" w/ 8GB SSD) and these problems/fixes may not work on newer models.

Ok, now with that out of the way, I've got some good news: Maverick works great on my AO. Installation was fast and painless (it only took around 20 min., I think), and booting is super-quick (something like 15 seconds to a working desktop in my experience). Wireless works out-of-the-box, as does the wifi activity light :O. Unfortunately, the SD card slots are still b0rked. To get them working, we can use the same fix from my previous AO/Ubuntu post:

Open up a terminal and type:

sudo gedit /etc/modprobe.d/options

Then paste in:

options sdhci debug_quirks=1

Reboot and you should be all set.

I also ran into a problem trying to create shared directories using samba. The system automatically installs the samba packages just fine, but when I try to actually make a share, it fails with the error "Failed to execute child process "testparm" (No such file or directory)." If this problem affects you, too, hop back into your terminal and type:

sudo ln -s /usr/bin/testparm.samba3 /usr/bin/testparm ; sudo ln -s /usr/bin/net.samba3 /usr/bin/net

This should get you all fixed up. You don't even need to reboot again.

Some other things to note about this new release:
1. Virtualbox no longer needs Guest Additions installed to utilize mouse pointer integration.
2. The new unity netbook interface sucks. I think the idea of putting the launcher bar on the left is great, and I like the look of it, but I could never track down where they had the gnome-terminal hidden, and it wouldn't show up when I searched for it in their application search applet. Also, hitting Alt+F2 wouldn't bring up the execution prompt, so after a few minutes of frustration, I uninstalled it and went back to the standard interface.

I'm happy to see the improvements they've made in this new release and I look forward to seeing what else comes in before the upcoming feature freeze. If you run into any other problems with this release, drop me a comment and I'll help however I can. Also, keep an eye on my PPA for packages of bsnes v1.0, which should be optimized enough for use on your AspireOne netbook.

Read More

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.

In the future, bsnes will serve a dual role: a modern, highly accurate emulation platform through which everyday users can relive their glory days, as well as a pristine, functional archive of SNES hardware. Like the Rosetta Stone, bsnes will be a digital translator that will ensure that SNES games can be understood and executed even without working SNES hardware. Thanks to byuu's unique and tireless efforts, the SNES will never disappear, even after the last console turns to dust.

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

Read More