Kompilieren wie 1992 (2014)

 (fabiensanglard.net)
3 Punkte von GN⁺ 2024-02-27 | 1 Kommentare | Auf WhatsApp teilen
  • Der originale Wolfenstein-3D-Quellcode von 1992 passt nicht direkt auf moderne Systeme, lässt sich aber erneut kompilieren, wenn man die Umgebung mit DosBox und Borland C++ 3.1 nachbildet
  • Die benötigten Komponenten sind der Wolfenstein-3D-Quellcode, DosBox, Borland C++ 3.1 und die Shareware-Assets zum Ausführen
  • Beim Build-Prozess müssen nicht nur die Projekteinstellungen von Borland C++ gesetzt, sondern auch die Pfade für PATH, SIGNON.OBJ und GAMEPAL.OBJ manuell korrigiert werden
  • Der Grund für die Grafikfehler beim ersten Start ist, dass der im Engine-Code einkompilierte Grafikindex nicht mit den Positionen innerhalb der Asset-Dateien übereinstimmt
  • Wenn man die neu erzeugten VGA-Assets kopiert und in DosBox die aspect correction aktiviert, lässt sich das Spiel in einer Form starten, die dem CRT-Seitenverhältnis von 1992 nahekommt

Die Build-Umgebung von 1992 nachbilden

  • Der originale Wolfenstein-3D-Quellcode von 1992 ist auf modernen Systemen mehr als 20 Jahre später nicht mehr ohne Weiteres nutzbar, kann aber kompiliert werden, wenn man die damaligen Werkzeuge und die Laufzeitumgebung passend einrichtet
  • Benötigt werden diese vier Dinge
    • Wolfenstein-3D-Quellcode
    • DosBox
    • Borland C++ 3.1
    • Wolfenstein-3D-Shareware-Assets

Verzeichnisse vorbereiten, die wie DOS-Laufwerke genutzt werden

  • Lokal werden zwei Verzeichnisse angelegt, die wie DOS-Laufwerke verwendet werden
    • system/c
    • system/a
  • In system/a kommt das Archiv von Borland C++ 3.1
  • In system/c kommen der Wolfenstein-3D-Quellcode und die VGA-Dateien
  • Nach dem Entpacken ist die Dateistruktur wie folgt
    • system/a: BCPP31.zip
    • system/c: wolfsrc.zip, vgafiles.zip

Compiler und Quellcode in DosBox installieren

  • Nach dem Start von DosBox werden lokale Ordner als DOS-Laufwerke gemountet
    • ~/system/c wird als C: gemountet
    • ~/system/a wird als A: gemountet
  • In A:\BCPP31 wird install ausgeführt, um Borland C++ 3.1 zu installieren
    • Die Standardeinstellungen bleiben unverändert und die Installation wird gestartet
    • Die Warnung, dass kein Microsoft-Windows-Ordner gefunden werden kann, ist hier nicht relevant und wird mit Enter übersprungen
  • Unter C:\ wird das Installationsprogramm für den Wolfenstein-3D-Quellcode ausgeführt, mit dem Standardpfad \WOLFSRC

Das Borland-C++-Projekt bauen

  • Borland C++ 3.1 wird über C:\BORLANDC\BIN\BC.EXE gestartet
  • Das Projekt ..\..\WOLFSRC\WOLF3D.PRJ wird geöffnet und die Verzeichnisse werden wie folgt gesetzt
    • Include Directories: C:\BORLANDC\INCLUDE
    • Library Directories: C:\BORLANDC\LIB
    • Output Directories: OBJ
    • Source Directories: C:\WOLFSRC
  • Beim ersten Build tritt der Fehler Cannot find executable TASM auf
    • Borland C++ wird beendet, PATH=C:\BORLANDC\BIN gesetzt und das Programm anschließend erneut gestartet
  • Beim nächsten Build tritt in der Link-Phase der Fehler Unable to find OBJ file auf
    • SIGNON.OBJ und GAMEPAL.OBJ sind im Projekt fälschlich auf den Pfad C:\SOURCE\WOLF\ gesetzt
    • Die beiden Einträge werden aus dem Projekt entfernt und anschließend als WOLFSRC\OBJ\SIGNON.OBJ bzw. WOLFSRC\OBJ\GAMEPAL.OBJ erneut hinzugefügt
  • Danach verläuft Compile -> Build All erfolgreich

