Sidedef

From DoomWiki.org

A sidedef contains the wall texture data for each linedef (though sidedefs do not reference linedefs directly, indeed it is the other way around). Each sidedef contains texture data, offsets for the textures and the number of the sector it references (this is how sectors get their 'shape').

Upper texture - This contains the name of a texture that will be displayed on the border between a sector and its neighboring ceiling of a different height. If the linedef that contains this sidedef is one sided this field is meaningless.

Middle texture - On one sided linedefs this will be the only texture displayed; as the main wall texture. On two sided linedefs this will be displayed as a 'floating' texture which the player is able to walk through. Middle floating textures can be used to achieve a variety of faux 3D effects such as 3D bridges. Note that middle floating textures will only tile horizontally and not vertically, where they only repeat once.

Lower texture - This performs a similar function to the upper texture; the lower texture is displayed on the border between a sector and its neighboring floor of a different height.

x offset - How many pixels to shift all the sidedef textures on the X axis (right or left).

y offset - How many pixels to shift all the sidedef textures on the Y axis (up or down).

Regardless of the texture used on a sidedef, each sidedef will still take up the same amount of space since textures are referred to by name.

Sidedef structure[edit]

Doom level format

Each Sidedef is 30 bytes large. Sidedefs are stored in WAD files in the following format:

Offset Size (bytes) C99 type Description
0 2 int16_t x offset
2 2 int16_t y offset
4 8 int8_t [8] Name of upper texture
12 8 int8_t [8] Name of lower texture
20 8 int8_t [8] Name of middle texture
28 2 int16_t Sector number this sidedef 'faces'

Sidedefs are exactly the same in Hexen format as they are in the original Doom format.

Note that the original source code uses the C types short for 2-byte integers and char for character strings. Many limit-removing source ports and modern editing utilities change the interpretation of the sector number field to unsigned, to allow maps to contain up to 65536 sectors as opposed to the original limitation of 32768.

The names of upper, lower, and middle textures must be zero-terminated if the texture name is shorter than 8 bytes. However, the space after the zero-terminating byte is not guaranteed to contain useful data in the case of texture names shorter than 7 bytes. Many utilities may leave such unused bytes uninitialized and therefore prone to misinterpretation by software supporting Unicode or other extended character sets if not properly ignored.

Doom 64 format[edit]

The Doom 64 sidedef is the same as the Doom format except that the textures are represented by indexes into a hash table of texture names. Therefore each linedef is 12 bytes long. This format is also used by the Sony PlayStation version of Final Doom.

Offset Size (bytes) C99 type Description
0 2 int16_t x offset
2 2 int16_t y offset
4 2 int16_t Index of upper texture
6 2 int16_t Index of lower texture
8 2 int16_t Index of middle texture
10 2 int16_t Sector number this sidedef 'faces'

Sidedef compression[edit]

Linedefs reference two sidedefs: one for the left side, and one for the right side, by their order into the SIDEDEFS lump. Naive map authoring tools will generate a unique sidedef for every linedef side in the game (so one per one-sided linedef, two per two-sided).

WAD compression tools can reduce the number of sidedef entries by making multiple linedefs reference the same sidedef, when the linedefs have the same texture, offsets, and sector.

The index used by the linedef entry is a signed 16-bit integer, which restricts the number of sidedefs that can occur to 32768 (ids 0–32767) per level in the original engine. Many limit-removing source ports increase this limit to 65535 by interpreting the sidedef number as unsigned (ids 0–65534), and reserving the value 65535 (equivalent in two's complement binary representation to -1) to mean "none".

See also[edit]

Sources[edit]