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.
sprmaker -c -p < CvS2King.txt > null.txt
Put that in a text file and save it as SprMaker.bat (remove the .txt extension)
#
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.
- Put SprMaker.bat, SprMaker.exe, the above text file, in the same folder
- 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.
sffextract -n -o CvS2King.txt -i -d CvS2King.sff
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.
|
|