Format & tools

We've talked a lot about coding and coding concepts so far, but one thing you may be wondering is about how the hell you do the very first step of creating from nothing : the sprites. You just downloaded a spritepack off the Internet, and I've been telling you a lot about the code, but how do I make the images be displayed on the screen to begin with ?
The sprites need to be in PCX format, in 8 bits, meaning it has a 256 color palette. The palette is the first thing to look at on sprites - a good number of image editing softwares have a palette viewer or editor. The palette is a table of colors (256 colors for the format we use in Mugen), and on all sprites, every single pixel refers to that table. If you want to change the colors, do not change the sprite, but the palette : a given pixel remains linked to the color slot in the palette, no matter what color is in that color slot, so changing the color in that slot will change the color of all the pixels associated to that slot. If you want to change the sprite, you need to pick a color in the existing palette. Do not add extra colors, unless you add them to the palette. More generally, if you want to create a new palette for new colors, you simply have to switch the colors in the palette and keep an eye on the sprite until it looks good. For the records, a number of 2D fighting games use about 15 colors for the character and a variable number of additional colors for effects (projectiles...)


A palette. Here, the palette contains just the colors of the character, without effects.
See the pink ? It's used for the background - often hot pink because you can't mix it up with a color on the character. For transparency, Mugen has a dedicated color slot (last color slot on bottom right corner if you are editing the palette with PhotoShop's .act format, or first slot on top left corner if you are editing with Paint Shop Pro's .pal format) that it will always consider to be transparent, no matter what color is in it.

