Difference between revisions of "TEXTURE1 and TEXTURE2"

From DoomWiki.org

[checked revision][checked revision]
(some explanation so the article doesn't jump directly into programming details)
(add example)
Line 4: Line 4:
  
 
The list of patches is stored in the [[PNAMES]] lump. Patches themselves are graphics in Doom's [[picture format]], traditionally placed between the P_START and P_END marker lumps, though there is no engine requirement for this. The TEXTURE1 and TEXTURE2 lumps then refer to specific patches by their index number in the PNAMES list, and gives them their position in the composite texture.
 
The list of patches is stored in the [[PNAMES]] lump. Patches themselves are graphics in Doom's [[picture format]], traditionally placed between the P_START and P_END marker lumps, though there is no engine requirement for this. The TEXTURE1 and TEXTURE2 lumps then refer to specific patches by their index number in the PNAMES list, and gives them their position in the composite texture.
 +
 +
==Example==
 +
The Doom II texture {{c|CRATELIT}}, which represents four small gray crates on top a larger brown crate, is composed of four patches:
 +
*Patch #99 at position 0, 0
 +
*Patch #99 again at position 32, 0
 +
*Patch #95 at position 0, 64
 +
*Patch #96 at position 32, 64
 +
From PNAMES, the game (or a texture editor) retrieves that patch #95 is the graphic BCRATEL1, #96 is BCRATER1, and #99 is SGCRATE2.
  
 
==Binary data==
 
==Binary data==

Revision as of 10:54, 10 August 2021

The TEXTURE1 and TEXTURE2 lumps define how wall patches from the WAD file should combine to form wall textures. They do not contain the graphics themselves, merely their definition.

In other words, a texture is decomposed into smaller textures in such a way that repeating areas are only stored once. At startup time (to be precise, during "R_Init: Init DOOM refresh daemon"), the patches inside the WAD are read and combined into Wall Textures, or how the source code refers to, "map textures".

The list of patches is stored in the PNAMES lump. Patches themselves are graphics in Doom's picture format, traditionally placed between the P_START and P_END marker lumps, though there is no engine requirement for this. The TEXTURE1 and TEXTURE2 lumps then refer to specific patches by their index number in the PNAMES list, and gives them their position in the composite texture.

Example

The Doom II texture CRATELIT, which represents four small gray crates on top a larger brown crate, is composed of four patches:

  • Patch #99 at position 0, 0
  • Patch #99 again at position 32, 0
  • Patch #95 at position 0, 64
  • Patch #96 at position 32, 64

From PNAMES, the game (or a texture editor) retrieves that patch #95 is the graphic BCRATEL1, #96 is BCRATER1, and #99 is SGCRATE2.

Binary data

The binary contents of the TEXTURE1 and TEXTURE2 lumps start with a header of flexible size, followed by all of the map textures.

TEXTURE1 or TEXTURE2
Offset Length Name Content
0x00 4 numtextures An integer holding a the number of map textures.
0x04 4 * numtextures offset[ ] An array of integers containing the offsets to the map textures in this lump.
offset[0]
offset[1]
...
Flexible mtexture[ ] An array with the map texture structures. (see next table)

All integers are 4 bytes long in x86-style little-endian order. Their values can never exceed 231-1, since Doom reads them as signed ints. Short integers are 2 bytes long and are otherwise equal to integers.

Map textures structure, binary data

The binary contents of the maptexture_t structure starts with a header of 22 bytes, followed by all the map patches.

maptexture_t
Offset Length Name Content
0x00 8 name An ASCII string defining the name of the map texture. Only the characters A-Z (uppercase), 0-9, and [ ] - _ should be used in lump names[citation needed]. When a string is less than 8 bytes long, it should be null-padded to the eighth byte.
0x08 4 masked A boolean (0=false, 1=true) defining ?
0x0C 2 width A short integer defining the total width of the map texture.
0x0E 2 height A short integer defining the total height of the map texture.
0x10 4 columndirectory Obsolete, ignored by all DOOM versions.
0x14 2 patchcount The number of map patches that make up this map texture.
0x16 10 * patchcount patches[ ] Array with the map patch structures for this texture. (see next table)

Map patches structure, binary data

The binary contents of the mappatch_t structure contains 10 bytes defining how the patch should be drawn inside the texture.

mappatch_t
Offset Length Name Content
0x00 2 originx A short int defining the horizontal offset of the patch relative to the upper-left of the texture.
0x02 2 originy A short int defining the vertical offset of the patch relative to the upper-left of the texture.
0x04 2 patch A short int defining the patch number (as listed in PNAMES) to draw.
0x06 2 stepdir A short int possibly intended to define if the patch was to be drawn normally or mirrored. Unused.
0x08 2 colormap A short int possibly intended to define a special colormap to draw the patch with, like a brightmap. Unused.

Other formats

Under construction icon-yellow.svgThis article or section is a stub. Please help the Doom Wiki by adding to it.

The TEXTUREx format above is used in all versions of Doom since the 0.5 alpha, Heretic, and Hexen, as well as the "teaser" and 1.0 versions of Strife.

The earlier alpha versions of Doom and v1.1 of the Strife IWAD have different formats.

Doom 0.2

This version has no TEXTUREx lump at all; and instead displays patches directly on the walls.

Doom 0.4

This version has a single TEXTURES lump with a "nameless" format.

maptexture04_t
Offset Length Name Content
0x00 4 masked A boolean (0=false, 1=true) defining ?
0x04 2 width A short integer defining the total width of the map texture.
0x06 2 height A short integer defining the total height of the map texture.
0x08 4 columndirectory Obsolete, ignored by all DOOM versions.
0x0C 2 patchcount The number of map patches that make up this map texture.
0x0E 10 * patchcount patches[ ] Array with the map patch structures for this texture.

Strife 1.1 and above

These have a shortened format with unused bits removed.

maptexturestrife11_t
Offset Length Name Content
0x00 8 name An ASCII string defining the name of the map texture. Only the characters A-Z (uppercase), 0-9, and [ ] - _ should be used in lump names. When a string is less than 8 bytes long, it should be null-padded to the eighth byte.
0x08 4 masked A boolean (0=false, 1=true) defining ?
0x0C 2 width A short integer defining the total width of the map texture.
0x0E 2 height A short integer defining the total height of the map texture.
0x10 2 patchcount The number of map patches that make up this map texture
0x12 6 * patchcount patches[ ] Array with the shortened map patch structures for this texture. (see next table)
mappatchstrife11_t
Offset Length Name Content
0x00 2 originx A short int defining the horizontal offset of the patch relative to the upper-left of the texture.
0x02 2 originy A short int defining the vertical offset of the patch relative to the upper-left of the texture.
0x04 2 patch A short int defining the patch number (as listed in PNAMES) to draw.

Text formats

DeuTex uses a combined PNAMES + TEXTUREx format to output extracted textures or recreate a texture lump. The format is simple:

;Comment
TextureName		Width	Height
*	PatchName	Xoffset	Yoffset

If a line starts with a name, it is a new texture. If it starts with an asterisk, it is a patch to add to the last texture. If it starts with a semi-colon, it is ignored as a comment. Patch names are used directly and the PNAMES table is then rebuilt by numbering them in order of appearance. The numbers that follow a texture names are understood as its dimensions, while the numbers that follow a patch name are understood as its offsets.

Doom source ports such as Doomsday and ZDoom have introduced new text based formats for textures which allows many additional effects to be performed, such as patch rotation or mirroring, as well as altering colors with a translation or a blending.

See also