Hay una forma interesante de estudiar la arquitectura de las computadoras del pasado. Encuentre un programa que conozca e intente descubrir cómo fue portado.
Una buena opción para esto sería DOOM . El megahit de 1994 de id Software fue portado a todo lo posible. El juego está diseñado alrededor del núcleo, claramente dividido en capas. Por lo general, es fácil encontrar y leer la implementación de los seis subsistemas de E / S.
Otra opción sería Another World 1991 de Eric Chailly, más conocido en América del Norte como Out Of This World . Diría que en realidad es más interesante estudiar que DOOM, debido a los gráficos poligonales adecuados para optimizaciones salvajes . En algunos casos, los trucos difíciles permitieron que el juego funcionara en equipos creados cinco años antes del lanzamiento del juego.
- Polígonos de otro mundo.
- Polígonos de otro mundo: Amiga 500 .
- Polígonos de otro mundo: Atari ST .
Esta serie de artículos es un viaje a través de los equipos de videojuegos de principios de los 90. Desde Amiga 500, Atari ST, PC de IBM, Super Nintendo, hasta Sega Genesis. Para cada máquina, traté de descubrir cómo se implementó Another World.
En el mejor de los casos, logré contactar al desarrollador original. En el peor de los casos, tuve que descubrir el código desmontado yo mismo. Fue una aventura divertida.
Otro mundo 101
Otro mundo tiene bastante código. Según los informes, la versión inicial de Amiga tenía solo 6,000 líneas de largo. El archivo ejecutable para DOS en PC es de solo 20 kB. Sorprendentemente para un juego tan grande, que vino en un disquete de 1.44 MiB. Esto se debe a que la mayor parte de la lógica empresarial se implementa utilizando bytecode. El ejecutable Another World es en realidad el host de la máquina virtual que lee y ejecuta los uint8_t .
La máquina virtual en Another World define 256 variables, 64 hilos, 29 códigos de operación y tres framebuffers ( traducción de PatientZero ). Eso es todo Si crea un host para la máquina virtual que puede manejar esto, puede iniciar el juego. Si puede hacer que la máquina virtual sea lo suficientemente rápida como para correr a 20 cuadros por segundo, en realidad puede jugar el juego.
El sistema de gráficos de la máquina virtual utiliza un sistema de coordenadas de 320x200 con una paleta de 16 colores. El límite de la paleta puede sorprender, teniendo en cuenta que el Amiga 500 admite hasta 32 colores. Esto se hizo a propósito, lo que permitió combinar gráficos con otra gran plataforma de la época: Atari ST, que solo admite 16 colores.
Pero no hay un lado positivo. Esta limitación ha llevado a un estilo único que, a lo largo de los años, todavía agrada a la vista.
Incluso cuando era posible usar una paleta específica para la escena, Eric Shayi decidió no hacerlo. Durante una colisión con la Bestia, solo se usan tres colores: negro para el cuerpo, rojo para los ojos y beige para los dientes. La imaginación hizo el resto.
Un sistema similar para la paleta se reveló completamente en la escena inicial. Un cambio de paleta muy barato facilitó la representación de un rayo.
Los rayos de los faros de Ferrari son translúcidos. Están pintados con un color especial de 0x10 que no existe, ya que solo hay 16 colores disponibles. El valor especial se interpreta como "leer el índice de búfer de trama, agregar 0x8 y regresar". La última parte del truco es seleccionar inteligentemente los siguientes 8 colores en la paleta.
Tres framebuffers
De los tres framebuffers, dos se usan para el doble buffer, mientras que el último se usa para preservar la composición de fondo (BKGD). Esta optimización evita volver a dibujar todos los polígonos de fondos estáticos a favor de una operación de copia simple.
En el siguiente video, vea cómo se dibuja una nueva escena primero en el búfer BKGD. Cada nuevo marco BKGD se copia completamente en el búfer doble. Allí se dibujan elementos móviles, como Leicester. Tenga en cuenta que después de que el automóvil está "estacionado", también se dibuja en el búfer BKGD para minimizar la cantidad de polígonos que se dibujarán en los cuadros posteriores.
También tenga en cuenta cómo la composición utiliza un algoritmo simple del artista , que, a pesar de su simplicidad, conduce a un rediseño innecesario. Esto no es un problema, ya que se deprecia en gran medida por una copia de BKGD.
Opcodes de máquinas virtuales
La siguiente tabla muestra 29 códigos de operación. Aquí puede encontrar códigos de operación para control de flujo (THRD), gestión de framebuffer (FB) y todas las operaciones de gestión de registros. La mayoría de las operaciones son "simples" de implementar, con la excepción de COPY FB, FILL y DRAW_POLY *, que son complejas en términos de rendimiento.
Ambos códigos de operación DRAW_POLY_ * abarcan más de una celda. DRAW_POLY_BACKGROUND ocupa la mitad del espacio del código de operación, de 0x80 a 0xFF . Muy derrochador, pero este es un truco para ahorrar espacio. El uso de todas las operaciones que comienzan con el bit "1" permite transferir otros 7 bits al espacio del código de operación como parámetros de representación. Dado que este código de operación se usa para el fondo y la sinomática, es muy importante ahorrar espacio.
La versión SPRITE utiliza todos los códigos de operación que comienzan con los bits "01", mientras que los 6 bits restantes se utilizan para codificar las coordenadas [x, y] y el zoom para representar los "sprites" de Leicester, amigos y enemigos.
Que sigue
Como se mencionó anteriormente, 26 de 29 códigos de operación son fáciles de implementar. El verdadero problema al portar este juego era manipular píxeles dentro de los límites del ancho de banda del bus y del procesador. Esta serie discutirá cómo se manipularon los framebuffers en el puerto y cómo se resolvieron los problemas de los códigos de operación DRAW, FILL y COPY.