Second, axis. When inserting sprites into the SFF file, you need to give them an axis. It's commonly set somewhere in the middle horizontally, and on the horizontal line where the ground should be. Of course, many 2D fighting games have a bit of depth on the position, so you'll end up with one foot below the ground line and the other above, and Mugen's shadow is a reflection, so it might be a little odd visually. Well, whatever, there's nothing much you can do about it. So anyway, you get an X and Y coordinate for the axis. If possible, try to get a sprite pack (or rip them yourself if you know how to, it'd be even better) where the axis is the same on all sprites - the character moves, but the coordinates of the axis should remain the same. That'll make things simpler and save you a lot of time.


The blue cross is the axis of the sprite. This is a screen capture from a random SFF/AIR viewing tool, the axis normally does not appear on the sprite, don't worry.

Once you have all the sprites, they will have to be organized by group and image number. Don't do it on the sprites themselves, but just get things in order to make it as easy as possible when you will be inserting the sprites. Basically, the sprites are organized by group number and image number, where the group can correspond to an animation, and the image number is the position of the give sprite in that animation (starting from 0). For a quick and simple example, sprite "0,0" is the first sprite of group 0, which you will most likely want to be used for animation 0 (the stance). Sprite "1000,1", could be the second sprite of your first special move (for example, a fireball). There's a list of required sprite numbers and a list of required animations which you will find in the docs ; you will quickly see the corelation between the sprite numbers and animation numbers, and you will also notice the numbering habits. Group 100 (and animation 100) is often used for run or dash animation, group 200 for a light punch, group 1000 and 1100 for the first two special moves, and so on. Of course, beside the required sprites and animations, you can use any number you want, it's just that most people have similar habits, and that usually makes it simpler for anyone to recognize any file with a glance.

The "hard" and original way to create an SFF file is with a text file through SprMaker.
SprMaker is a DOS command line program. This means you cannot double-click on it, you need to open a DOS command invite before starting it. Then, when you start the program, you will need to give it the right options.
In fact, it's much simpler to create a text file with all the information to create the SFF file, and then create a .bat (batch) file, which is nothing more than a text file with the .txt extension replaced by .bat, and in which you will write the command line to start SprMaker and give it the name of the text file with the SFF data. As for the construction of the SFF data file and the exact syntax of the command line to use SprMaker, reading up the docs on that and looking around in a previously existing file will make things as easy as possible. The SFF data start with a few lines for various options (such as how to deal with palettes) are simply a matter of building one block of lines per sprite, where you give the path to the PCX file, whether it uses the palette of the previous sprite (this can go all the way back up to the very first sprite, in which case all your sprites will share the same palette), the group number, the image number, the X axis, and the Y axis. Make one block, copy it over and again, and just change the right information each time. The file length will grow pretty quickly, and it might look overbearing the first time, but since it's always the same format, you get used to it fast enough.

1. sprmaker -c -p < CvS2King.txt > null.txt
   
   Put that in a text file and save it as SprMaker.bat (remove the .txt extension)
2. #
   1
   2 ; those three lines mean that this sprite shares the palette with the previous sprite
   CvS2King\0000000002.pcx ; path to the file
   0 ; group number : group 0
   2 ; image number : third image in group 0
   28 ; X axis, from the left to the right
   110 ; Y axis, from the top downward
   A typical group of lines to insert one sprite in the SFF. Make a whole text file with that block multiplied by as many sprite as you have. Check the documentation first for a few options at the top of the file.
3. Put SprMaker.bat, SprMaker.exe, the above text file, in the same folder
4. Double-click SprMaker.bat

If all goes well, you get a shiny SFF file (you specify the name and location at the top of the text file).

... That was for the SFF format used by WinMugen, but a new SFFv2 format was introduced for Mugen 1.0. Unfortunately, I myself have never tried to use it, so I don't know the details on it, but it should not be too difficult to get the hang of it soon enough - beside, the SFF (v1) format is, of course, still recognized by Mugen 1.0.
One example of the differences in SFFv2 format is how palettes are included in the SFFv2 file, meaning they have to be added in the SFF date text file I have talked about just now. Later Mugen versions are expected to further improve what you can do with your sprites, mainly the support of full color sprites (no 256 color restriction). But, again, I expect the format for sprites that don't need to be full color can remain the same, and the compatibility with the format I have just described should remain.

That said, a few people with programming skills are in the middle of developping tools to view SFF/SFFv2 files. You may want to have a look at that when they get released.

SFFExtract is a program that takes an SFF file and extract all the data from it : all the PCX files, and also the text file with the SFF data - the one I have just described for SprMaker. It should be very easy to extract everything from an existing SFF file (file path, group & image numbers, axis...), make some tweaks, and directly feed the text file to SprMaker. Just as with coding in general, it is very easy to change stuff in the text file and run it in SprMaker to see what it does, and keep changing and testing again to get the hang of it.


Put this text in a text file, save it as SFFExtract.bat, removing the .txt extension. Put that .bat file at the same location as SFFExtract.exe and the SFF file you want to extract. Double-click the .bat file, and you get all the PCX sprites as well as a text file of the proper format, as described in the SprMaker part above.

SprMaker and SFFExtract are just a little weird to get used to if it's your very first time dealing with something like that, but since it's a lot of copy-paste and changing a couple of values, it's also pretty easy to get used to it and never worry about not doing things properly. Other than that, I dare not contest that it's much simpler to get a viewer that lets you browse through the sprites in an SFF file without any of this extraction and creation voodoo. As long as you get a proper tool for that (a few have been made, including the popular Fighter Factory, and a few more are being made for the recent format for Mugen 1.0).
Just for the records, it is my personal belief that using automated tools (like the popular Fighter Factory series) always carry a risk of messing up your file without your knowledge and you may waste a lot of time figuring out what went wrong, not to mention that it's always so much cleaner to actually know how the hell things work, so you can fix anything that comes your way just by looking at it. It is nothing more than a matter of habit. Nevertheless, I am well aware that people usually like it much better when they have an interface where they just have to click on one button, as long as said program works the way it should. But nevermind me.

First, there are the tools made by Elecbyte that come with Mugen.

• PCXClean : a DOS command line tool. Take a screenshot you want to clean, make it a PCX file, take the .act file you want to use, use that tool, and you get a cleaned PCX file. What it does is take all the pixels in the screenshot, and if they are not of a color that is in the palette, they are replaced by the color which is in the slot that Mugen will read as transparent. This implies that the character in the screenshot needs to have the exact colors in the palette you use, and this also mean that you need to have your .act file already complete. This tool is less used as emulators and other tools allow people to rip directly all the sprites they need without the background or any parasite objects on the screenshot, and as sprite packs are released. It also fell out of use as it doesn't work with Windows versions like Vista and 7.


• Mugen tools : a pack of simple tools, include AirEdit (completely fallen out of use as other viewers came up), SprMaker, SndMaker, FntMaker (this one actually has a graphic interface, and is a very simple and useful font maker/viewer).

Over the years, there have been a number of tools made by various people online to help you create characters, with various success. Because they are not made directly by Elecbyte but by people like you and me who just try to emulate what Mugen wants, not all of them work properly. Some of them do work better than others, though.

• MCM (Mugen Character Maker) : a very popular tool made by Sés, relatively early on (in the DOS era). It has a viewer and editor for the SFF and AIR files, as well as an SND editor. It does contain minor flaws (some information in the SFF not visible to the user are improperly created) and the viewer might not be perfectly fit for the more recent versions of Mugen (because of things like palette management), but it is the most straightforward user-friendly tool to create the SFF, AIR and SND files, as long as you set the palette-related options properly. It is also the most straightforward (publicly released) tool if you only want to look at the content of the SFF file. A few SFF viewers have been (and still are) worked on, and could be looked at, but MCM is a widely renowned tool.


• MEE (Mugen Editing Ensemble) : an editor that could view and edit all files used by Mugen. It did not quite gain as much popularity as MCM, as the interface was slightly less instinctive, and just mostly fell out of use. It could be called a spiritual father to the much more recent Fighter Factory, which has a lot of common traits, with a nicer packaging and a more user-friendly approach.


• Paletero : one of the rare palette editing tools. Palette editing should be quite simple, but require you to have something like Paint Shop Pro or PhotoShop, which are not free softwares. Very few programs have been made that simply focused on palettes and did it properly, despite the apparent simplicity. Fighter Factory includes a palette editor - I had a number of problems with it in the early versions and have not looked at more recent versions, but I hear it has improved.
  Just for the side-note, one thing I like to do with palettes is create a .pal file (Paint Shop Pro's format) and open it with a text editor ; there, I just switch the values around and change them as I want for new colors. Finally, I use Pal2Act, one of Elecbyte's original tools, to get the corresponding .act file.


• Fighter Factory : at this point, I have named that tool very often in this overview. This tool, relatively recent in the history of Mugen, is aimed at allowing you to edit everything in a Mugen character (a stage editor by the same authors was on its way last time I looked it up). It just loads all the files and supposedly does everything for you as long as it can be automated. I personally have an extremely low trust level toward an automated tool that does not actually show you what it does, knowing that it does not actually do things exactly as they should be. In general, it forces certain automated treatments on the files and it does not give you the correct habits in several domains : the automatic SCTRL generation and the default values are loose, the automatic Clsn box maker can make useless boxes... Unless you already know the details on how to set up your character properly, the tool could do more damage than not (the last version I tried had a risk, even if rare, of giving you a corrupted SFF file and you had to start over from scratch).
  Regardless of my personal opinion of it, this tool remains extremely popular and very used ; it is also still active, making it easier for complete newcomers to get at least a viewer for all files and start coding from there. Because it is still being worked on by the authors, it also has room for improvement.


• Automatic Stage Creation Tool : just as the name says. The greatest upside to this tool (beside the fact that it is for stages, which have much less room for sensitivity than characters) is that the author, Cybaster, made it along with an extremely detailed tutorial on stages as well as palette making. The tool itself only does the simplest things, setting the very base of the stage with just an image and a coordinate for the ground, letting you chose between different methods to create the SFF file. This goes hand in hand with the tutorial, with which you can do everything else.