Beginner's Guide to Face-fixing

If you've experimented with moveswapping across characters, you've certainly seen the horrible deformation that occurs to their faces, commonly known as "monkeyface."

This tutorial is going to show you how to swap movesets (we're actually swapping models, but it comes out to the same thing) without the monkeyface problem (except in cinematics, such as intro/outro and during ultras).

Background

Animations and movesets in Street Fighter 4 are stored in the ***.cmn.emz file. Specifically, facial animations are stored in the ***.fce.ema file, which is itself a component of the cmn.emz file. To transplant these face animations from one character alongside the moveset of another character, we're going to have to collect a few tools: piecemontee's Asset Explorer, Kensou's Tool and your favorite hex editor (I use the free and open source Frhed).

Getting Started

First, identify which characters we're going to mess with and backup their chara directories. I'll be using Chun Li's model (I'll refer to her as the 'donor') on Sagat's moveset (I'll refer to him as the 'receiver'), so I made copies of those files.

Next, run the donor's cos and col files through the Asset Explorer, along with both characters' cmn.emz files (in my case, CNL.cmn.emz and SGT.cmn.emz). This will decompress them and get them ready for modding.

Now, open the donor's cos and col files in a hex editor, scroll all the way down to the bottoms of the files and change the 3-letter character name references to match the receivers'. In my case, I changed the CNL instances to SGT (there will be 4 instances to change in the cos file and 2 in the col file). Then, rename the files to match (e.g., CNL_01.cos.emz to SGT_01.cos.emz and CNL_01_01.col.emz to SGT_01_01.col.emz).

At this point, you should copy those new donor model files over to the receiver's chara folder (in my case, the SGT directory) and make sure the game loads without crashing. If it loads ok, you should see some monkeyface. Good job, we're halfway there.

Extracting the CMN components

Now, open the receiver's cmn.emz file in the Asset Explorer. Click the 'plus' signs to expand the base file and the overall #EMB file, like this:

Then, left-click on the first section (#EMO (SGT.skl.emo)) to select it and then right-click on it and choose 'Raw dump...' Repeat this process for each section in the cmn.emz file except for the *.cam.ema file, which will crash the Asset Explorer if you select it. Unfortunately, we need that section, so we'll have to get it the hard way--via hex editor.

Isolating the cam.ema Component

Open the receiver's cmn.emz file in a hex editor and make your way down to the third section labeled '#EMA' (I find it easiest to search sequentially through the document for #EMA 3 times). It will be the last one in the file.

Now, write down where it starts, in my case x760e40.

Next, we need to find the end of that section, which is most easily accomplished by searching again, but this time for '#BAC.'

Now, select everything between that last #EMA (at the location we wrote down) and the beginning of #BAC

Copy it and paste it into a new file and save it with the appropriate name (in my case, SGT.cam.ema):

Ok, now that we have all of our receiver's cmn components extracted and isolated, we're ready to get our donor's face animation ready for transplantation.

Open the donor's cmn.emz file in the Asset Explorer and expand it just like we did with the receiver's cmn file earlier on. Left-click on the section labeled #EMA (***.fce.ema) and then right-click and select 'Raw dump...' just like before.

Now, we want to rename that file--in my case, CNL.fce.ema--to match the receiver's other files (you'll have to overwrite the receiver's original fce.ema file in the process, but we don't need it anyway, so no big deal). Alright, we're almost there. Time to rebuild the receiver's cmn file with the new face data using Kensou's Tool.

Repacking A New File

Open up the directory for Kensou's Tool, then navigate to 'sf4' and then the 'emz' directory (you might have to create this directory if it doesn't already exist). Take your receiver's 6 original cmn component files that we raw-dumped, along with the renamed fac.ema file from our donor, and place them all in the aforementioned 'emz' directory:

Go back into the sf4 directory and launch sf4tool.exe:

In the big pane to the right with all of the directory structure, double-click on the folder labeled 'emz,' then click on the left-hand button below that pane. It should then populate the smaller, lower-left pane with a bunch of paths referencing our cmn component files:

These files need to be in exactly the same order as the ones in the original cmn.emz file (skl.emo, skl.emm, obj.ema, fce.ema, cam.ema, bac and bcm) but they won't be by default, so we'll need to click into that pane and do a little manual reordering. Everything should be in order except for the last two, so just copy/paste their paths into the right spots.

Once that's done, click the right-hand button to combine everything. It should pop up this window:

and you should have a shiny new file named 'newpack.emz' alongside your original cmn component files in the 'emz' directory. Now we're really in the home stretch.

Testing it Out

Rename your newpack.emz file to match the receiver's cmn file--in my case, SGT.cmn.emz.

