WAD

Un WAD (que, según la Biblia de Doom es un acróstico de "Where's All the Data?") es el formato de archivo utilizado por Doom y todos los juegos basados ​​en el motor de Doom para el almacenamiento de datos, conteniendo los sprites, niveles, música y los demás datos necesarios para la ejecución del juego. Un archivo WAD consta de una cabecera, un directorio, y los datos de lumps que componen los recursos almacenados en el archivo.

Es un progenitor de los mods actualmente tan populares.

Un archivo WAD puede ser de dos tipos:

• IWAD: Un "WAD Interno" (o "WAD Inicial"), o un WAD esencial que se carga automáticamente (o desde un menú de selección de juego en los source port) por el motor y por lo general proporciona todos los datos necesarios para ejecutar el juego.

• PWAD: un "Parche WAD", o un archivo opcional que reemplaza los datos del IWAD cargado o proporciona datos adicionales para el motor.

Un archivo WAD se puede leer y / o editar por muchas herramientas, tales como los editores WAD.

Historia

Durante el desarrollo de Doom, Id Software era consciente de que muchos jugadores habían tratado de crear niveles personalizados y otras modificaciones para su juego anterior, Wolfenstein 3D. Sin embargo, los procedimientos involucrados en la creación y carga de modificaciones para ese juego eran muy engorrosos.

John Carmack, programador jefe en id Software, diseñó las partes internas de Doom desde cero para permitir a los jugadores extender el juego. Por esa razón, los datos del juego, tales como niveles, gráficos, efectos de sonido y la música se almacenan por separado del motor de juego, en los "archivos WAD". Esto permitió a los jugadores hacer sus propios datos sin realizar ninguna modificación al motor.

La idea de hacer que Doom fuese fácilmente modificable fue respaldada principalmente por Carmack, un partidario bien conocido del copyleft y el ideal Hacker de personas que comparten y se basan en el trabajo de otros, y por John Romero, que había hackeado juegos en su juventud y quería permitir otros jugadores hagan lo mismo. No todo el mundo en el equipo de id Software estaba contento con este desarrollo; algunos, entre ellos Jay Wilbur y Kevin Nube, lo objetaron debido a preocupaciones legales y en la creencia de que no sería de ningún beneficio para los negocios de la compañía.

Cabecera (header)

Un archivo WAD siempre comienza con una cabecera de 12 bytes. Contiene tres valores:

wadinfo_t
Posición	Largo	Nombre	Descripción
0x00	4	identificación	Los caracteres ASCII "IWAD" o "PWAD". Define si el WAD es un IWAD o un PWAD.
0x04	4	numlumps	Un entero que especifica el número de lumps en el WAD.
0x08	4	infotableofs	Un entero que posee un puntero a la ubicación del directorio.

Todos los enteros son de 4 bytes de longitud en estilo x86 little-endian orden. Sus valores no pueden exceder de 2 ³¹ -1, donde Doom los lee como enteros con signo.

Directorio

El directorio asocia nombres de lumps con los datos que les pertenecen. Se compone de un número de entrada, cada una con una longitud de 16 bytes. La longitud del directorio se determina por el número dado en la cabecera del WAD. La estructura de cada entrada es como sigue:

