Compilemos como en 1992 (2014)

 (fabiensanglard.net)
3 puntos por GN⁺ 2024-02-27 | 1 comentarios | Compartir por WhatsApp
  • El código fuente original de Wolfenstein 3D de 1992 no encaja directamente con los sistemas modernos, pero puede volver a compilarse si se recrea el entorno de DosBox y Borland C++ 3.1
  • Los componentes necesarios se resumen en el código fuente de Wolfenstein 3D, DosBox, Borland C++ 3.1 y los assets shareware para ejecutar el juego
  • En el proceso de build, además de configurar el proyecto de Borland C++, hay que corregir manualmente las rutas de PATH, SIGNON.OBJ y GAMEPAL.OBJ
  • La razón por la que los gráficos se ven corruptos al ejecutarlo por primera vez es que el índice de gráficos compilado en el motor no coincide con las posiciones internas de los archivos de assets
  • Al copiar los assets VGA regenerados y activar el aspect correction de DosBox, puede ejecutarse con una apariencia cercana a la relación de aspecto de los CRT de 1992

Recrear el entorno de build de 1992

  • El código fuente original de Wolfenstein 3D de 1992 es difícil de usar tal cual en sistemas modernos después de más de 20 años, pero puede compilarse si se ajustan las herramientas y el entorno de ejecución de la época
  • Los componentes necesarios son estos cuatro
    • Código fuente de Wolfenstein 3D
    • DosBox
    • Borland C++ 3.1
    • Assets shareware de Wolfenstein 3D

Preparar directorios para usarlos como unidades DOS

  • Se crean localmente dos directorios para usarlos como unidades DOS
    • system/c
    • system/a
  • En system/a se descarga el archivo comprimido de Borland C++ 3.1
  • En system/c se descargan el código fuente de Wolfenstein 3D y los archivos VGA
  • Después de descomprimir, la disposición de archivos queda así
    • system/a: BCPP31.zip
    • system/c: wolfsrc.zip, vgafiles.zip

Instalar el compilador y el código fuente en DosBox

  • Tras ejecutar DosBox, se montan las carpetas locales como unidades DOS
    • Se monta ~/system/c como C:
    • Se monta ~/system/a como A:
  • En A:\BCPP31, se ejecuta install para instalar Borland C++ 3.1
    • Se mantiene la configuración predeterminada y se inicia la instalación
    • La advertencia de que no se puede encontrar la carpeta de Microsoft Windows no es necesaria, así que se avanza con Enter
  • En C:\, se ejecuta el instalador del código fuente de Wolfenstein 3D y se usa la ruta predeterminada \WOLFSRC

Build del proyecto en Borland C++

  • Se ejecuta Borland C++ 3.1 con C:\BORLANDC\BIN\BC.EXE
  • Se abre el proyecto ..\..\WOLFSRC\WOLF3D.PRJ y se configuran los directorios así
    • Include Directories: C:\BORLANDC\INCLUDE
    • Library Directories: C:\BORLANDC\LIB
    • Output Directories: OBJ
    • Source Directories: C:\WOLFSRC
  • En el primer build aparece el error Cannot find executable TASM
    • Se cierra Borland C++, se configura PATH=C:\BORLANDC\BIN y se vuelve a ejecutar
  • En el siguiente build aparece el error Unable to find OBJ file en la etapa de enlace
    • SIGNON.OBJ y GAMEPAL.OBJ están especificados erróneamente en el proyecto con la ruta C:\SOURCE\WOLF\
    • Se eliminan ambos elementos del proyecto y se vuelven a agregar como WOLFSRC\OBJ\SIGNON.OBJ y WOLFSRC\OBJ\GAMEPAL.OBJ
  • Después, al ejecutar Compile -> Build All, el build se completa correctamente

Assets de ejecución y causa de los gráficos corruptos

  • Para ejecutar el archivo compilado se necesitan los assets de la versión shareware o de la versión completa de Wolfenstein 3D
  • Si después de instalar la versión shareware se copia el .EXE compilado a la carpeta del juego y se ejecuta, la pantalla se muestra de forma extraña
  • La causa está en el pipeline de producción que crea los archivos gráficos y en la forma en que el motor accede a los assets
    • Adrian Carmack y Kevin Cloud creaban los archivos gráficos y luego los empaquetaban con la herramienta IGRABed
    • La salida consta de 3 archivos: VGAHEAD.WL1, VGAGRAPH.WL1, VGADICT.WL1, y 2 archivos: GRE.H, GRE.EQU
  • VGAHEAD.WL1 es un índice que apunta a las posiciones de datos dentro de VGAGRAPH.WL1
    • VGAGRAPH.WL1 almacena datos comprimidos con Huffman
    • VGADICT.WL1 contiene el diccionario Huffman para la descompresión
  • GRE.H y GRE.EQU son archivos que permiten que el motor acceda a los assets por nombre
    • Por ejemplo, un nombre lógico como L_GUYPIC se conecta con el valor real del índice
    • El motor se compila con los índices de imagen hardcodeados
  • Después del lanzamiento shareware de Wolfenstein 3D, al cambiar los assets y la base de código junto con Spears of Destiny, los índices del juego recién compilado dejaron de coincidir con las posiciones de los archivos de assets existentes

