Street Fighter x Tekken handles colors in a completely different way from Street Fighter 4 and its derivatives as a result of the color customization feature. Instead of just pulling colors and textures directly from the texture image, the textures look like this:
and the game calculates the appropriate color based on a series of numbers, which represent a color mix from the texture image’s color channels. These numbers are stored in the *.obj.emm files–specifically the ‘MatCol’ attributes–alongside the various other object materials and material attributes.
There are two main ways to edit *.obj.emm files, manually via hex or using NanjouJ’s MatEdit tool, which is a little more user-friendly than fiddling with hex codes. In this tutorial, we’ll be using MatEdit to copy colors from another color file, rather than calculating the color from scratch. If you would like to calculate an entirely new color from scratch, this post from yajirobe does a good job of explaining it.
So, first thing, we need to make backups of any of the files we plan to mess with. Once you’ve done that, go download MatEdit from the AE wiki’s ‘tools’ page and identify which files you want to work with. I’m going to be copying a color from one of Ryu’s *.obj.emm files into one of Poison’s.
Now, create a new folder (on your desktop or wherever) and copy matedit.exe and both Ryu and Poison’s *.obj.emm files into it. Then, hold ctrl+shift on your keyboard and right-click somewhere inside that folder, and choose ‘Open command window here’:
 This will open a command line window, but don’t freak out. I’m going to tell you exactly what to type in.

First thing, we want to export the materials from both of our files, using the syntax “matedit.exe export [target obj.emm file] [newfile.txt].” So, in my case, I’m going to type (replace PSN/RYU and poison/ryu as appropriate for your files):

matedit.exe export PSN_01_01.obj.emm poison.txt

and

matedit.exe export RYU_01_01.obj.emm ryu.txt

If done correctly, you should have two new files in your directory, in my case, poison.txt and ryu.txt. At this point, we’re done with the command line for now, but don’t close it yet because we’re going to need it again later.

For now, open both files in the text editor of your choice. Notepad works, but I prefer Notepad++ (it’s free and awesome; go get it).

Open both of the txt files in your text editor. You’ll see a series of sections which correspond to the various objects that make up the character’s model. In each section, there are a bunch of variables and values that tell the game how to render each object. The ones we’re worried about today are the MatCol variables:
 You’ll notice that I highlighted just the *R, *G and *B MatCols, which correspond to the red, green and blue color channels, respectively, and not the *A MatCol, which corresponds to the Alpha channel. You shouldn’t mess with the alpha value if you’re just trying to change colors.

So, lets say we want to take the color of Ryu’s pants–i.e., white–and copy it over to Poison’s hair. To do this, we would hop over to our ryu.txt file and search for ‘pants.’ Then, scroll down through his ‘pants’ section until we find the MatCol subsection.
 In this case, I only have a single color, MatCol0 to choose from, but some models will have multiple color groups, such as MatCol1 and MatCol2. These MatCols represent the color groups that can be customized in-game, so make sure you’re choosing the correct one.

Copy those values and then switch over the poison.txt file and search for ‘hair.’ Scroll down to the MatCol section and replace the values there with your new, copied values:
 Great, we’re almost done.

The last step is to import the modified text files back into the target *.obj.emm file. So, back to your command line window (if you didn’t listen earlier and closed it, just open a new one) and type:

matedit.exe import poison.txt PSN_01_01.obj.emm

Now you’re ready to test it out. Copy the PSN_01_01.obj.emm file into your [install directory]\resource\CMN\battle\chara\PSN folder, overwriting the one that was there (you made a backup, right??) and go check it out.

If you had calculated a new color from scratch using yajirobe’s instructions instead of copying the color from some other costume, you would go through the exact same steps, only using your calculated color numbers instead of the ones from Ryu’s pants.

That’s it. Have fun, share your work and always make backups.

This tutorial will cover the very basics of using Waterine’s ClgEditor tool to create your own combo challenges for SSF4AE. For this, we will need the ClgEditor and Dantarion et al’s Ono! Editor.

When you first run the ClgEditor, click the button to ‘Open…’ and browse to your installation directory (usually C:\Program Files (x86)\Steam\steamapps\common\super street fighter iv – arcade edition), then go to …\resource\battle\chara and go into the folder for the character whose Trial Mode you wish to modify. It should filter the folder contents such that the only file displayed is our desired CLG file, in my case, CMY.clg.

Once the file is loaded, you can see the list of challenge levels on the left. At the top of the window you should see a pulldown menu labeled ‘Ultra Selection,’ which lets you select which Ultra combo should be loaded for the challenge, and another pulldown labeled ‘Target State,’ which determines how the dummy (Dan) should act (for use with situational combos, like ones that must start with a counterhit or only work on jumping opponents).

The area underneath those pulldowns is where most of the fun happens.