Copy that file into your receiver's chara directory and overwrite the old one (you made sure to make a backup, right? Right??) and go test it out.

If you did everything correctly, you should have a perfectly normal face:

Congratulations!

Read More

Mudlord's HLSL Shaders for BSNES

I came across a set of HLSL pixel shaders from mudlord that were intended for use with snes9x, so I formatted them for use with bsnes and everything seems to work just fine. You can download the whole pack here.

Here are some screenshots from a couple of them:

1. Emboss

Looks pretty cool but gets old quickly.

2. Blur 2

There are 4 different blur settings. The first one actually looks pretty decent, but the rest are too intense for me.

3. Pixelator

Hmmm. Can't really see shit... Kinda like if your favorite SNES game came out on Atari first.

4. Toon

This one actually looks really cool. It makes everything look like Yoshi's Island :D

There are a number of others in the pack, including all of the blurs, another take on bloom, a toon shader without the black outlines and a couple that cover everything with a wave mask.

This pack gives D3D users a bit more freedom beyond the lone Sepia filter that comes with bsnes, and I hope to add more of these in the future. I'll post them here if/when I come across them.

UPDATE (2/2/11):

I fiddled around with some and came up with a couple more. They're essentially functioning just like mudlord's 'emboss' shader, but they maintain color:

1. color emboss bright

