Yadex $VERSION ($SOURCE_DATE)

Wad specs

This document describes the characteristics of the wads that Yadex accepts and generates.

Wad data types

i32

An array of 4 bytes that is interpreted as a little-endian signed 32-bit integer. The array is always interpreted as little-endian, even if the platform is not. By definition, the value of an i32 can be between -2 147 483 648 and +2 147 483 647.

i16

An array of 2 bytes that is interpreted as a little-endian signed 16-bit integer. The array is always interpreted as little-endian, even if the platform is not. By definition, the value of an i16 can be between -32 768 and +32 767.

Wad header

Input

The next 4 bytes contain the number of entries in the directory as an i32. If this field is 0, the whole wad should be ignored (but I'm not sure it is in practice--TBF). If this field is negative, the wad should be rejected (but it don't think it is in practice--TBF). Otherwise, this field should not be greater than INT_MAX.

The next 4 bytes contain the offset in the wad as an i32. There is no particular constraint or checking on this number, although it would be a good idea to check that the offset is not negative and does not go beyond the end of the wad.

Output

Wad directory

Input

The lump names can contain any combination of 8 characters, including control characters, though non-printable characters will probably make Yadex display garbage, as they are not filtered. A NUL terminates the lump name. All characters following the NUL are ignored for comparison purposes. The lump names are treated in a case-insensitive fashion. That is, any lower case alphabetic character of the US-ASCII set (a-z) is equivalent to the corresponding upper case character (A-Z) for comparison purposes. Alphabetic characters not belonging to the US-ASCII set (E.G. accented characters from ISO-8859 or IBM CP 437) are not subject to case folding. (Note: in practice, I think there are areas where comparisons are case-sensitive. TBF.)

Output

The directory and the header never overlap. Depending on the function that created the wad, the directory is either between the header and the first lump or after the last lump.

Lump names in the output may have their case folded to upper case and the tail of the name may be filled with NULs.

Levels

Input

The offset and length of the label are ignored. I'm pretty sure Doom ignores them because there are pwads out there that have level labels with non-zero lengths and weird offsets.

If the length of a lump is not a multiple of the size of the type of object it contains, a warning is printed and the number of bytes read is equal to the size truncated to the nearest multiple of the object size.

Output

In a wad, a level is formed of 11 lumps, always in the same order : the label, THINGS, LINEDEFS, SIDEDEFS, VERTEXES, SEGS, SSECTORS, NODES, SECTORS, REJECT and BLOCKMAP.

The label can have any name at the user's discretion (all letters are uppercased, though), but in practice it is generally either "EnMm" or "MAPnm". The offset of the label is always set to the offset of the first lump of the level (that is, THINGS). Its length is always 0.

All 10 following directory entries are always present, even if the corresponding lumps do not exist. For example, in the case of a new level that hasn't had its nodes built, the directory entries SEGS, SSECTORS and NODES are present, with an offset of 0 and a length of 0.