A sprite is a graphic that is displayed by an Object. Some Objects, such as static scenery items, have only one sprite, which they display at all times. More complex Objects like the player or enemies have a larger set of sprites that the game cycles through to animate the Object. Like other graphics, sprites are stored as lumps in WAD or PK3 files and then referenced by the states of the Objects that use them. In PK3 files, sprites must be placed in the
Sprites/ folder in order to be recognized by SRB2. In WAD files, they must be placed between empty marker lumps called
SS_END can also be used, but the former pair is generally favored. An exception to this are sprites for custom characters; see Custom character tutorial/Overview > Organization for more information.
Because SRB2 has a fixed palette of 256 colors that it can display, sprites are limited to these 256 colors. When converting an image to the graphics format used by SRB2, the color value of each pixel will be converted to an index number that corresponds to an entry in the palette. If the image uses a color that is not in the palette, it will be converted to the nearest available color.
With a few exceptions (invisible Objects and Objects that share their sprites with other Objects), every Object has its own sprite set, which is a collection of sprites that it can display. A sprite set contains up to 62 frames, which together make up the Object's animation. For example, the first frame of the player's sprite set is the standing frame, which is displayed when the player is standing. Frames 4–11 are the player's walking frames, which the player cycles through to create the walking animation. The frame itself consists of eight rotations, which depict the frame from different angles. For example, a Crawla that is facing the player will display its front rotation, whereas a Crawla that is facing away from the player will display its back rotation.
To designate the sprite set, frame and rotation of a sprite, every sprite has a lump name of the format
NAME is a four-letter prefix that designates the sprite set. SRB2 allows for up to 521 different sprite sets, 265 of which are already occupied by the game's native sprites and the other 256 of which are free slots that can be used for custom sprites. For a list of sprite sets and the associated prefixes, see the list of sprites. When adding a new sprite set, a freeslot declaration has to be created for it; see Freeslot > Declaring freeslot names for more information.
X designates the frame that the sprite belong to. See Frame list below for a list of valid frame designations. Finally,
x designates the sprite's rotation. It is a number between 1 and 8, where 1 is the front view, 5 is the back view and 8 is the diagonal front-right view.
If the sprite's rotation number is 0, the sprite will display for all 8 rotations in the frame. This is commonly used for static scenery items. It is also possible to supply only some rotations and use the sprite with rotation 0 as a fallback sprite for the other rotations. To achieve this, the sprite lumps for the specific rotations must be placed after the sprite lump for rotation 0 inside the WAD or PK3 file.
Diagonal-back view (left)
Diagonal-back view (right)
Side view (left)
Displays for all rotations
Side view (right)
Diagonal-front view (left)
Diagonal-front view (right)
Condensed naming system
The name of a lump can contain up to eight characters, but only six are occupied by the sprite's name. SRB2 makes use of this circumstance to implement a condensed (or abridged) naming system for sprites. This allows a single sprite to be used for two different rotations (which can even be of two different frames) at once. This is done by designating two frames and rotations in the sprite, e.g.
NAMEXxYy, which will cause this sprite to be displayed both as
NAMEXx and as
NAMEYy. For example, naming a sprite
PLAYF1J1 would cause it to be displayed as the front view for both the third and the seventh frame of the player's walking animation. Note however that the displayed sprite for the latter of these two frames (
J1) will be a flipped version of the other (
More commonly, the condensed sprite naming system is used to reduce the number of rotations for a frame from eight to five. This makes use of the fact that if the frame is horizontally symmetrical (which is often the case), the rotations 2 and 8, 3 and 7, as well as 4 and 6, will look identical except for being flipped horizontally. For example,
PLAYA7 are part of the player's standing frame, once facing left and once facing right. These sprites will usually be identical except for their orientation, and flipping one of them horizontally will produce the other. Therefore, the game will accept a single sprite called
PLAYA3A7 for the left-facing rotation and automatically flip it to be used for the right-facing rotation as well.
In total, this allows for five sprites per frame instead of eight. For example, the standing frame of the player would consist of the following five sprites:
PLAYA1 PLAYA2A8 PLAYA3A7 PLAYA4A6 PLAYA5
However, if the frame has non-symmetrical features, using the condensed naming system will cause these features to be flipped as well. For example, the CastleBot FaceStabber holds a lance in its left hand. If it used the condensed naming system, the lance would suddenly switch hands when facing the enemy from a different angle. In cases like this, all eight rotations need to be supplied separately.
This is a list of all the standard 62 frames that a sprite set can use in SRB2 and the frame designators for them.
Note that the backslash (
\) character, which is used by frame 27, cannot be used in PK3 files because it is reserved for referring to a lump's path within the PK3 file's folder structure (e.g.,
Sprites\PLAYA1). Because of this, the plus (
+) character is accepted as an alternative frame designator for frame 27.
It is technically possible to use frame numbers 62 and beyond, but these require usage of extended ASCII characters, which may vary depending on the encoding used and so are not consistent for all users. SLADE also does not support non-ASCII characters. For these reasons it is recommended not to use frame characters beyond frame number 61 ('~') whenever possible.
Lowercase lump names
Frames 32–57 use lowercase letters as part of their lump name, e.g.,
PLAYa1. Since lump names were intended to always be uppercase in Doom, most WAD editors will automatically convert lowercase letters in the lump names of a WAD file into uppercase, which will prevent the sprite from functioning correctly. To prevent this, many lump editors (including SLADE and XWE) have a feature that allows lowercase lump names to stay as they are. However, this feature needs to be activated manually. See the SLADE or XWE article for information on how to activate this feature. In PK3 files, lowercase lump names are always accepted without issue.
Sprites can have additional special effects applied to them, depending on the properties of the Objects and states that they belong to:
There are multiple ways to make an Object's sprites turn invisible:
- Objects with the
MF2_DONTDRAWflag will prevent their sprites from being drawn, turning them invisible. This lasts for as long as the flag is enabled.
- Objects with the
MF_NOSECTORflag will be removed from the sector links; this causes an Object's sprites to not be drawn, making the Object invisible. This flag is not intended to turn on and off the visibility of an Object during runtime, however.
Alternatively, the special sprite set
SPR_NULL can be used on specific states where an Object using them is intended to be invisible. Note that sprites for this sprite set (e.g.
NULLA0) do not actually exist, and will not be used even if they were provided in a custom WAD file; states using the sprite set
SPR_NULL will not draw anything at all for Objects that use them, regardless of whether the sprites for it exist or not.
Full brightness and translucency
Both full-brightness and translucency for sprites are determined by the
SpriteFrame attribute for states; see State > Attributes for applying these effects.
Through the properties given to a state, sprites are capable of being rendered in full brightness with use of the
FF_FULLBRIGHT frame flag, which prevents a sprite from being affected by any sector lighting. This can be useful for making visible in dark maps important items such as the Chaos Emeralds, or fire-based objects so they can act as a pseudo-light source in such maps.
The other main state-given property for sprites is translucency: nine different levels of translucency are available in SRB2, corresponding to the frame flags
TR_TRANS90 – each of these give a different percentage of translucency in multiples of 10% (assuming that 100% would be totally invisible, if it were included here). The table below displays an example sprite rendered normally in-game, and with all nine translucency levels separately applied for comparison:
Alternatively, Objects with the
MF2_SHADOW flag will automatically display their sprites in full brightness but with 80% translucency for as long as the flag is enabled for them, overriding any state-given full-brightness/translucency settings.
Skins and skin colors
- See also: List of skin colors
SPR_PLAY is a special sprite set generally reserved for players to use, though the icons for the Level End Sign and Extra Life Monitor also use this set. By default an Object using a sprite from this set will display the sprites for Sonic; however, if the Object changes to a skin other than Sonic himself, the sprite the Object displays will be of the custom sprite set for the skin selected.
Display offsets are used by some types of Objects (e.g.: shield orbs) to resolve ordering conflicts when drawing sprites in certain situations. In particular, when multiple Objects are in the exact same position, the sprites for Objects with a higher display offset will be displayed in front of sprites for those with a lower display offset. The display offset for an Object is determined by the
DispOffset attribute for Object types (this attribute is applied to all Objects of the same type; separate display offsets for individual Objects cannot be determined); see Object > Other attributes for applying this effect.