Sprites

Sprites are the images used by Animations, Backgrounds and Graphic elements. They contain both the Bitmap (pixels) and additional information like axis for alignment.

M.U.G.E.N has its own file format to store multiple sprites in a single file, the SFF (no further details on the file format specification as this information isn't interesting to users, just for Tool makers). To create such file you must use Elecbyte's sprmaker tool or Fighter Factory (it's a binary file, no way to manually edit by yourself). MUGENext supports PCX (8/24/32bits) and PNG (8/16/24/32bits) images, plus all SFF V2 custom encodings (RLE5, RLE8 and LZ5).

A Sprite has an Identifier, a Bitmap, an Axis and an optional Palette (for 8bit images). This is all information Elecbyte M.U.G.E.N supports, but MUGENext adds a little more: NPOT and Rect.

• Identifier: numeric pair of Group and Number (positive integer values).
• Bitmap: Image with 5, 8, 16, 24 or 32 bit depth (indexed images (5/8 bit) are drawn with Nearest-Neighbor filtering, and the others uses Bilinear filtering).
• Axis: X and Y coordinates for alignment (it's the offset from the top-left corner of the Bitmap where the axis should be).
• Palette: A color palette with up to 256 RGBA entries to be used by 8bit color-indexed Bitmaps. Palettes also has an Identifer.
• NPOT: This defines how the texture will be scaled to POT (power of two) dimensions if required (if the hardware supports NPOT and [Video] ForcePOT is 0 in mugen.cfg it has no effect).
• Rect: This parameter allows you to specify a sub region of the Bitmap to be used.

SFF Version 1

Uses PCX images (8bit only, but technically, nothing prevents from using other bit depths, just M.U.G.E.N doesn't like it) as both Bitmap and Palette for the Sprite.

This format has a Flag that forces the use of the Palette from the previous Sprite (in this case the PCX Palette, that's the last 768 bytes of the file, becomes unused, and can be stripped out as Fighter Factory does to save space).

The first Sprite's Bitmap must have its own Palette. All next Sprites can use the previous one by activating the above mentioned Flag, or its own. For characters, the engine always apply an external Palette to the Sprites 9000,0 and 0,0, so this can be exploited to propagate this Palette to other Sprites as desired, meaning Version 1 requires strict ordering for correct Palette propagation.

All 12 possible character Palettes in this format are external ACT files.

Each sprite can have a name or description, with up to 12 ASCII characters.

SFF Version 2

Uses custom encodings (RLE5, RLE8 and LZ5) for Bitmaps, supporting only 5 and 8 bit depth images. This version was introduced in M.U.G.E.N 1.0, and supports embedding Palettes into it. Bitmap images have no built-in Palette anymore, as they are separate entities now.

The Palette propagation is handled by the user creating the file, and the 12 character Palettes are named as Group 1 (these are the ACT ones in Version 1, from 1,1 to 1,12). The others can be any Group besides 1 (reserved).

Version 2 has a Flag to tell the engine to delay the decompression of image data to the time it'll be rendered, reducing memory consumption, but this may lead to other issues like IO starvation and is not recommended.

The ability to give Sprites a name was removed.

SFF Version 2.0.1

The latest format designed by Elecbyte, introduced in M.U.G.E.N 1.1. It adds support for PNG images, from 8 to 32 bit depth and 32 bit color components for Palettes (with Alpha channel for transparency).

In addition to SFF (who feature set varies from one Version to another), MUGENext has its own DEF based format (full feature set). It's easier to work on as Sprites are regular Image files you can edit directly, and with ZIP support you can compress everything anyway, no need for a special binary format, neither compression (uncompressed PNG is recommended alongside ZIP to avoid unnecessary double compression).

The DEF format consist of a list of [Palette] sections, followed by a colletion of [Sprite] sections, as described bellow:

[Palette]

• id: Identifier (comma separated integer values).
• file: Palette filename. Currently, only .act is supported here.

[Sprite]

• id: Identifier (comma separated integer values).
• axis: Alignment axis (comma separated integer values).
• palette: Identifier of the Palette to be used by this Sprite (optional, for 8bit Bitmaps only). [Palette] sections have higher precedence. If there's none with this id, a new Palette will be added from the image pointed by file (this means palettes can be added both from ACT files in [Palette] sections, or dynamically created from the Sprite's Bitmap own Palette).
• file: Image filename (PCX of PNG). The color palette can be stripped out in both formats if not used.
• rect: Source region of 'file' to be used by this Sprite. Format: Left, Top, Width, Height (comma separated integer values).
• NPOT: Non Power of Two mode. Valid values are Stretch, Extend or ommited for default scaling.

NPOT modes:

• Stretch: a fast (and low quality) nearest neighbor scaling is used to fill the entire dimension, stretching the original image. At render time, the texture will be scaled down to the original size. This may reduce quality, but is the only way for tiled Width-based parallax work (uses texture repeat mode, so no outer border is allowed) and prevents weird borders with bilinear filtering on 16/24/32bit images.
• Extend: an outer border extends the image, without stretching. The new pixels at right and bottom are filled with 0, or a custom value for all channels (grayscale only) using the syntax: Extend {0-255}.
• Default if ommited: Stretch for 16/24/32bit images and Extend for 8bit.

The only case that needs this setup correctly is the tiled parallax one on 8bit images (I've seen this only in DOS/Win M.U.G.E.N title menu BG so far). You may not need to worry about other cases much, but making everything with POT in mind has its benefits.

With SFF, NPOT mode is always the default as MUGENext will not promote changes to that format (could be included as a flag easily), and encourages you to use text formats instead (DEF).

POT images seem a waste of space, as extra pixels are required to fulfill this dimension requirement. An SFF usually has more than 1000 sprites, and if all of them require extra padding, the ammount of unused space may be a big hit in memory usage. But, we can exploit this and place more than one sprite in the same image: a spritesheet. By using the Rect option, you can use a single image for multiple sprites, and easily make its dimensions a power of two if needed, wasting less space.

Using a spritesheet has more benefits like:

• Easy to edit multiple sprites at once;
• Fonts can be built using just one image, like in .fnt files;
• More efficient use of GPU resources, leading to less memory usage and more performance.