Reemplazo de assets VGA y corrección de relación de aspecto

  • La solución es copiar a la carpeta del juego los assets VGA regenerados para que coincidan con los índices .H y .EQU incluidos en el código fuente
  • Si se usan assets shareware, hay que copiarlos cambiando la extensión de archivo de .WL6 a .WL1
    • VGADICT.WL6 → VGADICT.WL1
    • VGAGRAPH.WL6 → VGAGRAPH.WL1
    • VGAHEAD.WL6 → VGAHEAD.WL1
  • Tras el reemplazo, al ejecutar de nuevo WOLF3D.EXE, el juego funciona correctamente
  • La pantalla predeterminada de DosBox es distinta de la pantalla original que veía la gente en 1992
    • El framebuffer VGA es de 320x200
    • Los monitores CRT tenían relación de aspecto 4:3, por lo que la salida se veía estirada verticalmente
  • Si en la configuración de DosBox se cambia aspect=false a aspect=true en [render], se aplica la corrección de relación de aspecto
  • Al aplicar también la corrección de relación de aspecto, Wolfenstein 3D se ejecuta con una apariencia cercana al modo en que se mostraba en los CRT de la época

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-02-27
Comentarios en Hacker News

  • Recomiendo muchísimo el libro de Wolfenstein 3D mencionado al final del artículo. Aunque es técnico, no se siente rígido ni aburrido, y está lleno de optimizaciones a la vieja escuela, como 64 funciones desplegadas para escalar texturas de paredes, guardar sprites “de lado”, lidiar con tarjetas gráficas rarísimas y hackear el modo gráfico para que al menos pareciera un juego

    • Gracias por la recomendación. Acabo de descargar el PDF de 431 páginas sobre el motor del juego, y hasta incluye un prólogo de John Carmack
    • ¿Te refieres a este libro? https://fabiensanglard.net/Game_Engine_Black_Book/index.php
      Parece que todavía no ha salido, ¿no?
    • Totalmente de acuerdo. Ni siquiera sabía que existían estos libros, pero disfruté muchísimo tanto el de Wolfenstein 3D como el de Doom. Es una pena que no vaya a escribir el libro de Quake/i586
    • El libro de Doom, que salió después, también se lee muy bien

  • Lo bueno de los sistemas retro es que, si reúnes las herramientas, puedes volver a compilar. Hace poco recompilé por diversión el viejo juego Uplink, y lo único que necesité fue Visual Studio 6.0; el archivo de desarrollo incluía todas las dependencias necesarias para el build
    Me tomó como una hora cuadrar las dependencias, pero al final funcionó y el juego corre bien. Incluso arreglé un defecto menor e hice pequeñas mejoras por aquí y por allá. Si pienso en tocar software moderno, de verdad parece una locura

    • Eso aplica más cuando la gestión de paquetes en Linux es un desastre. En el mundo comercial de embebidos/Windows que me ha tocado ver, normalmente las dependencias se vendoran dentro de una carpeta thirdparty/, y también se fija la toolchain que se usa, así que la configuración siempre era reproducible
    • Hoy en día, gran parte de lo necesario es simplemente instalar la versión correcta de Unity o Unreal. Para la era previa a Unity, definitivamente tienes razón
    • No sabía que el código fuente de Uplink estaba publicado. Gran juego

  • Aprendí a programar con Borland Turbo C++. Una de las razones por las que extraño esa época es que podías hacer cosas que parecían complejas con muchísima facilidad. Bastaba con llamar funciones geométricas para dibujar en pantalla, y después de trazar una figura, podías hacer animación llamando xor sobre una figura ligeramente distinta
    Con unos amigos hicimos un juego tipo Final Fantasy usando esa técnica, con sprites hechos a mano, mapas por pantalla, un mundo donde al llegar al borde pasabas al mapa adyacente, e incluso un sistema en el que entrabas en combate cuando salía el número natural 1 en cada paso. Era engorroso, pero para unos estudiantes de preparatoria era realmente divertido, y ayudaba mucho que, en vez de tener que aprender SFML, ActiveX u OpenGL desde el principio como hoy, bastaba con llamar circle

    • Si buscas un entorno donde los niños puedan programar con formas simples, supongo que todavía debe haber algo así. La diferencia es que ahora hay una separación mucho mayor entre las “herramientas para profesionales” y las “herramientas para niños/principiantes”, mientras que Turbo C++ o el Turbo Pascal de mi época estaban cerca de ser ambas cosas
    • Envidio un poco haber podido tener acceso a Borland Turbo C++ y a material de aprendizaje cuando eras pequeño. Yo apenas llegaba a leer reseñas en revistas locales de computación, y aunque hubiera conseguido una copia, sin material para leer no habría sabido qué hacer. Con el nivel de inglés que tenía entonces, ni siquiera sé cuánto habría entendido aunque hubiera tenido la documentación
    • Los gráficos 2D modernos ya no funcionan dibujando píxeles sobre un framebuffer; los elementos básicos del sistema son las texturas o superficies, y la composición se hace en una etapa aparte. Por eso hacer un “sprite simple” en realidad se volvió más fácil, y puedes pensar en una superficie compuesta como una forma más general de un sprite por hardware
    • Me trae recuerdos del buen viejo conio.h y del BGI graphics.h de Borland. Hoy en día SDL cumple un poco ese papel, pero no es tan simple
    • Borland Turbo C++ sigue siendo, por mucho, mi IDE favorito de todos los tiempos

  • Después de verlo mencionado varias veces aquí durante años, hace unos meses por fin leí Masters of Doom, y me pareció un libro excelente. Los juegos que hacían en ese entonces ya eran fascinantes de jugar, pero visto en retrospectiva, lo que más inspira es lo que unos cuantos desarrolladores jóvenes con tan pocos recursos pudieron llegar a crear

    • Vi que Romero publicó recientemente sus memorias, Doom Guy; me pregunto si alguien ya las leyó. Me gustaría saber si valen la pena

  • De verdad extraño la interfaz de texto de DOS. Me hace pensar en ese confiable PS/2 que seguí usando hasta más o menos 1997

    • Al menos siempre puedes usar Midnight Commander en la terminal

  • ¿Instalar en la unidad C:? ¡Eso ya era un lujo! Yo no tenía disco duro, así que me la pasaba cambiando disquetes entre las unidades A y B, y el compilador seguía pidiendo partes intercambiadas. Aun así, nos divertíamos. Los jóvenes de hoy ni nos creerían si les contáramos estas historias

    • En 1992 yo tenía un disco duro de 8.9 MB de 5.25 pulgadas y doble altura, además de dos unidades de disquete de 360 KB de 5.25 pulgadas. Le tenía envidia a la Mac de un amigo, que tenía una unidad de disco de 720 KB y un disco duro de 30 MB, pero ese sistema seguramente costaba unas 6 veces más que mi PC
    • Es 1992, no 1982

  • Borland C++ era realmente sobresaliente. Un IDE con compilador de C++, biblioteca estándar y depurador cabía en unos 5 MB, además de esa acogedora paleta de colores de Borland con letras amarillas y fondo azul

    • También venía con un manual impreso que incluía un tutorial de C++. Yo aprendí C++ con eso hace años
    • OWL también era bastante bueno
    • Zortech era mucho mejor

  • Los IDE de MS-DOS de Borland son recuerdos entrañables

    • Si te da esa nostalgia, quizá valga la pena probar Free Pascal. Es un clon open source de Pascal/Delphi, y también incluye un clon del editor DOS azul de Turbo Pascal, así que puede darte justo esa sensación
      Lo usé para algunos días del Advent of Code este año, pero la nostalgia se me pasó rápido. Ya acostumbrado a entornos modernos, las limitaciones del IDE y lo verboso de Pascal no se sentían “divertidos” para el uso diario. Aun así, los recuerdos sí son dulces
    • RHIDE quizá no se actualiza desde hace 23 años, pero todavía debe quedar su código fuente. El verdadero problema al implementar este tipo de GUI en modo terminal era que las terminales Unix/Linux estaban atadas a estándares que no ofrecían todas las capacidades de los programas de modo texto de MS-DOS
      En particular, no podían reconocer una pulsación de Alt por sí sola, combinaciones Alt+letra ni Ctrl+Shift+flecha izquierda/derecha
    • Todavía guardo una caja con los manuales de Turbo C en un espacio donde antes tenía libros

  • Artículo relacionado: Let’s compile like it’s 1992 (2014) - https://news.ycombinator.com/item?id=13750097 - febrero de 2017, 80 comentarios

  • Tuve problemas al abrir el archivo. En wolfsrc.zip me salió el error End-of-central-directory signature not found, diciendo que no era un archivo zip o que podía ser parte de un archivo dividido en varios discos