id Tech 1 , también conocido como motor Doom , es el motor de juego utilizado en los videojuegos de id Software Doom y Doom II: Hell on Earth . También se utiliza en Heretic , Hexen: Beyond Heretic , Strife: Quest for the Sigil , Hacx: Twitch 'n Kill , Freedoom y otros juegos producidos por licenciatarios. Fue creado por John Carmack , con funciones auxiliares escritas por Mike Abrash , John Romero , Dave Taylor y Paul Radek. Desarrollado originalmente en computadoras NeXT , [3] fue portado a MS-DOS y sistemas operativos compatibles para el lanzamiento inicial de Doom y luego fue portado a varias consolas de juegos y sistemas operativos .
El código fuente de la versión Linux de Doom se lanzó al público bajo una licencia que otorgaba derechos para uso no comercial el 23 de diciembre de 1997, seguido de la versión Linux de Doom II aproximadamente una semana después, el 29 de diciembre de 1997 . 4] [5] El código fuente fue relanzado posteriormente bajo la Licencia Pública General GNU v2.0 o posterior el 3 de octubre de 1999. [6] [7] Las docenas de ports fuente no oficiales de Doom que se han creado desde entonces permiten Doom para ejecutarse en sistemas operativos que antes no eran compatibles y, a veces, expandir radicalmente la funcionalidad del motor con nuevas características.
Aunque el motor genera un espacio 3D, ese espacio se proyecta desde un plano de planta bidimensional . La línea de visión es siempre paralela al piso, las paredes deben ser perpendiculares al piso y no es posible crear estructuras de varios niveles o áreas inclinadas (pisos y techos con diferentes ángulos). A pesar de estas limitaciones, el motor representó un salto tecnológico con respecto al anterior motor Wolfenstein 3D de id . Posteriormente, el motor de Doom pasó a llamarse "id Tech 1" para clasificarlo en una lista de la larga línea de motores de juegos de id Software . [8]
El motor de Doom separa el renderizado del resto del juego. El motor gráfico funciona lo más rápido posible, pero el mundo del juego funciona a 35 cuadros por segundo independientemente del hardware, por lo que varios jugadores pueden jugar entre sí usando computadoras de diferente rendimiento. [9]
Una configuración sencilla que demuestra cómo Doom representa los niveles internamente
Vistos de arriba hacia abajo, todos los niveles de Doom son en realidad bidimensionales, lo que demuestra una de las limitaciones clave del motor de Doom : no es posible pasar de una habitación a otra . Esta limitación, sin embargo, tiene un lado positivo: se puede mostrar fácilmente un "modo de mapa", que representa las paredes y la posición del jugador, muy parecido a la primera imagen de la derecha.
La unidad base es el vértice , que representa un único punto 2D. Los vértices (o "vértices", como se los denomina internamente) luego se unen para formar líneas , conocidas como "linedefs". Cada linedef puede tener uno o dos lados, lo que se conoce como "sideefs". Luego, los sidedefs se agrupan para formar polígonos ; estos se denominan "sectores". Los sectores representan áreas particulares del nivel.
Cada sector contiene una serie de propiedades: altura del piso, altura del techo, nivel de luz, textura del piso y textura del techo. Para tener un nivel de luz diferente en un área en particular, por ejemplo, se debe crear un nuevo sector para esa área con un nivel de luz diferente. Por lo tanto, las líneas de un solo lado representan paredes sólidas, mientras que las de dos lados representan líneas de puente entre sectores.
Los Sidedefs se utilizan para almacenar texturas de paredes ; estos están completamente separados de las texturas del piso y el techo. Cada sidedef puede tener tres texturas; éstas se denominan texturas media, superior e inferior. En linedefs de un solo lado, solo se usa la textura intermedia para la textura de la pared. En las definiciones de líneas bilaterales, la situación es más compleja. Las texturas inferior y superior se utilizan para llenar los huecos donde los sectores adyacentes tienen diferentes alturas de piso y techo: las texturas inferiores se utilizan para escalones, por ejemplo. Los sidedefs también pueden tener una textura media, aunque la mayoría no la tienen; esto se usa para hacer que las texturas cuelguen en el aire. Por ejemplo, cuando se ve una textura de barra transparente formando una jaula, este es un ejemplo de una textura intermedia en una línea de definición de dos lados.
Doom hace uso de un sistema conocido como partición de espacio binario (BSP). [10] Se utiliza una herramienta para generar los datos BSP para un nivel de antemano. Este proceso puede llevar bastante tiempo para un nivel grande. Es por esto que no es posible mover las paredes en Doom ; Aunque las puertas y los ascensores se mueven hacia arriba y hacia abajo, ninguno de ellos se mueve nunca hacia los lados.
El nivel se divide en un árbol binario : cada ubicación en el árbol es un "nodo" que representa un área particular del nivel (con el nodo raíz representando el nivel completo). En cada rama del árbol hay una línea divisoria que divide el área del nodo en dos subnodos. Al mismo tiempo, la línea divisoria divide linedefs en segmentos de línea llamados "segs". [11]
En las hojas del árbol hay polígonos convexos , donde no es necesaria una mayor división del nivel. Estos polígonos convexos se denominan subsectores (o "SSECTORES") y están vinculados a un sector particular. Cada subsector tiene una lista de segmentos asociados a él. [10]
El sistema BSP clasifica los subsectores en el orden correcto para su renderizado. El algoritmo es bastante simple:
El proceso se completa cuando se llena toda la columna de píxeles (es decir, no quedan más espacios). Este orden garantiza que no se pierda tiempo dibujando objetos que no son visibles y, como resultado, los mapas pueden volverse muy grandes sin ninguna penalización de velocidad.
Todas las paredes de Doom están dibujadas verticalmente; Es por esto que no es posible mirar hacia arriba y hacia abajo correctamente. Es posible realizar una forma de búsqueda hacia arriba/abajo mediante "y-shearing", y muchos puertos fuente modernos de Doom hacen esto, así como juegos posteriores que usan el motor, como Heretic . Básicamente, esto funciona moviendo la línea del horizonte hacia arriba y hacia abajo dentro de la pantalla, proporcionando de hecho una "ventana" en un área visible más alta. Al mover la ventana hacia arriba y hacia abajo, es posible dar la ilusión de mirar hacia arriba y hacia abajo. Sin embargo, esto distorsionará la vista cuanto más arriba y abajo mire el jugador.
El motor de Doom renderiza las paredes a medida que atraviesa el árbol BSP, dibujando subsectores por orden de distancia desde la cámara, de modo que los segmentos más cercanos se dibujen primero. A medida que se dibujan los segmentos, se almacenan en una lista vinculada. Esto se utiliza para recortar otros segmentos renderizados más adelante, reduciendo el sobredibujo. Esto también se usa más adelante para recortar los bordes de los sprites.
Una vez que el motor alcanza una pared sólida (de un lado) en una coordenada x particular, no es necesario dibujar más líneas en esa área. Para recortar, el motor almacena un "mapa" de áreas de la pantalla donde se han alcanzado paredes sólidas. Esto permite recortar por completo partes lejanas del nivel que son invisibles para el jugador.
El formato gráfico de Doom almacena las texturas de las paredes como conjuntos de columnas verticales ; Esto es útil para el renderizador, que esencialmente renderiza las paredes dibujando muchas columnas verticales de texturas.
El sistema de dibujo de suelos y techos ("pisos") es menos elegante [ ¿según quién? ] que el utilizado para las paredes. Los pisos se dibujan con un algoritmo similar a un relleno de inundación . Debido a esto, si se utiliza un constructor BSP incorrecto, a veces es posible obtener "agujeros" donde el piso o el techo sangran hasta los bordes de la pantalla, un error visual comúnmente conocido como "rastro de limo". [13] Esta es también la razón por la cual si el jugador viaja fuera del nivel usando el truco noclip, los pisos y techos parecerán extenderse desde el nivel sobre el espacio vacío.
El suelo y el techo se dibujan como "visplanos". Estos representan tramos horizontales de textura, desde un piso o techo a una altura, nivel de luz y textura particular (si dos sectores adyacentes tienen exactamente el mismo piso, estos pueden fusionarse en un visplano). Cada posición x en el visplano tiene una línea vertical particular de textura que se va a dibujar.
Debido a este límite de dibujar una línea vertical en cada posición x, a veces es necesario dividir los visplanos en múltiples visplanos. Por ejemplo, considere ver un piso con dos cuadrados concéntricos . El cuadrado interior dividirá verticalmente el piso circundante. En ese rango horizontal donde se dibuja el cuadrado interior, se necesitan dos visplanos para el piso circundante.
Esto lleva a una de las limitaciones clásicas de Doom que frustró a muchos cartógrafos [ ¿quién? ] por mucho tiempo. Doom contenía un límite estático en el número de visplanos; si se excede, se produciría un "desbordamiento de visplanos", lo que provocaría que el juego saliera a DOS con uno de dos mensajes: "¡No más visplanos!" o "desbordamiento de visplano (128 o superior)". La forma más sencilla de invocar el límite del visplano es un gran patrón de suelo en forma de tablero de ajedrez; esto crea una gran cantidad de visplanos.
A medida que se renderizan los segmentos, también se agregan visplanos, que se extienden desde los bordes de los segmentos hacia los bordes verticales de la pantalla. Estos se extienden hasta llegar a los visplanos existentes. Debido a la forma en que esto funciona, el sistema depende del hecho de que el motor general represente los segmentos en orden; es necesario acercarse primero a los visplanos más cercanos, para que puedan ser "cortados" por otros más alejados. Si no se detiene, el piso o el techo se "sangrarán" hasta los bordes de la pantalla, como se describió anteriormente. Con el tiempo, los visplanos forman un "mapa" de áreas particulares de la pantalla en las que se pueden dibujar texturas particulares.
Mientras que los visplanos se construyen esencialmente a partir de "franjas" verticales, la representación real de bajo nivel se realiza en forma de "tramos" horizontales de textura. Una vez construidos todos los visplanos, se convierten en tramos que luego se muestran en la pantalla. Esto parece ser una compensación: es más fácil construir visplanos como franjas verticales, pero debido a la naturaleza de cómo aparecen las texturas del piso y el techo, es más fácil dibujarlos como franjas horizontales.
Cada sector dentro del nivel tiene una lista vinculada de cosas almacenadas en ese sector. A medida que se dibuja cada sector, los sprites se colocan en una lista de sprites que se dibujarán. Si no están dentro del campo de visión, se ignoran.
Los bordes de los sprites se recortan comprobando la lista de segmentos dibujados previamente. Los sprites en Doom se almacenan en el mismo formato basado en columnas que las paredes, lo que nuevamente es útil para el renderizador. Las mismas funciones que se usan para dibujar paredes también se usan para dibujar sprites.
Si bien se garantiza que los subsectores estarán en orden, los sprites dentro de ellos no lo están. Doom almacena una lista de sprites a dibujar ("vissprites") y ordena la lista antes de renderizarla. Los sprites lejanos se dibujan antes que los cercanos. Esto provoca un sobregiro, pero normalmente es insignificante.
Hay un último problema con las texturas intermedias en líneas de 2 lados, utilizadas en barras transparentes, por ejemplo. Estos se mezclan y dibujan con los sprites al final del proceso de renderizado, en lugar de con las otras paredes.
El motor Doom alcanzó la mayor parte de su fama como resultado de impulsar el clásico juego de disparos en primera persona Doom , y se utilizó en varios otros juegos. Generalmente se considera que los "Cuatro Grandes" juegos con motor de Doom son Doom , Heretic , Hexen: Beyond Heretic y Strife: Quest for the Sigil .
En la década de 1990, un puñado de desarrolladores adquirieron licencias para distribuir conversiones totales de Doom y, tras la publicación del código fuente en 1997, se produjeron varios títulos independientes en el motor, incluidos software gratuito , fangames y títulos comerciales. [14]
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
