Compiler comme en 1992 (2014)

 (fabiensanglard.net)
3 points par GN⁺ 2024-02-27 | 1 commentaires | Partager sur WhatsApp
  • Le code source original de Wolfenstein 3D de 1992 n’est pas directement compatible avec les systèmes modernes, mais il peut être recompilé en recréant un environnement DosBox et Borland C++ 3.1
  • Les éléments nécessaires sont le code source de Wolfenstein 3D, DosBox, Borland C++ 3.1 et les ressources shareware pour l’exécution
  • Pendant la phase de build, il faut corriger manuellement non seulement la configuration du projet Borland C++, mais aussi PATH ainsi que les chemins de SIGNON.OBJ et GAMEPAL.OBJ
  • Si les graphismes sont corrompus au premier lancement, c’est parce que les index graphiques compilés dans le moteur ne correspondent plus à l’emplacement réel des données dans les fichiers de ressources
  • En recopiant des ressources VGA régénérées et en activant l’aspect correction de DosBox, on peut exécuter le jeu avec un rendu proche du format CRT de 1992

Recréer l’environnement de build de 1992

  • Le code source original de Wolfenstein 3D datant de 1992 est difficile à utiliser tel quel sur un système moderne plus de 20 ans plus tard, mais il reste possible de le compiler en reproduisant les outils et l’environnement d’exécution de l’époque
  • Les quatre éléments nécessaires sont les suivants
    • le code source de Wolfenstein 3D
    • DosBox
    • Borland C++ 3.1
    • les ressources shareware de Wolfenstein 3D

Préparer des répertoires qui serviront de lecteurs DOS

  • Créez en local deux répertoires qui serviront de lecteurs DOS
    • system/c
    • system/a
  • Téléchargez l’archive de Borland C++ 3.1 dans system/a
  • Téléchargez le code source de Wolfenstein 3D et les fichiers VGA dans system/c
  • Après extraction, l’agencement des fichiers est le suivant
    • system/a: BCPP31.zip
    • system/c: wolfsrc.zip, vgafiles.zip

Installer le compilateur et les sources dans DosBox

  • Lancez DosBox, puis montez les dossiers locaux comme lecteurs DOS
    • montez ~/system/c sur C:
    • montez ~/system/a sur A:
  • Depuis A:\BCPP31, exécutez install pour installer Borland C++ 3.1
    • conservez les paramètres par défaut et démarrez l’installation
    • l’avertissement indiquant que le dossier Microsoft Windows est introuvable n’est pas important, validez simplement avec Entrée
  • Depuis C:\, lancez le programme d’installation des sources de Wolfenstein 3D et utilisez le chemin par défaut \WOLFSRC

Construire le projet Borland C++

  • Lancez Borland C++ 3.1 avec C:\BORLANDC\BIN\BC.EXE
  • Ouvrez le projet ..\..\WOLFSRC\WOLF3D.PRJ et définissez les répertoires comme suit
    • Include Directories: C:\BORLANDC\INCLUDE
    • Library Directories: C:\BORLANDC\LIB
    • Output Directories: OBJ
    • Source Directories: C:\WOLFSRC
  • Lors du premier build, l’erreur Cannot find executable TASM apparaît
    • quittez Borland C++, définissez PATH=C:\BORLANDC\BIN, puis relancez-le
  • Au build suivant, une erreur Unable to find OBJ file apparaît à l’étape d’édition des liens
    • SIGNON.OBJ et GAMEPAL.OBJ pointent à tort vers C:\SOURCE\WOLF\ dans le projet
    • supprimez ces deux entrées du projet, puis ajoutez-les de nouveau avec WOLFSRC\OBJ\SIGNON.OBJ et WOLFSRC\OBJ\GAMEPAL.OBJ
  • Exécutez ensuite Compile -> Build All pour terminer le build avec succès

Ressources d’exécution et origine des graphismes corrompus

  • Pour lancer l’exécutable compilé, il faut les ressources Wolfenstein 3D en version shareware ou complète
  • Après installation de la version shareware, si vous copiez le .EXE compilé dans le dossier du jeu et l’exécutez, l’affichage apparaît anormal
  • La cause vient du pipeline de production des fichiers graphiques et de la manière dont le moteur accède aux ressources
    • Adrian Carmack et Kevin Cloud créaient les fichiers graphiques avant de les regrouper avec l’outil IGRABed
    • la sortie se compose de trois fichiers VGAHEAD.WL1, VGAGRAPH.WL1, VGADICT.WL1 et de deux fichiers GRE.H, GRE.EQU
  • VGAHEAD.WL1 est un index qui pointe vers l’emplacement des données à l’intérieur de VGAGRAPH.WL1
    • VGAGRAPH.WL1 contient des données compressées avec Huffman
    • VGADICT.WL1 contient le dictionnaire Huffman utilisé pour la décompression
  • GRE.H et GRE.EQU permettent au moteur d’accéder aux ressources par leur nom
    • par exemple, un nom logique comme L_GUYPIC est associé à une valeur d’index réelle
    • le moteur est compilé avec des index d’images codés en dur
  • Après la sortie de la version shareware de Wolfenstein 3D, les ressources et la base de code ont évolué avec Spear of Destiny, si bien que les index du jeu recompilé ne correspondent plus aux positions présentes dans les fichiers de ressources existants