In the ‘Scripts’ section, the first button from the left (looks like a sun) creates a new command, either an ‘attack’ or a ‘script,’ which you can choose between using the ‘Criteria type’ pulldown menu to the right. Attacks are just your normal actions while scripts are movement actions, like dashes and FADCs.

The ‘Criteria indices’ field tells the game which moves it should accept as a successful command. If any strength of a move will do, as is the case with many of the early challenges, you must include each index that fulfills the criteria. For a regular special move (light, medium, hard and EX), you would need entries for all four strengths.

Back in the scripts window, each command represents one discreet portion of a challenge, and you can show up to 8 on the screen. You can go beyond 8 in the list, but unfortunately the display doesn’t scroll in-game, so the player won’t be able to see the rest.

To the right, you can choose what on-screen instructions and input help to display from the respective pulldown menus.

So, lets say I want to change Cammy’s first challenge from a simple Spiral Arrow to a Cannon Spike > FADC > EX Cannon Spike.

Step 1. Select the first trial from the levels list and hit the ‘X’ button under Scripts to delete the existing command. Then, click the sun button to create a new command. Our first command–Cannon Spike–is an attack, so choose that from the Criteria type pulldown.

Step 2. Next, we need to fill in the Criteria indices field with the indices for the move (I cheated and stole them from Challenge #3), in this case, 100, 101, 102, 103, 104, 105.

Step 3. Under ‘On-screen command text’s last pulldown menu, we want to select Cannon Spike, and under ‘Help menu command text’s last pulldown menu, we want to select Cannon Spike Input.

Great! There’s our first command. Now, we need to make another.

Step 4. Click on the sun button again, but this time we’re going to use a movement script, so select ‘Script’ from the Criteria type pulldown.

As in step 2, fill in the Criteria indices field with the appropriate inputs, in this case 325 (I stole that from a later challenge, as well; are you seeing a pattern here?).

Likewise, we’ll fill in the On-screen command text and Help menu command text, which are a little weird for FADCs: in the first pulldown under On-screen commant text, choose ‘EX,’ and under the third pulldown, choose ‘FocusCancel.’ Then, under Help menu’s first pulldown, choose ‘EX’ again, and under the third, choose ‘MP+MK.’

Step 5. Alright, moving right along, click the sun button one more time and choose the ‘Attack’ criteria. Up until now, all of the moves we’ve wanted to use could be easily pilfered from other challenges. However, no challenge requires an EX Cannon Spike specifically, so we’ll have to figure this one out on our own. To do it, open up the Ono! Editor and open Cammy’s BCM file. You should see a window that looks something like this:

Click on the bottom button, labeled “Hitbox Table.” It should open a new window that looks something like this:

There’s a lot of really great information available in this window, but we really only need the numbers on the far left in front of the move names. So, scroll down until you find your desired move, in my case EX Cannon Spike, which is listed under #106 and #107. Now, enter those numbers into the Criteria indices field, separated by commas and spaces as necessary. Fill in the appropriate on-screen command and help menu text, and you should be all set. Click the save button and lets go check it out by copying it into our …\resource\battle\chara\CMY folder (don’t forget to make a backup!!).

Now, as a note, you can make your combos against any version of the characters’ movesets you like (Super is the default, of course, but you can use movesets from AE, 2012 or even custom movesets created in Ono!), you just have to copy the appropriate BAC/BCM files into the …\resource\battle\chara\*** folder to overwrite the ones that are already there.

If you create something cool, be sure to share your work with the community, and always always always make backups!

This post compares the popular HQx interpolation algorithm with the newer xBR, which has been covered in some of my other posts. If you just want to download the filters, you can get them from the link at the bottom of the post.

Since Maxim Stepin created the HQx interpolation algorithm more than a decade ago, it has been the favored real-time interpolation filter for the emulation scene. The way it works is it looks at each pixel and then compares its color to that of the 8 surrounding adjacent pixels. If it finds a match, the filter then compares the resulting pattern with a predefined lookup table to guess what the original pattern was trying to represent.

For example, if we take a pattern like this:

and scale it up via nearest neighbor–that is, a straight upscale with no interpolation–you end up with this checkerboard pattern:
But, if you use HQ2x, you end up with this:

The algorithm guesses that the original pattern was trying to represent a diagonal line rather than a checkerboard pattern, so it fills in the gaps to compensate.

Recently, a Brazilian programmer by the name of Hyllian (aka Jararaca) developed a new algorithm that actually improves on HQx, known as xBR (stands for “a filter that scales By Rules”).

xBR works much the same way as HQx insofar as it is based on pattern recognition, and it would upscale the above pattern with the same result. However, it goes further than HQx by using a 2-stage set of interpolation rules, which better handle more complex patterns such as antialiased lines and curves.

You can read more about Hyllian’s algorithm here.

Lets take a look at how they compare on a real-world example (HQ2x on the left, 2xBR on the right; click to embiggen):


As you can see, 2xBR does a much better job on smoothing curves without getting chunky (see Yoshi’s nose and the dragon coin). It also does a better job on the ‘eyes’ of the block, which is represented as a diagonal line with 2xBR compared with the series-of-squares look with HQ2x.

Here’s another comparison, using Earthworm Jim’s title screen:
 

And here’s a third comparison, using the title screen to Earthworm Jim 2:

HQ2x actually does a slightly better job at getting a smooth gradient around the highlight in Jim’s eye, but the rest of the image is a mess. xBR has smoother, straighter lines at every color transition.

Additionally, the xBR algorithm scales to higher scale factors much more easily than the HQx algorithm, making 3-, 4-, 5- and higher versions faster and more effective.

At very high scale factors (5 and higher), the xBR algorithm can obliterate some small details, such as pupils in eyes, dots, and so on, so Hyllian introduced some additional calculation to compensate (5xBR-v3.5a on the left [uncompensated] vs 5xBR-v3.5b on the right [compensated]):

Of course, this compensation comes with its own drawbacks and false-positives, so which version works better varies on a game-by-game basis.

Another interesting aspect of this algorithm is that it works very effectively on images already upscaled with xBR, so you can easily get absurdly large images (scaled 1x, 3x, 9x and 27x) with just a few iterations:
This puts it in direct and favorable competition with this vectorization method that recently made the rounds. xBR manages to maintain detail a bit better than the vectorizer, and it can actually operate in real-time, unlike the vectorizer.

You can download these shaders from my Mediafire repo (most are available in either XML/GLSL or Cg format, both of which are compatible with SSNES).

This post compares the popular HQx interpolation algorithm with the newer xBR, which has been covered in some of my other posts. If you just want to download the filters, you can get them from the link at the bottom of the post.

Since Maxim Stepin created the HQx interpolation algorithm more than a decade ago, it has been the favored real-time interpolation filter for the emulation scene. The way it works is it looks at each pixel and then compares its color to that of the 8 surrounding adjacent pixels. If it finds a match, the filter then compares the resulting pattern with a predefined lookup table to guess what the original pattern was trying to represent.

For example, if we take a pattern like this:

and scale it up via nearest neighbor–that is, a straight upscale with no interpolation–you end up with this checkerboard pattern:
But, if you use HQ2x, you end up with this:

The algorithm guesses that the original pattern was trying to represent a diagonal line rather than a checkerboard pattern, so it fills in the gaps to compensate.

Recently, a Brazilian programmer by the name of Hyllian (aka Jararaca) developed a new algorithm that actually improves on HQx, known as xBR (stands for “a filter that scales By Rules”).

xBR works much the same way as HQx insofar as it is based on pattern recognition and it would upscale the above pattern with the same result. However, it goes further than HQx by using a 2-stage set of interpolation rules, which better handle non-45-degree angles and curves.

You can read more about Hyllian’s algorithm here.

Lets take a look at how they compare on a real-world example (HQ2x on the left, 2xBR on the right; click to embiggen):

As you can see, 2xBR does a much better job on smoothing curves without getting chunky (see Yoshi’s nose and the dragon coin). It also does a better job on the ‘eyes’ of the block, which is represented as a diagonal line with 2xBR compared with the series-of-squares look with HQ2x.

Additionally, the xBR algorithm scales to higher scale factors much more easily than the HQx algorithm, making 3-, 4-, 5- and higher versions faster and more effective.

At very high scale factors (5 and higher), the xBR algorithm can obliterate some small details, such as pupils in eyes, dots, and so on, so Hyllian introduced some additional calculation to compensate (5xBR-v3.5a on the left [uncompensated] vs 5xBR-v3.5b on the right [compensated]):

Of course, this compensation comes with its own drawbacks and false-positives, so which version works better varies on a game-by-game basis.

Another interesting aspect of this algorithm is that it works very effectively on images already upscaled with xBR, so you can easily get absurdly large images (scaled 1x, 3x, 9x and 27x) with just a few iterations:
This puts it in direct and favorable competition with this vectorization method that recently made the rounds. xBR manages to maintain detail a bit better than the vectorizer, and it can actually operate in real-time, unlike the vectorizer.

You can download these shaders from my Mediafire repo (most are available in either XML/GLSL or Cg format, both of which are compatible with SSNES).

Due to a potential for exploding batteries, Apple recently instituted a recall on all 1G iPod Nanos, of which I had two (one with 2GB capacity and one with 4GB). I sent them off and, after a pretty long turnaround time (nearly two months altogether), I’ve received my first replacement: a brand new 6th generation touchscreen iPod Nano with 8GB capacity

If you happen to have one or more of the old models, I recommend you take advantage.