Sophie: yadex-1.5.2-2mdk i586

yadex-1.5.2-2mdk.i586.rpm

<html>
<head>
<title>Yadex wad specs</title>
</head>
<body>

<div align="center">
<img src="logo_small.png" alt="Fancy logo">
<br>Yadex 1.5.2 (2001-06-30)
<h1>Wad specs</h1>
<table><tr><td></td><td width="50%" align="center">
This document describes the characteristics of the wads that
Yadex accepts and generates.
<td></td></table>
</div>
<br>
<br>
<br>

	<h2>Wad data types</h2>

<dl>
<a name="i32"><dt><code>i32</code></a>
<dd>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 <code>i32</code> can be between
-2&nbsp;147&nbsp;483&nbsp;648 and +2&nbsp;147&nbsp;483&nbsp;647.


<a name="i16"><dt><code>i16</code></a>
<dd>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 <code>i16</code> can be between -32&nbsp;768 and
+32&nbsp;767.

</dl>

	<h2>Wad header</h2>

		<h3>Input</h3>

An iwad or pwad must be at least 12 bytes long or it will be
rejected. It must start with the string "<code>IWAD</code>" or
"<code>PWAD</code>" (the matching is case sensitive), otherwise
it will be rejected.

<p>The next 4 bytes contain the number of entries in the
directory as an <a href="#i32"><code>i32</code></a>. 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
<code>INT_MAX</code>.

<p>The next 4 bytes contain the offset in the wad as an <a
href="#i32"><code>i32</code></a>. 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.

		<h3>Output</h3>

All generated iwads and pwads start with either
"<code>IWAD</code>" or "<code>PWAD</code>".

	<h2>Wad directory</h2>

		<h3>Input</h3>

<p>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 <em>not</em> subject to case folding. (Note: in
practice, I think there are areas where comparisons are
case-sensitive. TBF.)

		<h3>Output</h3>

<p>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.

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

	<h2>Levels</h2>

		<h3>Input</h3>

<p>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.

<p>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.

		<h3>Output</h3>

<p>In a wad, a level is formed of 11 lumps, always in the same
order&nbsp;: the label, <code>THINGS</code>,
<code>LINEDEFS</code>, <code>SIDEDEFS</code>,
<code>VERTEXES</code>, <code>SEGS</code>, <code>SSECTORS</code>,
<code>NODES</code>, <code>SECTORS</code>, <code>REJECT</code>
and <code>BLOCKMAP</code>.

<p>The label can have any name at the user's discretion (all
letters are uppercased, though), but in practice it is generally
either "<code>E<var>n</var>M<var>m</var></code>" or
"<code>MAP<var>nm</var></code>". The offset of the label is
always set to the offset of the first lump of the level (that
is, <code>THINGS</code>). Its length is always 0.

<p>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 <code>SEGS</code>, <code>SSECTORS</code> and
<code>NODES</code> are present, with an offset of 0 and a length
of 0.

<p><hr>AYM 1999-08-13
</body>
</html>