Doom Wiki
Registrarse
Doom Wiki
Sin resumen de edición
(No se muestran 46 ediciones intermedias de 2 usuarios)
Línea 1: Línea 1:
  +
[[Archivo:wad.png|thumb|200px]]
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 Doom para el almacenamiento de datos. Un archivo WAD consta de una cabecera, un directorio, y los datos de [[Lump|lumps]] que componen los recursos almacenados en el archivo.
 
   
 
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|motor de Doom]] para el almacenamiento de datos; contiene los [[Sprite|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 [[Lump|lumps]] que componen los recursos almacenados en el archivo.
Un archivo WAD puede ser de dos tipos:
 
   
 
Los archivos WAD pueden 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 [[Que son los Sourceport|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.
+
* '''[[IWAD]]''': Un "WAD Interno" (o "WAD Inicial"), o un WAD esencial que es cargado automáticamente (o desde un menú de selección de juego en los [[Source port|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. Es un progenitor de los [[Mods|mods]] actualmente tan populares.
Un archivo WAD se puede leer y / o editar por muchas herramientas, tales como los ''editores WAD''.
 
  +
  +
 
Un archivo WAD se puede leer y / o editar por muchas herramientas, tales como los [[Utilidad de edición|editores WAD]].
  +
  +
==Antecedentes históricos==
  +
  +
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 [https://es.wikipedia.org/wiki/Copyleft copyleft] y el ideal [https://es.wikipedia.org/wiki/Hacker 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)==
 
==Cabecera (header)==
  +
Un archivo WAD siempre comienza con una cabecera de 12 bytes. Contiene tres valores:
+
Un archivo WAD siempre comienza con una cabecera de 12 bytes, que contiene tres valores:
{| {{Tabla}}
 
  +
! colspan="4"|<tt>wadinfo_t</tt>
 
  +
{| border="0" cellpadding="0" cellspacing="0" class="article-table" align="left" style="float: none; width: auto; margin: 1em 1em 1em 0; font-size: 85%; margin-left:20px; box-shadow: 5px 5px 2px #888888; "
 
! colspan="4" | '''<tt>wadinfo_t</tt>'''
 
|-
 
|-
!Posición
+
! style="text-align: center;" | Posición
  +
! style="text-align: center;" | Largo
!Largo
 
  +
! style="text-align: center;" | Nombre
!Nombre
 
!Descripción
+
! style="text-align: center;" | Descripción
 
|-
 
|-
  +
| style="text-align: center;" | 0x00
|0x00
 
  +
| style="text-align: center;" | 4
|4
 
  +
| identification
|identificación
 
 
|Los caracteres ASCII "IWAD" o "PWAD". Define si el WAD es un IWAD o un PWAD.
 
|Los caracteres ASCII "IWAD" o "PWAD". Define si el WAD es un IWAD o un PWAD.
 
|-
 
|-
  +
| style="text-align: center;" | 0x04
|0x04
 
  +
| style="text-align: center;" | 4
|4
 
|numlumps
+
| numlumps
|Un entero que especifica el número de lumps en el WAD.
+
|Un número entero que especifica el número de lumps en el WAD.
 
|-
 
|-
  +
| style="text-align: center;" | 0x08
|0x08
 
  +
| style="text-align: center;" | 4
|4
 
|infotableofs
+
| infotableofs
|Un entero que posee un puntero a la ubicación del directorio.
+
|Un número 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 <sup>31</sup> -1, donde Doom los lee como enteros con signo.
+
Todos los enteros son de 4 bytes de longitud en estilo x86 [https://es.wikipedia.org/wiki/Endianness little-endian] orden. Sus valores no pueden exceder el valor de 2 <sup>31</sup> -1, donde Doom los lee como enteros con signo. Para algunas portaciones basadas en el código de [https://en.wikipedia.org/wiki/Atari_Jaguar Atari Jaguar] (los derivados de [[Sony PlayStation Doom|PlayStation]] son la excepción notable), en su lugar se utiliza el orden big-endian.
  +
  +
La firma IWAD o PWAD tiene la intención de definir si el archivo es un IWAD o un PWAD, sin embargo, esto no está realmente comprobado por el motor. Es posible cargar un IWAD como PWAD, y también es posible cargar inversamente un PWAD como un IWAD. Por ejemplo, [[CHEX.WAD]] y [[TNT.WAD]] tienen una firma PWAD a pesar de actuar como IWAD.
   
 
==Directorio==
 
==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:
+
El directorio asocia nombres de lumps con los datos que les pertenecen. Se compone de un número de entrada, cada uno 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:
{| {{Tabla}}
 
  +
{| border="0" cellpadding="0" cellspacing="0" class="article-table" align="left" style="float: none; width: auto; margin: 1em 1em 1em 0; font-size: 85%; margin-left:20px; box-shadow: 5px 5px 2px #888888; "
! colspan="4"|<tt>filelump_t</tt>
+
! colspan="4" | '''<tt>filelump_t</tt>'''
 
|-
 
|-
  +
! style="text-align: center;" | Offset
!Desplazamiento
 
  +
! style="text-align: center;" | Largo
!Nombre
 
  +
! style="text-align: center;" | Nombre
!Contenido
 
  +
! style="text-align: center;" | Contenido
 
|-
 
|-
  +
| style="text-align: center;" | 0x00
|0x00
 
  +
| style="text-align: center;" | 4
|4
 
|filepos
+
| filepos
|Un entero que contiene un puntero al comienzo de los datos del lump en el archivo.
+
|Un número entero que contiene un puntero al comienzo de los datos del lump en el archivo.
 
|-
 
|-
  +
| style="text-align: center;" | 0x04
|0x04
 
  +
| style="text-align: center;" | 4
|4
 
|size
+
| size
 
|Un entero que representa el tamaño del lump en bytes.
 
|Un entero que representa el tamaño del lump en bytes.
 
|-
 
|-
  +
| style="text-align: center;" | 0x08
|0x08
 
  +
| style="text-align: center;" | 8
|8
 
|name
+
| 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
+
|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 [[Sprite|sprites]] del [[Archi-vil]], que utilizan "\"). Cuando una cadena tiene menos de 8 bytes de longitud, debe ser rellenada con ''null'' hasta el octavo byte. Los valores superiores a 8 bytes están prohibidos.
 
|}
 
|}
   
Línea 67: Línea 84:
   
 
Un típico archivo WAD:
 
Un típico archivo WAD:
  +
{| border="0" cellpadding="0" cellspacing="0" class="article-table" align="left" style="float: none; width: auto; margin: 1em 1em 1em 0; font-size: 85%; margin-left:20px; box-shadow: 5px 5px 2px #888888; "
{| {{Tabla}}
 
 
| colspan="1" | <tt>wadfile_t</tt>
 
| colspan="1" | <tt>wadfile_t</tt>
 
|-
 
|-
|Cabecera
+
| Cabecera
 
|-
 
|-
|Datos del Lump
+
| Datos del Lump
 
|-
 
|-
|Nombres y punteros de Lumps
+
| Nombres y punteros de Lumps
 
|}
 
|}
   
 
==Orden de los Lump==
 
==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.
 
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===
 
===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 ([[The Ultimate Doom|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.
+
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 ([[The Ultimate Doom|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 <tt>DOOM64.WAD</tt> para [[Doom64 EX]], convertido desde el contenido de una ROM Nintendo 64, contiene IWADs incrustados en lumps MAPxx . En [[Hexen]], contienen información de control de versión; esto no es usado por el juego pero presumiblemente fue usado por las herramientas de edición de [[Raven Software]].
Para funcionar correctamente, los siguientes lumps deben seguir inmediatamente después del el nombre del nivel:
 
*THINGS: A lump listing all the Things present in this map: their X and Y coordinates, starting angles, type and flags. In the Hexen map format, this lump also contains information on Z-height and a thing's TID, special, and arguments. As with all of these lumps, this list will be generated by your level editor and should generally be left alone.
 
*LINEDEFS: A list of linedefs, defined by their starting and ending vertices, flags, type, tag, args, and front and back sidedefs (if any). Note: The standard Doom format does not contain args.
 
*SIDEDEFS: A list of the sidedefs that are linked to the linedefs. These contain the data for what textures appear where on the side of each line, their X and Y offsets, and what sector this side of the linedef belongs to.
 
*VERTEXES: A list of each vertex in the map, using X and Y coordinates.
 
*SEGS: A list of line segments called "segs" that connect to form subsectors. Created by a node builder.
 
*SSECTORS: A list of subsectors, created by a node builder.
 
*NODES: The node tree which Doom uses to speed up the rendering process. Similar to a vismap in modern 3D games (such as Quake 3). Created by a node builder.
 
*SECTORS: Defines the floor and ceiling heights and textures, as well as light value, tag, and type of each sector in your map.
 
*REJECT: Optionally compiled by the node builder, this lump contains data about which sectors are visible from which other sectors. Originally, Doom used this to optimize the game speed by skipping AI routines for enemies whose target was in a rejected sector. Some modern source ports do not require this lump any more; ZDoom for example has been designed to work even without this lump present. For compatibility purposes, an empty (0-filled) REJECT lump should be included if nothing else. The REJECT lump can also be used to create certain special effects (sectors into which enemies cannot see, for example) if modified carefully.
 
*BLOCKMAP: Collision-detection information which determines whether objects in a map are touching.
 
*BEHAVIOR: Not originally a part of Doom, the BEHAVIOR lump was first used in Hexen and contains the compiled scripts that this map will use. Vanilla Doom and other ports designed for Doom only will crash when this lump is present because Hexen format levels are not compatible with Doom format levels. This lump must be present for Hexen format levels since it is the only way to tell if a map is in Hexen or Doom format.
 
   
 
El nombre del nivel marca el inicio de ese mapa. Para funcionar correctamente, los siguientes lumps deben seguir inmediatamente después del nombre del nivel:
===Pisos, Sprites y Parches===
 
  +
*[[Cosas|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.
  +
*[[Linedef|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.
  +
*[[Sidedef|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.
  +
*[[Vértice (VERTEX)|VERTEXES]]: Una lista de cada vértice en el mapa, utilizando coordenadas X e Y.
  +
*[[Segmentos (SEG)|SEGS]]: Una lista de los segmentos de línea que se conectan para formar subsectores, creado por un ''node builder''.
  +
*[[Sector|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.
  +
*[[Subsector|SSECTORS]]: Una lista de subsectores, creado por un ''node builder''.
  +
*[[Nodo|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 [https://es.wikipedia.org/wiki/Inteligencia_artificial IA (Inteligencia_artificial)] de los enemigos cuyo objetivo era no entrar en un sector. Algunas portaciones modernas no requieren más este lump; [[ZDoom]] por ejemplo, ha sido diseñado para funcionar incluso sin este lump presente. Para fines de compatibilidad, un lump REJECT vacío (completado 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]], [[Sprite]]s y [[Parches de pared|Parche]]===
 
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.
 
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 <tt>X_START</tt> y <tt>X_END</tt>, donde <tt>X</tt> 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.
+
Los marcadores consisten en nombres <tt>X_START</tt> y <tt>X_END</tt>, donde <tt>X</tt> es la primera de una o dos letras que identifican el recurso correspondiente. Por ejemplo, los sprites deben estar situados entre los marcadores <tt>S_START</tt> y <tt>S_END</tt>. <tt>SS_START</tt> y <tt>SS_END</tt> se utilizan por lo general para los archivos WAD de usuario.
   
 
Estos marcadores son requeridos por DOOM:
 
Estos marcadores son requeridos por DOOM:
  +
  +
{| border="0" cellpadding="0" cellspacing="0" class="article-table" align="left" style="float: none; width: auto; margin: 1em 1em 1em 0; font-size: 85%; margin-left:20px; box-shadow: 5px 5px 2px #888888; "
  +
! style="text-align: center;" | Marcador inicial
  +
! style="text-align: center;" | Marcador final
  +
! style="text-align: center;" | Qué es
  +
! style="text-align: center;" | Usado por
 
|-
  +
| style="text-align: center;"|<tt>F_START</tt>
  +
| style="text-align: center;"|<tt>F_END</tt>
  +
|Delimitadores de planos
  +
|Todas las versiones
 
|-
  +
| style="text-align: center;"|<tt>S_START</tt>
  +
| style="text-align: center;"|<tt>S_END</tt>
  +
|Delimitadores de sprites
  +
|Todas las versiones
 
|}
  +
  +
Estos marcadores se encuentran en los archivos WAD oficiales, pero no son utilizados por los motores DOOM conocidos:
  +
{| border="0" cellpadding="0" cellspacing="0" class="article-table" align="left" style="float: none; width: auto; margin: 1em 1em 1em 0; font-size: 80%; margin-left:20px; box-shadow: 5px 5px 2px #888888; "
  +
! style="text-align: center;" | Marcador inicial
  +
! style="text-align: center;" | Marcador final
  +
! style="text-align: center;" | Encontrado en
  +
! style="text-align: center;" | Qué es
  +
! style="text-align: center;" | Usado por
 
|-
  +
| <tt>P_START</tt>
  +
| <tt>P_END</tt>
 
|
  +
| Delimitadores de parches
  +
| Todas las versiones
 
|-
  +
| <tt>P1_START</tt>
  +
| <tt>P1_END</tt>
  +
| inside P_ range
  +
| Parches Shareware, [[Heretic]] o Hexen
  +
| Doom shareware y posteriores (pero no Final Doom), Heretic, Hexen
  +
|-
  +
| <tt>P2_START</tt>
  +
| <tt>P2_END</tt>
  +
| inside P_ range
  +
| Parches de la versión registrada, Heretic o Hexen
  +
| Doom registrado y posteriores (pero no Final Doom), Heretic, Hexen
  +
|-
  +
| <tt>P3_START</tt>
  +
| <tt>P3_END</tt>
  +
| inside P_ range
  +
| Parches Doom II
  +
| Doom II, pero no Final Doom
  +
|-
  +
| <tt>F1_START</tt>
  +
| <tt>F1_END</tt>
  +
| inside F_ range
  +
| Pisos Shareware, Heretic o Hexen
  +
| Doom shareware y posteriores (pero no Final Doom), Heretic, Hexen
  +
|-
  +
| <tt>F2_START</tt>
  +
| <tt>F2_END</tt>
  +
| inside F_ range
  +
| Pisos de la versión registrada, Heretic o Hexen.
  +
| Doom registrado y posteriores (pero no Final Doom), Heretic, Hexen
  +
|}
  +
  +
Los parches no están obligados a tener ningún marcador. Algunas utilidades de gestión de lumps requieren <tt>P_START</tt> y <tt>P_END</tt>.
   
 
===Misceláneas===
 
===Misceláneas===
  +
 
Algunos lumps son conocidos por sus nombres y se aplican al juego en su conjunto. Algunos de estos son:
 
Algunos lumps son conocidos por sus nombres y se aplican al juego en su conjunto. Algunos de estos son:
  +
* Los efectos de sonido
 
  +
* Efectos de [[Sonido|sonido]].
* Música
+
* [[Música]].
* PLAYPAL: Paletas de colores para diferentes situaciones:.
+
* [[PLAYPAL]]: Paletas de colores para diferentes situaciones.
* COLORMAP : Mapa para ajustar los valores de píxel de brillo reducido.
+
* [[COLORMAP]] : Mapa para ajustar los valores de píxel de brillo reducido.
* ENDOOM : Texto mostrado cuando [[Vanilla Doom]] exite
+
* [[ENDOOM]] : Pantalla de texto que se muestra cuando [[Vanilla Doom]] termina.
* TEXTURE1, TEXTURE2, PNAMES: Datos que definen las texturas de paredes .
+
* [[TEXTURE1 y TEXTURE2]], [[PNAMES]]: Datos que definen las [[texturas]] de paredes .
* DEMOs: juegos grabados, que se ejecutan automáticamente antes de cada nivel.
+
* [[Demo|DEMO]]: juegos grabados, que se ejecutan automáticamente antes de cada nivel.
  +
  +
==Véase también==
  +
  +
* [[:Categoría:Archivos|Archivos]]
  +
  +
  +
[[en:WAD]]
 
[[Categoría:Recursos]]
 
[[Categoría:Recursos]]
  +
[[Categoría:Archivos| 1]]

Revisión del 21:47 19 abr 2020

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; contiene 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.

Los archivos WAD pueden ser de dos tipos:

  • IWAD: Un "WAD Interno" (o "WAD Inicial"), o un WAD esencial que es cargado 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. Es un progenitor de los mods actualmente tan populares.


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

Antecedentes históricos

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, que contiene tres valores:

wadinfo_t
Posición Largo Nombre Descripción
0x00 4 identification Los caracteres ASCII "IWAD" o "PWAD". Define si el WAD es un IWAD o un PWAD.
0x04 4 numlumps Un número entero que especifica el número de lumps en el WAD.
0x08 4 infotableofs Un número 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 el valor de 2 31 -1, donde Doom los lee como enteros con signo. Para algunas portaciones basadas en el código de Atari Jaguar (los derivados de PlayStation son la excepción notable), en su lugar se utiliza el orden big-endian.

La firma IWAD o PWAD tiene la intención de definir si el archivo es un IWAD o un PWAD, sin embargo, esto no está realmente comprobado por el motor. Es posible cargar un IWAD como PWAD, y también es posible cargar inversamente un PWAD como un IWAD. Por ejemplo, CHEX.WAD y TNT.WAD tienen una firma PWAD a pesar de actuar como IWAD.

Directorio

El directorio asocia nombres de lumps con los datos que les pertenecen. Se compone de un número de entrada, cada uno 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 número 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 del Archi-vil, que utilizan "\"). Cuando una cadena tiene menos de 8 bytes de longitud, debe ser rellenada con null hasta el octavo byte. Los valores superiores a 8 bytes están prohibidos.
  • 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 incrustados en lumps MAPxx . En Hexen, contienen información de control de versión; esto no es usado por el juego pero presumiblemente fue usado por las herramientas de edición de Raven Software.

El nombre del nivel marca el inicio de ese mapa. Para funcionar correctamente, los siguientes lumps deben seguir inmediatamente después del 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 (Inteligencia_artificial) de los enemigos cuyo objetivo era no entrar en un sector. Algunas portaciones modernas no requieren más este lump; ZDoom por ejemplo, ha sido diseñado para funcionar incluso sin este lump presente. Para fines de compatibilidad, un lump REJECT vacío (completado 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 Parche

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 la primera de una o dos 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é es Usado por
F_START F_END Delimitadores de planos Todas las versiones
S_START S_END Delimitadores de sprites Todas las versiones

Estos marcadores se encuentran en los archivos WAD oficiales, pero no son utilizados por los motores DOOM conocidos:

Marcador inicial Marcador final Encontrado en Qué es Usado por
P_START P_END Delimitadores de parches Todas las versiones
P1_START P1_END inside P_ range Parches Shareware, Heretic o Hexen Doom shareware y posteriores (pero no Final Doom), Heretic, Hexen
P2_START P2_END inside P_ range Parches de la versión registrada, Heretic o Hexen Doom registrado y posteriores (pero no Final Doom), Heretic, Hexen
P3_START P3_END inside P_ range Parches Doom II Doom II, pero no Final Doom
F1_START F1_END inside F_ range Pisos Shareware, Heretic o Hexen Doom shareware y posteriores (pero no Final Doom), Heretic, Hexen
F2_START F2_END inside F_ range Pisos de la versión registrada, Heretic o Hexen. Doom registrado y posteriores (pero no Final Doom), Heretic, Hexen

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:

Véase también