Sprite

This article or section is outdated and has not been fully updated to reflect the current version of SRB2.

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

To do

rollangle

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.

Format

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.

4 Diagonal-back view (left)	5 Back view	6 Diagonal-back view (right)
3 Side view (left)	0 Displays for all rotations	7 Side view (right)
2 Diagonal-front view (left)	1 Front view	8 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".

4 Diagonal-back view (left)	C Diagonal-back / Back inbetween (left)	5 Back view	D Diagonal-back / Back inbetween (right)	6 Diagonal-back view (right)
B Side / Diagonal-back inbetween (left)				E Side / Diagonal-back inbetween (right)
3 Side view (left)		0 Displays for all rotations		7 Side view (right)
A Side / Diagonal-front inbetween (left)				F Side / Diagonal-front inbetween (right)
2 Diagonal-front view (left)	9 Front / Diagonal-front inbetween (left)	1 Front view	G Front / Diagonal-front inbetween (right)	8 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 WALKC1G1 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 (G1) will be a flipped version of the other (C1).

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, STNDA3 and STNDA7 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 STNDA3A7 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:

STNDA1
STNDA2A8
STNDA3A7
STNDA4A6
STNDA5

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 Lance-a-Bot 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:

Invisibility

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.

Sprite/frame appearance flags

A number of visual effects can be set via 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 important items such as the Chaos Emeralds visible in dark maps, or for fire-based objects so they can act as a pseudo-light source in such maps. Similarly, FF_FULLDARK renders the sprite in full darkness, while FF_SEMIBRIGHT averages full brightness with the light level of the sector the sprite is in.

Other properties allow changing the sprite's orientation, like FF_HORIZONTALFLIP and FF_VERTICALFLIP, which flip the sprite horizontally or vertically. To change how a sprite is drawn in three-dimensional space, FF_PAPERSPRITE or FF_FLOORSPRITE can be used, to draw the sprite along a vertical plane or a horizontal plane.

Another state-given property for sprites is translucency: nine different levels of translucency are available in SRB2, corresponding to the frame flags FF_TRANS10 through FF_TRANS90 – each of these give a different percentage of translucency in multiples of 10% (where 100% is totally invisible).

In addition to normal translucency, there are four available blending modes that can be set for sprites: additive, subtractive, reverse subtractive and modulative blending, available through the frame flags FF_ADD, FF_SUBTRACT, FF_REVERSESUBTRACT and FF_MODULATE. Besides modulative blending, these can be combined with the translucency flags to change the blending strength.

The table below displays an example sprite rendered normally in-game, and with all combinations of blending modes and translucency levels separately applied for comparison:

Translucency level	0%	10%	20%	30%	40%	50%	60%	70%	80%	90%
Translucent
Additive `FF_ADD`
Subtractive `FF_SUBTRACT`
Reverse subtractive `FF_REVERSESUBTRACT`
Modulative `FF_MODULATE`

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.