Laufzeit-Assets und Ursache der Grafikfehler

  • Um die kompilierte ausführbare Datei zu starten, werden die Shareware-Assets oder die Vollversions-Assets von Wolfenstein 3D benötigt
  • Nach der Installation der Shareware wird die kompilierte .EXE in den Spielordner kopiert und gestartet, doch die Anzeige ist fehlerhaft
  • Der Grund liegt in der Produktions-Pipeline der Grafikdateien und in der Art, wie die Engine auf Assets zugreift
    • Adrian Carmack und Kevin Cloud erstellten die Grafikdateien und bündelten sie anschließend mit dem Tool IGRABed
    • Das Ergebnis besteht aus den drei Dateien VGAHEAD.WL1, VGAGRAPH.WL1, VGADICT.WL1 sowie den beiden Dateien GRE.H und GRE.EQU
  • VGAHEAD.WL1 ist ein Index, der auf die Datenpositionen innerhalb von VGAGRAPH.WL1 verweist
    • In VGAGRAPH.WL1 liegen Huffman-komprimierte Daten
    • VGADICT.WL1 enthält das Huffman-Wörterbuch zum Dekomprimieren
  • GRE.H und GRE.EQU sind Dateien, über die die Engine per Namen auf Assets zugreifen kann
    • Ein logischer Name wie L_GUYPIC wird dabei mit einem tatsächlichen Indexwert verknüpft
    • Die Engine wird mit hartkodierten Bildindizes gebaut
  • Nach der Veröffentlichung der Wolfenstein-3D-Shareware veränderten sich Assets und Codebasis zusammen mit Spears of Destiny, sodass die Indizes des neu kompilierten Spiels nicht mehr zu den Positionen in den vorhandenen Asset-Dateien passten

VGA-Assets austauschen und Seitenverhältnis korrigieren

  • Die Lösung besteht darin, die neu erzeugten VGA-Assets, die zu den im Quellcode enthaltenen .H- und .EQU-Indizes passen, in den Spielordner zu kopieren
  • Wenn Shareware-Assets verwendet werden, müssen die Dateierweiterungen beim Kopieren von .WL6 in .WL1 geändert werden
    • VGADICT.WL6 → VGADICT.WL1
    • VGAGRAPH.WL6 → VGAGRAPH.WL1
    • VGAHEAD.WL6 → VGAHEAD.WL1
  • Nach dem Austausch funktioniert das Spiel wieder korrekt, wenn WOLF3D.EXE erneut gestartet wird
  • Die Standardanzeige von DosBox entspricht nicht dem Bild, das Menschen 1992 ursprünglich gesehen haben
    • Der VGA-Framebuffer ist 320x200
    • CRT-Monitore hatten ein 4:3-Seitenverhältnis, wodurch das Bild bei der Ausgabe vertikal gestreckt wirkte
  • In der DosBox-Konfiguration kann unter [render] aspect=false auf aspect=true geändert werden, um die Seitenverhältnis-Korrektur zu aktivieren
  • Mit dieser Korrektur läuft Wolfenstein 3D in einer Darstellung, die der damaligen CRT-Ausgabe sehr nahekommt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-02-27