filelump_t
Offset	Largo	Nombre	Contenido
0x00	4	filepos	Un entero que contiene un puntero al comienzo de los datos del lump en el archivo.
0x04	4	size	Un entero que representa el tamaño del lump en bytes.
0x08	8	name	Una cadena ASCII que define el nombre del lump. Sólo los caracteres AZ (mayúsculas), 0-9 y [] - _ se pueden utilizar en los nombres de lump (una excepción son algunos de los sprites de Archi-vil, que utilizan "\"). Cuando una cadena tiene menos de 8 bytes de longitud, debe ser rellenado con null para el byte comprimido

• Las herramientas no asumen el orden del lump en el WAD, y son ordenados por el byte de desplazamiento.
• Lumps "virtuales" (como F_START) sólo existen en el directorio, teniendo un tamaño de 0. Su valor de desplazamiento, por lo tanto, es absurdo (a menudo 0). Es posible que más de un lump tenga el mismo valor de desplazamiento, es como tener compensaciones que se superponen a otros datos del lump.
• El tipo de archivo no se indica en los datos del lump.

Un típico archivo WAD:

wadfile_t

Cabecera

Datos del Lump

Nombres y punteros de Lumps

Orden de los Lump

La mayoría de los lumps no tienen restricciones sobre dónde deben ser ubicados en los archivos WAD, aunque normalmente hay algunas pautas para que el archivo sea de fácil lectura para otras personas. Para ciertos lumps, sin embargo, la ubicación es crucial.

Lumps de datos de mapa

Un mapa en Doom se compone de varios lumps, cada uno conteniendo datos específicos necesarios para construir y ejecutar el mapa. El primer lump da el nombre interno del mapa. En Doom, tenía que estar en el formato ExMy o MAPxx, donde x e y no podían exceder de 4 y 9, respectivamente (Ultimate Doom), y xx no puede ser superior a 32 (Doom II/Final Doom).

Aparte de definir el nombre del mapa, el lump está generalmente vacío, pero puede contener datos. El archivo DOOM64.WAD para Doom64 EX, convertido desde el contenido de una ROM Nintendo 64, contiene IWADs en bultos MAPxx incrustados.

El nombre del nivel marca el inicio de ese mapa. Para funcionar correctamente, los siguientes lumps deben seguir inmediatamente después del el nombre del nivel:

• THINGS: Un lump con la lista de todas las cosas presentes en este mapa con sus coordenadas X e Y, ángulos de origen, tipo y banderas. Al igual que con todos estos lumps, la lista será generada por el editor de niveles y por lo general se debe dejar sola.
• LINEDEFS: Una lista de linedefs, definidos por su vértices de inicio y finalización, banderas, tipo, etiqueta, argumentos, y sidedefs frontales y dorsales (si los hay). Nota: El formato estándar de Doom no contiene argumentos.
• SIDEDEFS: Una lista de los sidedefs que están vinculados a los linedefs. Estos contienen los datos para las texturas que aparecen en cada lado de la línea, sus desplazamientos X e Y, y qué sector del lado de la linedef pertenece.
• VERTEXES: Una lista de cada vértice en el mapa, utilizando coordenadas X e Y.
• SEGS: Una lista de los segmentos de línea que se conectan para formar subsectores, creado por un node builder.
• SECTORS: Define las alturas del piso y del techo y texturas, así como el valor de luz, etiquetas, y el tipo de cada sector en su mapa.
• SSECTORS: Una lista de subsectores, creado por un node builder.
• NODES: El árbol de nodos que Doom utiliza para acelerar el proceso de renderizado. Similar a un VISMAP en juegos 3D modernos (como Quake 3). Creado por un node builder.
• REJECT: Opcionalmente compilado por el node builder, este lump contiene datos sobre qué sectores son visibles desde otros sectores. Originalmente, Doom usó esto para optimizar la velocidad de juego al saltarse las rutinas de IA de los enemigos cuyo objetivo era no entrar en un sector. Algunos modernos source port no requieren más este nudo; ZDoom por ejemplo, ha sido diseñado para funcionar incluso sin este lump presente. Para fines de compatibilidad, un bulto REJECT vacío (completar con 0) debe ser incluido. El lump REJECT también se puede utilizar para crear ciertos efectos especiales (sectores en los que los enemigos no pueden ver, por ejemplo) si se modifica con cuidado.
• BLOCKMAP: información de detección de colisiones que determina si los objetos en un mapa se tocan.
• BEHAVIOR: No era originalmente una parte de Doom, el lump BEHAVIOR fue utilizado por primera vez en Hexen y contiene los scripts compilados que este mapa va a utilizar. Vanilla Doom y otros puertos diseñados solamente para Doom, se estrellan cuando este nudo está presente porque los niveles de formato Hexen no son compatibles con los niveles de formato de Doom. Este nudo debe estar presente para  los niveles de formato Hexen, ya que es la única manera de saber si un mapa está en formato Hexen o Doom.

Planos, Sprites y Parches

Estos tres recursos deben estar situados entre marcadores especiales de lump para que Doom sepa lo que se está mirando. Aparte de definir el principio y el final de una sección de gráficos, estos lumps no contienen datos y son de 0 bytes de longitud.

Los marcadores consisten en nombres X_START y X_END, donde X es 1 o 2 letras que identifican el recurso correspondiente. Por ejemplo, los sprites deben estar situados entre los marcadores S_START y S_END. SS_START y SS_END se utilizan por lo general para los archivos WAD de usuario.

Estos marcadores son requeridos por DOOM:

Marcador inicial	Marcador final	Qué	Usado por
F_START	F_END	Delimitadores de planos	Todas las versiones
S_START	S_END	Delimitadores de sprites	Todas las versiones

Los parches no están obligados a tener ningún marcador. Algunas utilidades de gestión de lumps requieren P_START y P_END.

Misceláneas

Algunos lumps son conocidos por sus nombres y se aplican al juego en su conjunto. Algunos de estos son:

• Los efectos de sonido
• Música
• PLAYPAL: Paletas de colores para diferentes situaciones:.
• COLORMAP : Mapa para ajustar los valores de píxel de brillo reducido.
• ENDOOM : Texto mostrado cuando Vanilla Doom exite
• TEXTURE1 y TEXTURE2, PNAMES: Datos que definen las texturas de paredes .
• DEMOs: juegos grabados, que se ejecutan automáticamente antes de cada nivel.