From SRB2 Wiki
Jump to: navigation, search
Test.png This article or section is outdated and has not been updated to reflect the release of SRB2 v2.2.

Please help the Wiki by correcting or removing any misinformation, as well as adding any new information to the page.

ToDoIcon.png To do
  • rollangle
  • SPR2_ system, no lump for SPR_PLAY in 2.2 actually uses PLAY prefix anymore, etc etc
This article is about the definition of sprites. For a list of sprites that are used in SRB2, see List of sprites.
Sprite of a blue Crawla (POSSA1)

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 S_START and S_END. Alternatively, SS_START and 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 NAMEXx. NAME is a four-letter prefix that designates the sprite set. SRB2 allows for up to 777 different sprite sets, 265 of which are already occupied by the game's native sprites and the other 512 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)
Back view
Diagonal-back view (right)
Side view (left)
Displays for all rotations
Side view (right)
Diagonal-front view (left)
Front view
Diagonal-front view (right)

From version 2.2.1 onwards, it is possible to provide sprites for 16 angles instead of the regular 8. This is accomplished by using the number 9 and the letters A through G as in-betweens, creating a new cycle of "1, 9, 2, A, 3, B ... 8, G".

Diagonal-back view (left)
Diagonal-back / Back inbetween (left)
Back view
Diagonal-back / Back inbetween (right)
Diagonal-back view (right)
Side / Diagonal-back inbetween (left)
Side / Diagonal-back inbetween (right)
Side view (left)
Displays for all rotations
Side view (right)
Side / Diagonal-front inbetween (left)
Side / Diagonal-front inbetween (right)
Diagonal-front view (left)
Front / Diagonal-front inbetween (left)
Front view
Front / Diagonal-front inbetween (right)
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 (F1).

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, PLAYA3 and 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:


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.

Frame list

This is a list of all 64 frames that a sprite set can use in SRB2 and the frame designators for them.

Value Frame
0 A
1 B
2 C
3 D
4 E
5 F
6 G
7 H
8 I
9 J
10 K
11 L
12 M
13 N
14 O
15 P
Value Frame
16 Q
17 R
18 S
19 T
20 U
21 V
22 W
23 X
24 Y
25 Z
26 0
27 1
28 2
29 3
30 4
31 5
Value Frame
32 6
33 7
34 8
35 9
36 a
37 b
38 c
39 d
40 e
41 f
42 g
43 h
44 i
45 j
46 k
47 l
Value Frame
48 m
49 n
50 o
51 p
52 q
53 r
54 s
55 t
56 u
57 v
58 w
59 x
60 y
61 z
62 !
63 @

Lowercase lump names

Frames 36–61 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.

Extra attributes

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_DONTDRAW flag will prevent their sprites from being drawn, turning them invisible. This lasts for as long as the flag is enabled.
  • Objects with the MF_NOSECTOR flag 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_TRANS10 through 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:

% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90%
Example Trans00ex.png Trans10ex.png Trans20ex.png Trans30ex.png Trans40ex.png Trans50ex.png Trans60ex.png Trans70ex.png Trans80ex.png Trans90ex.png

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

The appearance of an Object's sprite in-game can also be influenced by the current skin and/or skin color applied to the Object itself.

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

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.

Note: This feature is currently exclusive to the Software renderer. In OpenGL, the order that sprites are drawn in will be unaffected by DispOffset.