Meinungen auf Hacker News

  • Ich kann das am Ende des Artikels erwähnte Wolfenstein-3D-Buch sehr empfehlen. Obwohl es technisch ist, ist es weder trocken noch langweilig, und es enthält viele Old-School-Optimierungen: 64 ausgerollte Funktionen zum Skalieren von Wandtexturen, die Art, Sprites „seitlich“ zu speichern, der Umgang mit seltsamen Grafikkarten und wie man Grafikmodi hackte, damit es überhaupt wie ein Spiel aussah

    • Danke für die Empfehlung. Ich habe gerade das 431-seitige PDF über die Game Engine heruntergeladen, sogar mit einem Vorwort von John Carmack
    • Ist dieses Buch gemeint? https://fabiensanglard.net/Game_Engine_Black_Book/index.php
      Es sieht so aus, als sei es noch nicht erschienen, stimmt das?
    • Stimme voll und ganz zu. Ich wusste nicht einmal, dass es solche Bücher gibt, habe aber sowohl das Wolfenstein-3D- als auch das Doom-Buch wirklich gern gelesen. Schade, dass er kein Quake/i586-Buch schreiben wird
    • Auch das Nachfolgebuch zu Doom liest sich hervorragend

  • Das Gute an Retro-Systemen ist, dass man sie wieder bauen kann, sobald man nur die Tools zusammenträgt. Ich habe kürzlich zum Spaß das alte Spiel Uplink neu kompiliert; alles, was ich brauchte, war Visual Studio 6.0, und im Entwicklungsarchiv waren alle zum Build nötigen Abhängigkeiten enthalten
    Es dauerte etwa eine Stunde, die Abhängigkeiten passend einzurichten, aber am Ende hat es geklappt, und das Spiel läuft gut. Ich habe auch ein paar kleine Bugs behoben und hier und da kleine Verbesserungen eingebaut. Wenn ich daran denke, das mit heutiger Software zu tun, wirkt das völlig wahnsinnig

    • Das trifft meiner Meinung nach eher auf Fälle zu, in denen Linux-Paketmanagement ein Durcheinander ist. In kommerziellen Embedded-/Windows-Projekten, die ich gesehen habe, wurden Abhängigkeiten üblicherweise in einen thirdparty/-Ordner vendored, und die verwendete Toolchain war ebenfalls festgelegt, sodass das Setup immer reproduzierbar war
    • Heutzutage besteht ein großer Teil dessen, was man braucht, einfach darin, die passende Version von Unity oder Unreal zu installieren. Für die Zeit vor Unity stimmt das sicher
    • Ich wusste gar nicht, dass der Quellcode von Uplink veröffentlicht ist. Tolles Spiel

  • Ich habe mit Borland Turbo C++ programmieren gelernt. Einer der Gründe, warum ich diese Zeit vermisse, ist, dass man Dinge, die kompliziert wirkten, so einfach erledigen konnte. Man rief einfach Funktionen für geometrische Formen auf, und schon wurden sie auf den Bildschirm gezeichnet; nachdem man eine Form gezeichnet hatte, konnte man durch Aufruf der Funktion xor auf eine leicht andere Form sogar Animationen erzeugen
    Mit Freunden habe ich mit diesen Techniken ein Final-Fantasy-ähnliches Spiel gebaut, mit handgemachten Sprites, kartenweisen Screens, einer Welt, in der man am Rand zur benachbarten Karte wechselte, und Kämpfen, die starteten, wenn bei jedem Schritt die natürliche Zahl 1 herauskam. Es war umständlich, aber für einen Schüler unglaublich spaßig; und entscheidend war, dass man nicht wie heute gleich zu Beginn SFML, ActiveX oder OpenGL lernen musste, sondern einfach circle aufrufen konnte

    • Wenn man eine Umgebung sucht, in der Kinder einfache Formen programmieren können, gibt es so etwas vermutlich auch heute noch. Der Unterschied ist, dass sich „Werkzeuge für Profis“ und „Werkzeuge für Kinder/Einsteiger“ stärker getrennt haben; Turbo C++ und zu meiner Zeit Turbo Pascal waren beidem recht nah
    • Ich bin ein bisschen neidisch darauf, dass du als Kind Zugang zu Borland Turbo C++ und Lernmaterial hattest. Bei mir beschränkte es sich darauf, Reviews in lokalen Computerzeitschriften zu lesen; selbst wenn ich eine Kopie bekommen hätte, hätte ich ohne Lesematerial nicht gewusst, was ich damit anfangen sollte. Und mit meinen damaligen Englischkenntnissen weiß ich nicht, wie viel ich selbst mit Material verstanden hätte
    • Moderne 2D-Grafik funktioniert nicht mehr so, dass man Pixel in einen Framebuffer setzt; Texturen oder Surfaces sind die grundlegenden Systemelemente, und das Compositing wird als separater Schritt behandelt. Deshalb ist es eher einfacher geworden, „einfache Sprites“ zu erstellen; man kann eine zusammengesetzte Surface als allgemeinere Form eines Hardware-Sprites betrachten
    • Das erinnert mich an das gute alte conio.h und Borlands BGI-graphics.h. Heute übernimmt SDL in gewissem Maße diese Rolle, ist aber nicht ganz so simpel
    • Borland Turbo C++ ist bis heute mit großem Abstand meine Lieblings-IDE

  • Nachdem es hier über die Jahre mehrfach erwähnt wurde, habe ich vor ein paar Monaten endlich Masters of Doom gelesen, und es war ein großartiges Buch. Die Spiele, die sie damals bauten, waren schon als Spielerlebnis unglaublich spannend; rückblickend ist aber noch inspirierender, was ein paar junge Entwickler mit wenig Mitteln erschaffen konnten

    • Romero hat kürzlich seine Memoiren Doom Guy veröffentlicht; ich frage mich, ob sie jemand gelesen hat. Würde gern wissen, ob es ein gutes Buch ist

  • Ich vermisse die textbasierten UIs von DOS wirklich. Ich denke an meinen zuverlässigen PS/2, den ich bis etwa 1997 weiterbenutzte

    • Man kann immerhin Midnight Commander im Terminal verwenden

  • Installation auf Laufwerk C, was für ein Luxus! Ich hatte keine Festplatte, also habe ich ständig Disketten zwischen Laufwerk A und B gewechselt, und der Compiler verlangte immer wieder nach ausgetauschten Teilen. Trotzdem hatten wir Spaß. Die Kinder von heute glauben einem solche Geschichten nicht, selbst wenn man sie ihnen immer wieder erzählt

    • 1992 hatte ich eine 8,9 MB große 5,25-Zoll-Festplatte mit voller Bauhöhe und dazu zwei 5,25-Zoll-360-KB-Diskettenlaufwerke. Ich war neidisch auf den Mac meines Freundes mit 720-KB-Diskettenlaufwerk und 30-MB-Festplatte, aber dieses System war vermutlich etwa sechsmal so teuer wie mein PC
    • Es geht um 1992, nicht um 1982

  • Borland C++ war wirklich hervorragend. Eine IDE mit C++-Compiler, Standardbibliothek und Debugger passte in etwa 5 MB, inklusive der gemütlichen Borland-Farbpalette mit gelber Schrift auf blauem Hintergrund

    • Es kam auch mit einem gedruckten Handbuch, das ein C++-Tutorial enthielt. Damit habe ich früher C++ gelernt
    • OWL war auch ziemlich gut
    • Zortech war viel besser

  • Borlands MS-DOS-IDEs sind süße Erinnerungen

    • Wenn du solche Nostalgie hast, lohnt sich ein Blick auf Free Pascal. Es ist ein Open-Source-Pascal-/Delphi-Klon und enthält auch einen Klon des blauen DOS-Turbo-Pascal-Editors, sodass man die gewünschte Atmosphäre bekommt
      Ich habe es dieses Jahr für ein paar Tage Advent of Code benutzt, aber die Nostalgie verflog schnell. Wenn man an moderne Umgebungen gewöhnt ist, sind die Einschränkungen der IDE und die Weitschweifigkeit von Pascal nicht wirklich „spaßig“ für den täglichen Gebrauch. Trotzdem sind die Erinnerungen definitiv süß
    • RHIDE wurde zwar zuletzt vor 23 Jahren aktualisiert, aber der Quellcode dürfte noch irgendwo vorhanden sein. Das eigentliche Problem bei der Implementierung solcher Terminal-Mode-GUIs war, dass Unix-/Linux-Terminals an Terminalstandards gebunden waren, die nicht alle Funktionen von MS-DOS-Textmodusprogrammen bereitstellten
      Insbesondere erkennen sie einzelne Alt-Tastendrücke, Alt+Buchstaben-Kombinationen und Ctrl+Shift+Links/Rechts nicht
    • In meinem alten Bücherregalplatz bewahre ich noch immer eine Kiste mit Turbo-C-Handbüchern auf

  • Verwandter Artikel: Let’s compile like it’s 1992 (2014) - https://news.ycombinator.com/item?id=13750097 - Februar 2017, 80 Kommentare

  • Ich hatte Probleme beim Öffnen des Archivs. Bei wolfsrc.zip kam der Fehler End-of-central-directory signature not found, und es hieß, es sei keine Zip-Datei oder könne Teil eines über mehrere Datenträger verteilten Archivs sein