Remplacer les ressources VGA et corriger le format d’image

  • La solution consiste à copier dans le dossier du jeu des ressources VGA régénérées pour qu’elles correspondent aux index .H et .EQU inclus dans le code source
  • Si vous utilisez les ressources shareware, il faut renommer les extensions de .WL6 en .WL1 avant la copie
    • VGADICT.WL6 → VGADICT.WL1
    • VGAGRAPH.WL6 → VGAGRAPH.WL1
    • VGAHEAD.WL6 → VGAHEAD.WL1
  • Après remplacement, relancez WOLF3D.EXE et le jeu fonctionne normalement
  • L’affichage par défaut de DosBox ne correspond pas à ce que voyaient les joueurs en 1992
    • le framebuffer VGA est en 320x200
    • les moniteurs CRT avaient un format 4:3, ce qui étirait l’image verticalement à l’affichage
  • Dans la configuration de DosBox, remplacez aspect=false par aspect=true dans [render] pour activer la correction du format d’image
  • Une fois cette correction activée, Wolfenstein 3D s’exécute avec un rendu proche de celui d’un écran CRT de l’époque

À lire aussi

1 commentaires

 
GN⁺ 2024-02-27
Avis sur Hacker News

  • Je recommande vivement le livre sur Wolfenstein 3D mentionné à la fin de l’article. Même s’il s’agit de contenu technique, ce n’est ni aride ni ennuyeux, et on y trouve beaucoup d’optimisations à l’ancienne : 64 fonctions déroulées pour la mise à l’échelle des textures murales, la façon de stocker les sprites « de côté », la gestion de cartes graphiques bizarres, ou encore le bidouillage du mode graphique pour que ça ressemble à un jeu dès le départ

    • Merci pour la recommandation. Je viens de télécharger le PDF de 431 pages sur le moteur de jeu, qui contient même une préface de John Carmack
    • C’est de ce livre qu’il s’agit ? https://fabiensanglard.net/Game_Engine_Black_Book/index.php
      Il ne semble pas encore être sorti, si ?
    • Tout à fait d’accord. Je ne savais même pas que ces livres existaient, mais j’ai vraiment pris plaisir à lire ceux sur Wolfenstein 3D et Doom. Dommage qu’il ne compte pas écrire le livre sur Quake/i586
    • La suite, le livre sur Doom, se lit aussi très bien

  • Ce qui est bien avec les systèmes rétro, c’est qu’une fois les outils réunis, on peut les reconstruire. Récemment, pour le plaisir, j’ai recompilé le vieux jeu Uplink : il ne fallait que Visual Studio 6.0, et l’archive de développement contenait toutes les dépendances nécessaires au build
    Il m’a fallu environ une heure pour faire correspondre les dépendances, mais j’ai fini par y arriver et le jeu fonctionne bien. J’ai même corrigé quelques petits défauts et ajouté de petites améliorations ici et là. Quand on pense à bricoler du logiciel moderne, c’est vraiment de la folie

    • Cela me semble surtout vrai quand la gestion des paquets Linux est en vrac. Dans l’embarqué commercial et côté Windows que j’ai vus, les dépendances étaient généralement vendoring dans un dossier thirdparty/, et la toolchain utilisée était aussi figée, donc la configuration était toujours reproductible
    • Aujourd’hui, une bonne partie de ce qu’il faut consiste simplement à installer la bonne version de Unity ou d’Unreal. Pour l’époque d’avant Unity, c’est certainement vrai
    • Je ne savais pas que le code source d’Uplink était disponible. Super jeu

  • J’ai appris à programmer avec Borland Turbo C++. L’une des raisons pour lesquelles cette époque me manque, c’est qu’on pouvait faire très facilement des choses qui semblaient complexes. Il suffisait d’appeler des fonctions de formes géométriques pour dessiner à l’écran, et après avoir dessiné une forme, appeler une fonction xor sur une forme légèrement différente permettait même de faire des animations
    Avec des amis, on a utilisé ces techniques pour créer un jeu façon Final Fantasy, avec des sprites faits à la main, des cartes par écran, un monde où l’on passait à la carte voisine en atteignant les bords, et des combats déclenchés quand un 1 naturel sortait à chaque pas. C’était laborieux, mais vraiment amusant pour des lycéens, et le fait de pouvoir simplement appeler circle au lieu de devoir apprendre d’emblée SFML, ActiveX ou OpenGL, comme aujourd’hui, comptait beaucoup

    • Si l’on cherche un environnement où des enfants peuvent programmer des formes simples, il doit encore y avoir des choses comme ça aujourd’hui. La différence, c’est que les « outils pour professionnels » et les « outils pour enfants/débutants » se sont davantage séparés ; Turbo C++, ou le Turbo Pascal de mon époque, était proche des deux à la fois
    • J’envie un peu ceux qui, enfants, ont eu accès à Borland Turbo C++ et à des ressources d’apprentissage. De mon côté, je ne faisais que lire des critiques dans des magazines informatiques locaux, et même si j’avais pu mettre la main sur une copie, je n’aurais pas su quoi en faire sans documentation à lire. Avec mon niveau d’anglais de l’époque, je ne sais pas combien j’aurais compris, même avec des ressources
    • En graphisme 2D moderne, on ne dessine plus des pixels dans un framebuffer : les textures ou les surfaces sont les éléments de base du système, et la composition se fait dans une étape séparée. Créer un « sprite simple » est donc devenu plutôt plus facile, et l’on peut voir les surfaces compositées comme une forme plus générale de sprites matériels
    • Ça me rappelle le bon vieux conio.h et le BGI graphics.h de Borland. Aujourd’hui, SDL joue un peu ce rôle, mais ce n’est pas aussi simple
    • Borland Turbo C++ reste, et de loin, mon IDE préféré

  • Après l’avoir vu mentionné plusieurs fois ici au fil des années, j’ai enfin lu Masters of Doom il y a quelques mois, et c’était un excellent livre. Les jeux qu’ils créaient à l’époque étaient déjà incroyablement intéressants à jouer, mais avec le recul, ce qui inspire encore plus, c’est ce qu’une poignée de jeunes développeurs avec peu de moyens a pu construire

    • Romero a récemment publié ses mémoires, Doom Guy ; je me demande si quelqu’un les a lues. J’aimerais savoir si c’est un bon livre

  • Les interfaces textuelles de DOS me manquent vraiment. Je repense à mon fidèle PS/2, que j’ai utilisé jusqu’à environ 1997

    • On peut toujours utiliser Midnight Commander dans un terminal

  • Installer ça sur le disque C, quel luxe ! Je n’avais pas de disque dur, donc je passais mon temps à changer les disquettes entre les lecteurs A et B, et le compilateur réclamait sans cesse la partie remplacée. Mais on s’amusait quand même. Les jeunes d’aujourd’hui ne nous croient pas quand on raconte ce genre d’histoires

    • En 1992, j’avais un disque dur 5,25 pouces double hauteur de 8,9 Mo, ainsi que deux lecteurs de disquettes 5,25 pouces de 360 Ko. J’enviais le Mac de mon ami, avec son lecteur de disquettes 720 Ko et son disque dur de 30 Mo, mais ce système devait coûter environ six fois le prix de mon PC
    • On parle de 1992, pas de 1982

  • Borland C++ était vraiment remarquable. Un IDE avec compilateur C++, bibliothèque standard et débogueur tenait dans environ 5 Mo, avec en prime cette confortable palette de couleurs Borland, texte jaune sur fond bleu

    • Il était aussi livré avec un manuel imprimé contenant un tutoriel C++. C’est avec lui que j’ai appris le C++ à l’époque
    • OWL était plutôt bon aussi
    • Zortech était bien meilleur

  • Les IDE MS-DOS de Borland sont de doux souvenirs

    • Si vous avez cette nostalgie, Free Pascal vaut le détour. C’est un clone open source de Pascal/Delphi, qui inclut aussi un clone de l’éditeur DOS bleu de Turbo Pascal, de quoi retrouver l’ambiance souhaitée
      Je l’ai utilisé pour quelques jours de l’Advent of Code cette année, mais la nostalgie est vite retombée. Une fois habitué aux environnements modernes, les contraintes de l’IDE et la verbosité de Pascal ne sont pas vraiment « amusantes » au quotidien. Les souvenirs restent toutefois bien doux
    • RHIDE a peut-être encore son code source disponible, même si sa dernière mise à jour remonte à 23 ans. Le vrai problème pour implémenter ce genre de GUI en mode terminal, c’est que les terminaux Unix/Linux étaient coincés avec des standards de terminal qui ne fournissaient pas toutes les fonctionnalités des programmes en mode texte MS-DOS
      En particulier, ils ne reconnaissent pas la touche Alt seule, les combinaisons Alt+lettre, ni Ctrl+Maj+flèche gauche/droite
    • Je garde encore, dans l’espace de mon ancienne bibliothèque, une boîte contenant les manuels de Turbo C

  • Article lié : Let’s compile like it’s 1992 (2014) - https://news.ycombinator.com/item?id=13750097 - février 2017, 80 commentaires

  • J’ai eu un problème pour ouvrir l’archive. Avec wolfsrc.zip, j’obtenais l’erreur End-of-central-directory signature not found, indiquant que ce n’était pas un fichier zip ou que cela pouvait être une partie d’une archive répartie sur plusieurs disques