2. color emboss mild (this one requires that 'smooth video' be enabled to work properly; similar results to smooth video+mudlord's 'sharpen' shader)

Read More

BSNES on Older Distros, such as Lucid and Squeeze

In addition to being on the forefront of SNES emulation, BSNES also utilizes cutting-edge programming techniques to maintain the cleanest, most easily readable code possible. Unfortunately, that means that older distros--even ones that are still well within their supported lifespan--may get left out in the cold.

However, BSNES forums user Themaister has done us all a favor and backported byuu's cutting-edge C++0x code to use the more widely supported C++98 standard, which allows it to be compiled on any version of GCC from 3.x on up. The only catch is that his work only applies to libsnes, the modular emulation core of BSNES in library form, so byuu's official Phoenix GUI is still off limits, as is his libsnes-driven Qt GUI.

Thankfully, Themaister has us covered here, too, by offering SSNES, his super-slim CLI-only interface to libsnes. Just like his C++98 port of libsnes, SSNES can be readily compiled with even extremely old versions of GCC, so any semi-modern distro should be able to use it just fine.

My PPA now contains Lucid packages for both libsnes (all three official cores, plus an snes9x-based core for legacy machines) and SSNES, which should also (hopefully) work on Debian Squeeze.

A few things I'd like to point out about SSNES:

1. It will accept a variety of audio drivers, including jack, which allows ultra-low latency :D

2. My package was built using dynamic libsnes linking, so it requires a libsnes package from my PPA to function

3. In addition to accepting BSNES-style XML shaders written in GLSL, SSNES will also accept shaders written in Nvidia's Cg language if you install the nvidia-cg-toolkit package

4. The default configuration file for SSNES is located at /etc/ssnes.cfg, but you can override this by placing another config file in ~/.config/ssnes

As always, let me know if you run into any problems with these packages.

Read More

Crimson Echoes and Flames of Eternity

These two ROMhacks for the legendary SNES RPG Chrono Trigger were just leaked on Reddit the other day and I happened across some bsnes-compatible UPS patches, which you can download here. (I didn't make these patches, btw, and I didn't upload them)

I haven't played through them yet, but they seem to work fine from what I've seen. They will get past the initial intro sequence and into the playable game, but I haven't tested any further than that.

They were tested with an unheadered Chrono Trigger ROM that had been run through snespurify.

I'll update this post with anything interesting I find in my playthrough.

Read More

Setting Up Pbuilder To Act Like Launchpad Build Farm

I build a lot of packages for my Launchpad PPA and I use a number of different systems to do it, so I find myself needing to set up pbuilder environments to test my build procedures pretty often. Unfortunately, documentation for this procedure is often out of date and/or goes into a lot of strange details and edge-cases that are unrelated to me, so I decided to write down my steps for future reference.

Here's what I do:
1. Install pbuilder and some other handy packages
Open up a terminal and type:

sudo aptitude install pbuilder debhelper devscripts build-essential

2. Tell the pbuilder environment that it is going to act just like the Launchpad build farm
Still in our terminal:

sudo pbuilder create --debootstrapopts --variant=buildd

This one takes a while because it's basically installing an entire system inside your existing installation, so grab a cup of coffee and watch the messages fly by.

3. Give it access to all official Ubuntu repositories

By default, your shiny new pbuilder environment won't have access to a lot of packages, so we'll want to add mirrors for common Ubuntu packages, as well as our own PPA to the pbuilder configuration file. So, still in a terminal, type:

nano ~/.pbuilderrc

and paste in:

OTHERMIRROR="deb http://archive.ubuntu.com/ubuntu [YOUR UBUNTU VERSION] main restricted universe multiverse | deb http://archive.ubuntu.com/ubuntu [YOUR UBUNTU VERSION]-backports main restricted universe multiverse | deb http://archive.ubuntu.com/ubuntu [YOUR UBUNTU VERSION]-security main restricted universe multiverse | deb http://archive.ubuntu.com/ubuntu [YOUR UBUNTU VERSION]-updates main restricted universe multiverse"

and we'll also pipe on a section for our PPA, so we can use our own packages as dependencies, which in my case looks like this:

| deb http://ppa.launchpad.net/hunter-kaller/ppa/ubuntu maverick main

4. Make our pbuilder trust packages from our PPA

First, we'll login to our pbuilder environment:

sudo pbuilder --login --save-after-login

Then, we'll give it the public key to our PPA, just like if we were adding it to our own keyring:

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys [YOUR PUBLIC KEY HERE]

If all goes well, you can leave your pbuilder environment by typing:

exit

5. Update our environment with these new packages

Still in our terminal, type:

sudo pbuilder --update --override-config

This should get you in pretty good shape. Let me know if you run into any issues.

Read More

Bloom Pixel Shader for bsnes

I did some digging around online and came across some bloom filters written in GLSL. The one on this site looked the best to my eyes, so I converted it to work with bsnes and tweaked the settings a bit to achieve the desired effects.

What I found while playing around with it is:

1. Turning on 'Smooth video' seems to amplify the bloom effect.

2. The same amount of bloom looks different on each game, depending on the overall dark/light-ness of the game.

3. Combining excessive bloom with bsnes' scanline filters can make a pretty decent approximation of a CRT. While this is in no way as accurate or as nice looking as cgwg's CRT shaders, it may be an option for the many people whose video cards don't have enough horsepower to handle that complex shader.

First, I made a simple, fairly subtle (as far as bloom is concerned...) shader, which looks like this:

Looks pretty nice, eh? Unfortunately, the exact same shader settings look awful in Super Mario World:

One big flare-out... All I need is some brown and lens flare and I'll have next-gen graphics.

However, if you add in a scanline filter, things can really get evened out. In fact, you can use the different scanline intensity filters on a game-to-game basis to attenuate the inconsistency of the bloom effect. For example, here's a shot of Super Mario World with even more bloom added and 'smooth video' checked, but with 100% scanlines to chill things out a bit:

As you can see, it kinda gives it a plasticy, oversaturated look, but it's sort of charming, if you ask me.

In contrast, those exact same settings in Chrono Trigger--an altogether darker game--produce a really nice CRT-style effect, like this:

As you can see, even the bright parts don't suffer from excessive flare-out and the color bleed into the scanlines from the bloom provides an effect that is reminiscent of the phosphor glow on a CRT display.

One more shot of Chrono Trigger, this time using heavy bloom, 25% scanlines and smooth video:

I have asked WhateverMan if he would release his shader code under a permissive license. If he does, I will post my simplebloom and heavybloom versions here for download.

Update (1/19/11): WhateverMan was nice enough to allow his work to be distributed/modified under the GPL, so you can download the heavybloom shader here and the simplebloom shader here.

Update (2/2/11):

I also made a simple scanline shader that works with or without video smoothing:

For best results, use it along with a scale factor of 4x. Otherwise, the pixels won't line up with the scanlines correctly.

UPDATE (2/28/11): I made a scanline shader that works with a 3x scale factor, as well. You can download it (and the other GLSL shaders) here.

Read More

Added NEStopia to my Ubuntu PPA

I added packages for the latest Linux port of the awesome NES emulator NEStopia to my PPA. The only problem is that I don't know how to make a package create a ~/.[appname] config directory and/or put required config files into that directory at first run. If anyone knows how to do that, I'd appreciate the info. EDIT: Ok, I fixed it. I created a quick-and-dirty bash launcher script that will check for the required directory and file and create them if needed.

NO LONGER NECESSARY:

Unless/until I find out how to do that, anyone wanting to use my package will have to manually create the config directory and at least create a husk of an inputs file by opening a terminal and typing:

mkdir .nestopia ; touch .nestopia/nstcontrols

From that point on, everything should work fine. If you are super-scared of hitting the terminal and would feel better with a script, you can download and run this script and it will take care of it for you.

Let me know if you run into any issues or have any questions.

Read More