Sony PlayStation
La historia de PlayStation comenzó en 1988 cuando Nintendo y Sony comenzaron a trabajar juntos en un lector de CD-ROM opcional para la consola SNES. Según los términos del acuerdo, Sony pudo desarrollar de forma independiente juegos para esta plataforma y retuvo el control del formato Super Disc, dos concesiones inusuales de Nintendo.El proyecto se desarrolló antes de la exposición CES '91, en la que Sony anunció una colaboración en Play Station. Al día siguiente, en la misma exposición, Nintendo, para sorpresa de Sony, anunció que había firmado un acuerdo de asociación con Philips (en términos mucho más favorables). Sony, leal y humillada públicamente, trató de apelar ante la junta directiva de Sega, que rechazó de inmediato la idea. En una entrevista con 2013, el CEO de SEGA, Tom Kalinske, recordó la decisión del consejo.“Esta es una idea estúpida, Sony no sabe cómo desarrollar equipos. No saben escribir software. ¿Por qué nos metemos con ellos? - Junta Directiva de SEGA
Y no se equivocaron, Sony realmente tenía poca experiencia trabajando con juegos. Casi no mostró interés en ellos, con la excepción de la iniciativa de una persona: Ken Kutaragi. Desde el momento en que vio a su hija jugar en la Nintendo Famicom, Ken ha estado convenciendo a Sony de que necesita ingresar a este mercado. A pesar de las recomendaciones de los vicepresidentes de Sony, incluso desarrolló para Nintendo el chip de audio (SPC700) utilizado en SNES.La mayoría de los ejecutivos de Sony consideraron esto como una apuesta arriesgada, pero Kutaragi encontró apoyo en la persona del CEO de Sony, Norio Oga. En junio de 1992, a Ken se le permitió comenzar a crear un sistema de juegos desde cero. Para calmar a la junta directiva, el "padre de la PlayStation", como comenzaron a llamarlo más tarde, fue transferido a la empresa matriz financieramente independiente Sony Music, y comenzó a trabajar en lo que eventualmente se convertiría en la "PlayStation" (ya sin un espacio en el nombre).Inicialmente, los desarrolladores no podían decidir si la arquitectura debería centrarse en gráficos 2D de sprite o gráficos 3D de polígonos. Sin embargo, el éxito del juego Virtua Fighter lanzado en octubre de 1993 por Sega en máquinas arcade japonesas destruyó todas las dudas: la PSX seguirá el camino 3D.La culminación del proyecto llegó dos años después, cuando se creó Sony Computer Entertainment el 3 de diciembre de 1994 y la consola se lanzó en Japón. Obtuvo éxito instantáneo y se vendió el primer día con una circulación de 100 mil dispositivos, 2 millones de dispositivos después de seis meses y 102 millones de dispositivos a lo largo de su vida.Sony PSX (PS1, PlayStation). Foto: WikipediaArquitectura
El corazón de la máquina es un procesador RISC R3000A de 32 bits fabricado por MIPS con una frecuencia de 33.8688 MHz [3] en combinación con 2 MB de DRAM. Es de destacar que este chip también tiene un decodificador de movimiento (MDEC), que proporciona reproducción de video con una resolución de 320x240 a una frecuencia de 30 fps. Junto a MDEC, vemos el coprocesador Geometry Transform Engine (GTE) utilizado para realizar operaciones matemáticas rápidas de punto fijo en vectores y matrices. El sistema en su conjunto no puede trabajar con números de coma flotante.La GPU es una "caja negra" controlada por el procesador central mediante "comandos". Tiene 1 MB de VRAM, no disponible para la CPU. En muchos sentidos, su trabajo se asemeja al trabajo del maravilloso modo Inmediato OpenGL: dibuja polígonos texturizados que se pueden "sombrear" usando colores de vértice. La tubería de gráficos es fija y no se puede programar. No hay buffer Z (buffer de profundidad).La unidad de procesamiento de sonido Unidad de procesamiento de sonido (SPU), como la GPU, es una caja negra. Puede procesar 24 canales, tiene 512 KB de SRAM para almacenar audio (en formato ADPCM) y es capaz de mezclar pistas de audio de CD-ROM con sus canales de audio. La abreviatura SRAM no significa "RAM estática", sino "RAM de sonido".La decisión más atrevida de los ingenieros de Sony fue la elección del soporte de datos. Eligieron no cartuchos, sino un módulo de CD-ROM de doble velocidad, que redujo el costo de los juegos y aumentó significativamente el volumen disponible (hasta aproximadamente 650 MB). Las desventajas son la baja velocidad de transferencia (300 KB / s) y el tiempo de instalación del cabezal monstruosamente grande (300 ms).No hay blitter en la consola. El modelo de programación de la máquina era que los desarrolladores no tocaban el hierro "desnudo". Sin embargo, hay un controlador DMA para transmitir datos desde CD / DRAM a VRAM / SRAM.Sistema de vídeo
A pesar de que el sistema de video admite color de 24 bits, muy pocos juegos lo han utilizado (con la excepción de los fondos de Heart Of Darkness [4] ). En la práctica, se puede decir con buena conciencia que la mayoría de los juegos usaban colores de 16 bits con una máscara de 1 bit.Espacio de color PSX con una profundidad de 15 bits por píxelUna característica sorprendente del sistema de video es la organización de VRAM, que depende completamente del desarrollador. 1 MB de VRAM se considera una matriz de 1024 x 512 x 16 bits que se puede usar libremente. La aplicación de almacenamiento en búfer doble o triple se realiza de manera trivial, porque el área es simplemente suficiente para reservar, dibujar y transferir al sistema de salida. Las texturas también están en VRAM, al lado de los búferes de cuadros. Para escribir en el búfer de cuadros, se inician los comandos de GPU para representar triángulos / cuadrángulos texturizados.Las texturas pueden tener varios formatos. Hay dos fuentes directas de colores de 16 bits y 24 bits, así como fuentes basadas en una paleta llamada Tabla de búsqueda de color (CLUT). Se admiten CLUT de 8 y 4 bits.En términos de resolución, la consola se limitó a los estándares de televisión NTSC y PAL. Para los mercados de EE. UU. Y Japón, el desarrollador podría elegir una resolución horizontal de 256, 320, 384, 512 o 640 píxeles. La resolución vertical era 240 píxeles (al omitir cada segunda línea de trama) o 480 píxeles al alternar. Ambos modos verticales funcionan a una frecuencia de 60 Hz. La única diferencia entre NTSC y PAL fue una mayor resolución vertical (256/512 en lugar de 240/480) y una frecuencia de actualización más baja (50 Hz).Modo NTSC (60Hz) PAL (50Hz) Nota
=================================================== ========
0 256 x 240 256 x 256 No entrelazado
1 320 x 240 320 x 256 No entrelazado
2 512 x 240 512 x 256 no entrelazado
3640 x 240640 x 256 No entrelazado
4 256 x 480 256 x 512 intercalados
5 320 x 480 320 x 512 intercalados
6 512 x 480 512 x 512 intercalados
7 640 x 480 640 x 512 entrelazado
8 384 x 240 384 x 256 Sin entrelazar
9 384 x 480 384 x 512 intercalados
Preste atención a los modos con una resolución horizontal de 384 píxeles (8 y 9), que, a juzgar por su id, se agregaron más tarde.DOOM en PSX
DOOM fue portado a PSX por Williams Entertainment con el soporte de id Software. Un equipo de cinco personas tardó un poco menos de un año [5] [6] en portar el motor, cambiar los recursos y modificar el juego para que todo funcionara "solo" en 3.5 MB de RAM.“Los gráficos se han degradado: las texturas se reducen en tamaño, sprites, monstruos y armas también. [...] A veces cortamos cuadros de animación ". - Harry Tisley
El resultado final fue lanzado el 16 de noviembre de 1995. Se considera el mejor puerto de consola del juego, y algunos aspectos incluso superan la versión para PC debido a las tapas de color y la música con calidad de CD."Hasta ahora, este es el mejor DOOM!" - John Romero
Plan de estudios
Debido a la naturaleza del desarrollo, la estructura DOOM se basa en un núcleo que utiliza seis subsistemas para E / S. La mayoría de las veces estudié las tres partes que me parecieron más interesantes, a saber, el sistema de archivos basado en CD-ROM, el audio basado en SPU y el video basado en GPU, porque son exclusivos de la arquitectura PSX.El código fuente de DOOM para PSX nunca se publicó, pero resultó no ser un problema en absoluto. La información disponible es suficiente.La primera fuente es el impresionante PSY-Q SDK, que era la herramienta "oficial" utilizada por los desarrolladores de PSX de la época. Hay mucha documentación, presentada como un conjunto de archivos PDF. Tal abundancia de información solo confirma todo lo bueno que escuché sobre la amabilidad de PSX con los desarrolladores. La biblioteca (es decir, libcd, libds) desarrollada por Psygnosis también está bien documentada. Fue muy agradable ver explicaciones claras, especialmente en comparación con la falta casi completa de información sobre otras consolas (sí, estoy hablando de SNES).Otra fuente de información son las numerosas herramientas externas disponibles en la actualidad. ISOBuster me permitió abrir el contenido del CD. PSound ayudó a escanear archivos LCD. La sorprendente capacidad del emulador no $ PSX para rastrear comandos de GPU y SPU se ha convertido en oro real.Pero quizás estaba más impresionado con el gran amor de DOOM por PSX por parte de la comunidad de fanáticos. Se realizó una ingeniería inversa completa del juego. PSXDOOM-RE destaca especialmente porque es una base de código C que puede compilarse usando el SDK de PSY-Q en un juego completo de PSX. El código es altamente confiable porque se obtuvo reescribiendo cada función del código de máquina en C.El asombroso mundo de los CD
Antes de comenzar a estudiar la implementación del sistema de archivos, hice una pequeña excursión para comprender mejor el maravilloso mundo de los CD.Durante 20 años, de 1980 a 2000, se han publicado varios volúmenes de especificaciones que revelan este tema. Juntos, se llaman "Libros del arco iris". El primer libro de la serie, "Libro Rojo", contiene especificaciones para un disco compacto de audio (CD). El "Libro Amarillo" es un complemento del "Libro Rojo", agrega especificaciones de datos para CD-ROM e ISO-9600. El Orange Book ha agregado especificaciones para CD-DA, CD-R (grabable) y CR-WR (regrabable). El Libro Blanco está dedicado a Video-CD (VCD). El Libro Verde habla sobre CD-Interactive (CD-I). El Libro Azul presenta datos de CD mejorado (ECD) para soporte multimedia. Scarlet Book está dedicado a Super Audio (SACD), que agrega audio de alta definición. El Libro Púrpura enumera la especificación de CD de doble densidad (DDCD), que ha aumentado la capacidad del disco de 650 MB a 1.3 GB. Finalmente,Cyan Book detalla las especificaciones del sistema de archivos 9660[7] .Rainbow Books contiene todo lo que sabemos sobre el CD.Como mínimo absoluto, debemos entender que los CD de PSX generalmente consisten en sectores, cada uno de los cuales contiene 2048 bytes de datos. Los sectores se agrupan en pistas (que pueden ser datos o sonido). Las pistas se agrupan en sesión. La información de las pistas de datos se puede organizar utilizando el sistema de archivos estándar ISO-9660, sin embargo, el juego también puede tener direcciones de sector codificadas.Dentro del CD del juego DOOM
Si mira dentro del CD-ROM usando ISOBuster, puede ver que DOOM consiste en una sesión que contiene ocho pistas [8] . Siete de ellos son pistas de sonido con calidad de CD reproducidas entre misiones y en la escena final. La pista final (# 7) incluso usa voces de demonios digitalizadas. La pista número 6 es especialmente notable porque parece haber sido tomada directamente de la fiesta rave. Resulta que esta es música que se reproduce en la tarjeta súper secreta 59 "Club DOOM" (una tarjeta secreta accesible solo desde una tarjeta secreta) [9] . Déjame dejarte apreciar su locura. Antes de comenzar, verifique el volumen del sonido.La pista restante (número 1) es ISO-9660, que contiene el motor del juego y la mayoría de los recursos. Después de explorar los muchos puertos DOOM, ingenuamente esperaba un motor llamado DOOM.EXE, un archivo de recursos PSXDOOM.WAD y posiblemente un manifiesto. Estaba muy equivocado Se encontraron 287 archivos [10] [11] en la pista , incluidos 60 .WAD, 120 .IMG e innumerables .LCD.Los datos se ordenan por nivel (cinco archivos por tarjeta).Nombre del archivo Descripción
=================================================== =====
MAPDIR0 / MAP01.WAD Geometría estándar (BSP / Rechazar / ...)
MAPDIR0 / MAPTEX01.IMG Texturas de planos / paredes
MAPDIR0 / MAPSPR01.IMG Todos los sprites creados por THINGS
MUSIC / MUSLEV1.LCD Música reproducible
SNDMAPS1 / MAP01.LCD Todos los sonidos hechos por THINGS
Cuando se le preguntó por qué todo estaba organizado de una manera nueva, el desarrollador de Crash Bandicoot, Andy Gavin, respondió parcialmente en una entrevista con Ars Technica. [ traducción en Habré]"Se tarda aproximadamente 1/3 de segundo en mover la cabeza a cualquier punto del CD".
Debido al hecho de que la velocidad de posicionamiento del cabezal era cercana a los 300 ms (lo que se confirma mediante la documentación de PSY-Q [12] ), los desarrolladores de Williams Entertainment no pudieron guardar la arquitectura clara del motor DOOM, que almacenaba todos los recursos en un archivo (por ejemplo, DOOM.WAD) y los descargó a pedido. En la PSX, esto conduciría a una velocidad de cuadro terrible.Los desarrolladores resolvieron el problema lanzando una cantidad aparentemente interminable de bytes en el CD. Todos los recursos necesarios para el nivel se almacenaron en cinco archivos que contienen la geometría del mapa, la textura. sprites, efectos de sonido y música. Esto es muy costoso, pero eliminó la necesidad de acceder al CD durante el proceso del juego.Hecho interesante:en la lista de archivos en la pista de datos hay un archivo llamado PSXDOOM.WAD (4 806 088 bytes), pero se usa solo para cargar paletas y varias imágenes de menú. Probablemente más utilizado activamente en el proceso de desarrollo.Tome el primer mapa como ejemplo: la cantidad total de datos descargados se ha reducido de 4 MB a 900 KB.Tamaño del nombre del archivo (en bytes)
=====================================
MAPDIR0 / MAP01.WAD 28196
MAPDIR0 / MAPTEX01.IMG 90744
MAPDIR0 / MAPSPR01.IMG 590344
MÚSICA / MUSLEV1.LCD 61 232
SNDMAPS1 / MAP01.LCD 143 632
=====================================
Total: 914,148
Sabiendo que los recursos ocupan 914 KB, podría pensar que quedaba una gran cantidad de DRAM sin usar. Pero debe recordar que también tenía que ajustarse a un archivo ejecutable de 428 KB, así como a una pila que cambia en tiempo de ejecución. De hecho, solo aproximadamente 1 MB de DRAM estaba disponible en tiempo de ejecución.Un hecho interesante: al examinar el código fuente de PSXDOOM-RE, encontré la función P_LoadBlocks, que intenta leer desde el CD hasta cuatro veces [13] , después de lo cual se rinde. Este es uno de los placeres de trabajar con medios que se rayan fácilmente.No esperaba que el tiempo de instalación del cabezal del CD-ROM afectara tanto la arquitectura del juego. Algunos juegos, como Crash Bandicoot, se crearon desde cero con un sistema de páginas para transmitir datos desde un CD en tiempo de ejecución. En el caso de DOOM, el motor no era capaz de esto. El CD no se usa durante el juego, con la excepción de una canción en particular (sí, desde el nivel Club DOOM).Los chicos de id Software nunca han sido fanáticos de la compensación entre capacidad y velocidad que ofrecían los CD-ROM.« - . , CD. - , Crash 'n Burn — ? . , CD , 3DO . - CD- DOOM, „ DOOM“. , . .
, CD. ». — (ATARI EXPLORER ONLINE, 22 1994 )
Un hecho interesante: los eventos dentro del juego DOOM se activaron usando "estrías". Al cruzar una línea con una propiedad especial, se llamó a una función especial. En la versión "heredada" del motor no había propiedad que le permitiera tocar canciones. Para jugar al Club DOOM, se creó una acción de definición de línea especial (número 142) [14] . Es sorprendente la cantidad de esfuerzo adicional que se necesitó para crear este nivel. Probablemente a los desarrolladores realmente les gustaba divertirse en las raves.El caso del arzobispo desaparecido
Al realizar una investigación para mi Game Engine Black Book, no pude entender completamente esta frase del diseñador Harry Teesley:“Archvile tenía el doble de cuadros de animación que cualquier otro monstruo, y no pudimos incluirlo en la PSX. Ni su ataque ni el efecto de resurrección podrían perderse. Era demasiado grande ". - Harry Tisley (diseñador) en una entrevista con doomworld.com
Era obvio que el problema no era la capacidad de 650 megabytes del CD, pero no entendí cuál era el factor limitante: DRAM o VRAM.Habiendo entendido las limitaciones del CD-ROM, me di cuenta de que el problema no estaba en almacenar el sprite en un CD, o incluso transferirlo de DRAM a VRAM. El problema es encajar todo en DRAM.Dato interesante: ArchVile se elimina por completo del código fuente de PSXDOOM-RE. Incluso su #DEFINE está comentado [15] .#define CC_ZOMBIE "Zombieman"
#define CC_SHOTGUN "Shotgun Guy"
#define CC_HEAVY "Heavy Weapon Dude"
...
#define CC_HELL "Hell Knight"
#define CC_SPIDER "The Spider Mastermind"
#define CC_CYBER "The Cyberdemon"
#define CC_HERO "Our Hero"
Programación SPU
El chip SPU solo comprende un formato, a saber, ADPCM. Es capaz de mezclar hasta 24 canales (incluida la pista de audio de CD) y tiene potentes funciones de manipulación de audio.Para domar a esta bestia, el DOOM PSX utiliza la biblioteca libWESS (Williams Entertainment Sound System), escrita por el ingeniero de sonido Scott Patterson. La biblioteca es bastante poderosa, es capaz de recrear el sistema MiDI, en el que un pesado banco de notas (llamado fuente de sonido) está controlado por una partitura musical que ocupa poco espacio. También puede manipular atributos de sonido en tiempo real como volumen, tono, velocidad de nota y funciones ADSR (ataque, decaimiento, sostenido y liberación). Toda la música que se reproduce durante el juego se genera usando libWESS. Con una excepción, lo adivinó, este es el Club DOOM, que se reproduce desde la pista de CD número 6.WESS utiliza dos formatos de archivo propietarios. Estos son archivos .WMD que contienen partituras y efectos de sonido, y archivos .LCD, que tienen formato PSX VAG (sin título) y contienen muestras de ADPCM. Cuando se inicia DOOM, la biblioteca libWESS carga todos los efectos de sonido (SFX, 89 piezas) y partituras musicales (19 piezas) almacenadas en un pequeño archivo (55 KB) llamado DOOMSND.WMD. Ella también carga en la SRAM "siempre usado" muestras publicadas por el personaje, puertas, etc.MÚSICA / DOOMSFX.LCD -> SRAM
MÚSICA / DOOMSND.WMD -> DRAM
Después de cargar el mapa, libWESS abre MUSIC / MUSLEV% .LCD, que contiene las muestras de ADPCM utilizadas en la música de esta tarjeta, y SNDMAPS% / MAP %%. LCD, que contiene las muestras de ADPCM necesarias para los enemigos a este nivel. Todas las muestras de ADPCM se cargan directamente en SRAM y no ocupan espacio en DRAM.DOOM en PSX: GPU
En el área de la generación de videos, Williams Entertainment necesitaba resolver dos problemas: una pequeña cantidad de VRAM (volveremos a esto más adelante) y la falta de un mapeo de textura correcto teniendo en cuenta la perspectiva.“Aaron Siler y yo trabajamos en versiones para Nintendo 64 (este juego era bastante diferente) y para Playstation. Estas fueron las primeras versiones que no fueron escritas en metal desnudo, porque Sony y Nintendo obligaron a los desarrolladores (al menos de terceros) a escribir API y no les dieron documentación sobre los registros de hardware. Al principio, la cultura SGI limitó particularmente a los desarrolladores, pero gradualmente Nintendo aflojó su control.
Una historia divertida sobre el desarrollo de una versión para Playstation: Aaron y yo comenzamos con una arquitectura de motor diferente, que representaba los triángulos del mundo, porque la consola les proporcionaba una aceleración de hardware completa. En el caso de N64, esto funcionó perfectamente, ya que tenía una representación correcta en perspectiva con una precisión de subpíxeles (el resultado de la influencia de SGI), pero en el Playstation se realizó un mapeo de textura afinado con coordenadas enteras, por lo que los grandes triángulos de pared y piso parecían IMPRESIONANTES ”. - John Carmack (Game Engine Black Book: DOOM)
Para entender cuán "terrible" se veía, debajo mostré tres paredes renderizadas con texturas afines y prospectivamente correctas.Texturas en perspectivaAffine (PSX)Tenga en cuenta que no hay problema con una pared recta y, a medida que aumenta el ángulo de perspectiva, la distorsión se vuelve más notable.El mismo problema de percepción se enfrentó a los desarrolladores de Rage Software al portar DOOM a SEGA Saturn.« , id Software. , WAD Saturn, , 3D-. , , 3D- . , PC. , , : SH2 , PC, 68000 .
, » — ( DOOM Saturn) RetroGamer №134.
Tal vez, dado que los desarrolladores de PSX tuvieron más tiempo, pudieron resolver el problema de la asignación de textura prospectivamente correcta al convertir el renderizador de polígonos de GPU en renderizador de línea."Dije: haz una copia de seguridad de todo (¡entonces todavía no había sistemas de control de versiones!), Haremos que el juego sea completamente diferente". Utilizamos equipos que representaban triángulos que representaban columnas o filas de un píxel de ancho, al igual que en el código del ensamblador en una PC, y funcionó muy bien. Resultó que la solución más común en Playstation era la teselación de la geometría a lo largo de dos ejes, pero realmente me gustó que Doom pareciera menos "nervioso" que la mayoría de los juegos para Playstation de esa época ". - John Carmack (Game Engine Black Book: DOOM)
Gracias al proyecto PSXDOOM-RE [16], podemos descubrir cómo se implementó. La canalización de renderizado ha sido completamente reescrita y dividida en dos etapas. Esto se discutirá con más detalle a continuación, pero en realidad podemos ver que la función de representación R_Render_Wall transmite comandos de dibujo codificados con un ancho de 1 píxel.void R_Render_Wall(...) {
.
int x1 = ... ;
int x2 = ... ;
.
while(x1 < x2) {
.
setRGB0(wallpoly);
setXY3(wallpoly,
x1 , ypos1 - 1,
x1 + 1, ypos2 + 1,
x1 , ypos2 + 1);
setUV3(wallpoly,
upos, v0,
upos, v1,
upos, v1);
.
x1 += 1;
}
}
Los muros se representan en columnas de un píxel de ancho. Echa un vistazo a la API, que se parece al modo Inmediato en OpenGL.Dato interesante: el diseñador de hardware de Sony retuvo el i-cache del procesador MIPS, pero desactivó su d-cache para convertirlo en un scratchpad de alta velocidad de 1K. Los procedimientos de representación de pared / plano utilizaron este scratchpad ampliamente.Gestión de GPU VRAM
Para aprender cómo se realiza el control VRAM, elegí una forma curiosa: utilicé la función de ver el emulador VRAM en tiempo real sin $ PSX. Esta función muestra la matriz completa de píxeles 1024 x 512 x 16 bits (aunque en forma distorsionada). La función de visualización también muestra la lista completa de instrucciones de GPU transmitidas por el procesador central en cada cuadro.No $ PSX: Dios nos envió un emulador que le permite mirar dentro de la GPU.Un estudio cuidadoso del primer fotograma de VRAM le permite aprender mucho.El primer cuadro del juego se muestra con No $ PSX.Las más obvias son dos áreas de 256 x 240 x 16 bits en la esquina superior izquierda, que son los búferes de cuadros (por lo tanto, el juego usa doble búfer). Vale la pena señalar que 256x240 es la resolución más baja posible en una PSX.Debajo de los búferes de cuadros hay un conjunto colorido de píxeles: la paleta CLUT. Tenga en cuenta los tonos de rojo, significan que cuando la pantalla se vuelve roja cuando el jugador recibe daño, se usan paletas precalculadas.En la esquina superior derecha vemos texturas que están extrañamente comprimidas horizontalmente y tienen colores "incorrectos". Sucedió porque las texturas usan índices de 8 bits del CLUT descrito anteriormente.Hablemos de fuego en DOOM en PS1 nuevamente
En 2018, estudié cómo se realizó el efecto del fuego [17] [ traducción en Habré]. Fue genial volver a él nuevamente al explorar los comandos de la GPU. Observe que ningún $ PSX marca el área de destino de cada comando en rojo.Etapa 1: la llama se actualiza en RAM y se carga en VRAM (comando CpuToVram).Etapa 2: la textura de la llama se dibuja cuatro veces a lo largo de la pantalla (comando QuadTex). La textura de la llama tiene un ancho de 32 texels, pero la GPU se usa para dibujarlo con un ancho de 64 píxeles. Aquí no es posible el filtrado bilineal, se muestrean los texels más cercanos.Etapa 3: la placa final de DOOM (comando QuadTex) se dibuja encima de todo.Fotograma completo, equipo por equipo
Un estudio de los comandos transmitidos en el marco mostró que el motor es completamente diferente de la versión para PC. En él, el mundo estaba rodeado de una corta distancia en la distancia. Primero, se representan todos los muros. En la segunda pasada, se llena un espacio vertical entre ellos (visplane) (incluido el cielo). En el tercer (último) pasaje, se representan los sprites, comenzando por el más lejano. Todo esto se hizo con cero píxeles de redibujado.En PSX, el renderizado es un poco más grosero. Todo se procesa en un solo paso, realizado a partir de lejos. El sistema de visplane que la PC usó para llenar el vacío entre las paredes no está aquí. Gracias a un nuevo concepto llamado "hojas", el plano y las paredes se representan en el orden de los subsectores. Dichas operaciones en "verdadero 3D" se hicieron posibles debido al uso activo de las funciones de proyección de matriz GPE. Los sprites también se representan simultáneamente con paredes / planos sin controles de superposición y truncamiento, lo que resulta en una pequeña cantidad de redibujado.void R_RenderPlayerView(void) {
R_BSP();
R_RenderSKY();
for (all subsectors from phase 1) {
R_RenderAll(subsector)
}
R_Render_Hud_Weapons();
}
Miremos cada paso en detalle, comenzando con el cielo, que primero se representa con CopyRectRaw. no $ PSX muestra VRAM en el momento en que se completa el marco, pero le permite volver al historial de comandos. Los píxeles del cielo son visibles solo porque ningún $ PSX tiene problemas para percibir este truco con columnas de un ancho de píxel (otros emuladores, como ePSXe, no pueden hacer frente mejor [18] ), pero todos estos píxeles se reescribirán. Tenga en cuenta que bajo las texturas del cielo, todos los marcadores de las llaves de las puertas se recogen en un atlas.Luego, el BSP se atraviesa en orden de lejos a cerca. Para cada subsector, se representan todos los muros / planos / sprites. Si está familiarizado con DOOM BSP, probablemente recuerde que el compilador de doombsp solo mantuvo segmentos sólidos de subsectores. Para garantizar la representación de los planos, se agregó un nuevo concepto de "hojas" a la versión de PSX, en la que se almacenaron segmentos de separación BPS (invisibles). Estos segmentos se proyectan en el espacio de la pantalla para generar límites planos. Este es un enfoque mucho más "limpio", porque le permite deshacerse de los hacks con espacio en la pantalla y errores, por ejemplo, del conocido "rastro de babosas".
¡Desbordamiento de VRAM!
Trabajar con la GPU fue un ejercicio de asignación de espacio en VRAM. En el caso de búferes de trama, CLUT, contenido estático (interfaz) e incluso paredes / planos, la tarea es elemental, porque todos tienen el mismo tamaño. Pero con los sprites, las cosas son un poco más complicadas.Debido al hecho de que los sprites tienen diferentes tamaños, conducen a la fragmentación. Además, las texturas pueden cubrir grandes áreas de la pantalla y repetirse, y los sprites son a menudo únicos y puede ser necesario un número impredecible de ellos en cada cuadro. En el peor de los casos, un marco requiere una cierta cantidad de sprites que no se pueden colocar en VRAM. Esto se denomina desbordamiento de caché de textura y este problema no se puede resolver. Cuando esto sucede, el juego se bloquea y muestra un mensaje de error críptico [19]recordándonos a algunos de nosotros el siniestro "No más visplanes".Cuantos más sprites veas al mismo tiempo, más VRAM se usa.La diferencia entre PAL y NTSC
En conclusión del capítulo de video, decidí ver cómo NTSC se convierte a PAL. Desafortunadamente, como en muchos otros juegos, el DOOM PSX no tuvo en cuenta el aumento de la resolución vertical. Al jugar DOOM en PS1 en Europa, viste una imagen comprimida verticalmente con bordes negros notables.Después de conocer los principios de VRAM, me resulta difícil culpar a los desarrolladores. Si observa detenidamente el esquema VRAM en NTSC, notará que aumentar la resolución vertical del búfer de trama viola toda la estructura de asignación de datos. Sería imposible almacenar texturas debajo de él. O tendrías que mover CLUT a otra ubicación. Demasiado costo con relativamente poco beneficio, e incluso a pesar del hecho de que las fronteras negras interfieren con el juego, estoy de acuerdo en que no valió la pena.Expresiones de gratitud
Gracias a Eric Vázquez (autor de PSXDOOM-RE), Samuel Villarreal (uno de los desarrolladores de PSXDOOM-RE) y Dan Leslie (desarrollador profesional de juegos para PlayStation 1) por compartir generosamente sus conocimientos conmigo.