|  |  |  | SFF file building |  |  |  |

OK, let's assume we have some perfectly ripped sprites, all cropped and paletted. It's the moment to put them all together into a SFF file in order to be readable by Mugen. There are basically two ways to do this:

Option 1: Use the "sprmaker" program. This tool is included in the "Mugen tools" distributed by Elecbyte (Mugen's authors) itself. Sprmaker is a MS-DOS program which takes a text file with info about each sprite and palette sharing as input, and outputs a SFF file. Honestly, this is a rather cryptic method which requires you to know well what you are doing, but it works and allows you to do everything you need. Besides, once practiced enough it's a pretty fast method, and very safe too, we can build the SFF anytime as long as we have the text file ant the sprite, as opposed to other fancier programs which work directly on the SFF so, if they freak out and corrupt the file, you have no choice but start over from the beginning (it's really recommended to make backups often).
To use sprmaker first we need to create the text file with the information about the sprites. An example of this file would be the following:

;General options (at the beginning of the file). # ;Palette (it means nothing, but it's required). 1 ;This tells sprmaker all the sprites will share the same palette.
2
;SFF filename and path (opcional) where sprmaker will create the file.
character.sff
;
;
;
; ** Small portrait**
;PCX file with the sprite.
retr_p.pcx
;Group #.
9000
;Image # in that group.
0
;Axis' "x" component.
0
;Axis' "y" component.
0
;
;
; ** Big portrait **
;Individual options for this specific sprite.
#
;Paletta (again, it means nothing, but it's required).
1
;This will tell sprmaker this sprite will have an independent palette.
;We can only do this in this sprite (the big portrait).
1
port_b.pcx
9000
1
0
0
;
;
; ** Standing **
stand1.pcx
0
0
49
108
stand2.pcx
0
1
49
108
stand3.pcx
0
2
49
108

Feeding this file to sprmaker would generate a SFF with five sprites: small portrait, big portrait (with a standalone palette), and three standing sprites. Let's take a look at it.
Lines starting with a semicolon (;) are simple commentaries, which will be ignored, but make the file much easier to read by us. There can't be blank lines, so to separate sections we'll insert blank comments. OK. The six lines at the beginning (three if we don't count the comments) tells sprmaker that all sprites will share the same palette, which is exactly what we want and for a character's SFF we should leave it that way. Then we'll specify the location and name of the generated SFF (for instance, it could have also been "..\character.sff" or "c:\mugen\chars\character\character.sff"). Below there is the info needed for each sprite, which is composed of five elements: location and name of the sprite's PCX file, its group #, its image # and its axis' coordinates. Repeat this for every sprite and we'll have a working file ready. Now, take a close look at the big portrait definition: if we want it to have a stanalone palette, we need to indicate it as shown in the example. If we want it to share its palette as the rest of the sprites, we'll write nothing special there. Now, in order to create the SFF, we'll run sprmaker this way:

sprmaker < textfilename.txt

This will generate (if we did it right) an unoptimized SFF file which will compile very fast (what is a really good thing when there are many sprites to compile), which is enough while we're working in the character, unless we're really short on memory. If we want to add more sprites to the SFF, we'll add its data to the text file and will recompile the SFF. When we're ready to show our creation to the world, we should optimize the SFF with:

sprmaker < textfilename.txt -c -f -p

Which will create a SFF as compact as possible which will eat less memory (sometimes, really much less), ready to be released.

Option 2: Use any of the graphic editors available. I'd highlight two: sés' famous MCM (Mugen Character Maker), and Ragnarok's MEE (Mugen Editing Ensemble). In fact these applications's goal is being complete Mugen development environments and have more functions besides building a SFF, as previewing animations or designing palettes. Their greatest advantage is their friendly interface, much more versatile and intuitive that sprmaker (which to begin with doesn't have an interface at all): simply add the sprites one after another with the appropiate option, assign their four associated values, and voilá, you have your SFF. They are really friendly and easy to use options, specially when we're working on our first character and don't understand very well what's all this mess about sprites, groups and so on. Just by taking a look at the program's instructions we'll quickly catch on.

Building the SFF with Mugen Character Maker (Dev 2): This is the main window, with the SFF tab selected, where all the functions about sprite managment are. There are more functions (tabs), but we'll now concentrate on those regarding to SFF building.

In the SFF menu reside the options to create a new SFF, load an existing one or save the one we're working on. The remaining functions in this menu (except the two las ones) can also be accessed via the...

1 -Upper left panel: Here we'll find every option needed to manage the sprites composing the SFF: I (Insert sprite) - Adds a sprite to the SFF with group no.0 and image no.0, later we'll need to change this values; II (Change sprite) - Changes the sprite currently shown in the right panel with the one we select; III (Delete sprite) - Deletes the sprite currently shown in the right panel. IV (Clone sprite) - Creates a copy of the sprite shown and its four associated values, placing it just after it; V (Change palette) - Changes the paltte (in .ACT format) applied to the sprites shown in the right panel. VI (Sprite selector) - Used to select a sprite, sprites are sorted by group # and then by image #; VII (Move axis) - When it's checked, by moving the mouse while holding the left button in the right panel we'll move the axis and the image will remain still, if it's unchecked we'll move the image and the axis will move instead. We can change the axis' location in both ways.

2 - Lower left panel: Here reside the option which affect the right panel sprite rendering, the most important ones are: I (Transparency) - Controls if the sprite's background color will be shown or not; II (White background) - Toggles between a black and a white background.; III (Zoom) - Allows up to a 4x level zoom, useful for example for precise axis adjustment.

3 - Right panel: In it we can see the currently selected sprite and its axis (shown as a cross). Above there are its four associated values, which can (and shold) be modified. There are two ways to change the sprite's axis: one, clicking on it with the mouse's left button and moving the mouse while holding the button, and two, entering the numeric values directly (I recommend finding these values using the technique explained in the axis adjustment section).

However, these programs have a drawback and hide a temptation. The drawback is that they work directly on the SFF, so if we or the program have a bad day and corrupt the file, fix the problem is, in the better scenario, more tedious than with sprmaker, and in the worst, impossible at all, which can be easily avoided with regular backups. The temptation is that these programs allow the axis to be changed by simply dragging the sprite with the mouse, which isn't a bad thing on itself, of course; hower, we can feel tempted to manually adjusting every axis, saving us the effort of calculating their exact values, a trend that I can assure will turn against you the long run. Besides, don't think that manually adjusting the axis is that easy, you'd surely end retouching the axis constantly to prevent the character to be shifted when changing animations. Believe me, it's much better to precisely calculate the axis whenever you can, and only adjust manually when you can't, and only the component(s) we couldn't calculate.