Discussion :

[LittleWhite]

Game Engine Black Book: Wolfenstein 3D

How was Wolfenstein 3D made and what were the secrets of its speed? How did id Software manage to turn a machine designed to display static images for word processing and spreadsheet applications into the best gaming platform in the world, capable of running games at seventy frames per seconds? If you have ever asked yourself these questions, Game Engine Black Book is for you. This is an engineering book. You will not find much prose in here (the author’s English is broken anyway.) Instead, this book has only bit of text and plenty of drawings attempting to describe in great detail the Wolfenstein 3D game engine and its hardware, the IBM PC with an Intel 386 CPU and a VGA graphic card. Game Engine Black Book details techniques such as raycasting, compiled scalers, deferred rendition, VGA Mode-Y, linear feedback shift register, fixed point arithmetic, pulse width modulation, runtime generated code, self-modifying code, and many others tricks. Open up to discover the architecture of the software which pioneered the First Person Shooter genre.

[Lire la suite]

• Avez-vous lu ce livre ou pensez-vous le lire ?
• Souhaitez-vous ajouter une critique de ce livre sur la page de la rubrique ?
• Avez-vous un commentaire à faire ?

[ohnomorejmmings]

Pourquoi pas revisiter un classique aussi majeur mais il faut voir ce qu'il apporte de plus par rapport aux livres déjà existants. Avec ses 300 pages j'appréhende un paquet de code pas forcément utile. Ça aurait peut-être été mieux d'élargir le sujet à Doom et surtout le II compte tenu des nettes améliorations du moteur de lancer de rayon notamment. Enfin tant mieux si ça permet à certains lecteurs de découvrir cette époque passionnante et à d'autres de s'y replonger !

[LittleWhite]

Il n'y a pas beaucoup d'exemples de code. Il y en a, mais je n'ai pas trouvé qu'ils étaient trop nombreux. Il y a beaucoup de pages où ce sont des captures d'écran.
Vous pouvez en trouver quelques pages du livre sur Google Book (soit le premier chapitre... où il n'y a pas de code).

[codec_abc]

Pour en avoir un exemplaire à la maison, Assurez-vous d'avoir de bonnes connaissances bas niveau. Une maitrise de l'assembleur ne sera pas du luxe pour comprendre les morceaux de code présentés en détail.

[Paul TOTH]

il y a un truc qui m'échappe, c'est quoi l'intérêt en 2017 de sortir un bouquin sur le moteur graphique de W3D ?!

j'ai étudié tout cela il y a fort longtemps pour un moteur 3D sous Turbo Pascal pour DOS
http://tothpaul.free.fr/sources.php?bp7.wolf3d

mais de nos jours ça n'a plus beaucoup d'intérêt de travailler comme ça....à part pour s'amuser, comme porter W3D sous Javascript, mais même là WebGL est plus indiqué que le rendu software orignal.

[Kannagi]

Je pense pareil , j'en vois pas l’intérêt surtout que a la même année Alone in the Dark sortait et lui faisait de la 3D polygonale comme on l'a connaît :p
(et qui en plus inspiré Resident evil , même au technique utilisé ).

[Paul TOTH]

Je pense pareil , j'en vois pas l’intérêt surtout que a la même année Alone in the Dark sortait et lui faisait de la 3D polygonale comme on l'a connaît :p
(et qui en plus inspiré Resident evil , même au technique utilisé ).

non mais la technique utilisée dans W3D (et améliorée dans DOOM 1) est très intéressante, les gars ils ont fait un très beau boulot pour faire tourner un jeu 3D temps réel sur un 386...mais ce n'est juste plus nécessaire de nos jours. Alone in the Dark c'est autre chose, le décors est statique et seuls les personnages se déplacent en 3D...c'est aussi un symptôme de l'époque, comment faire du temps réel sur un 386. Le secret du Templier utilisait une technique similaire, et pour l'époque c'était génial...c'est même intéressant de savoir de nos jours comment c'était fait à l'époque...mais de là à en faire un bouquin...ça m'échappe...je suis même surpris qu'un éditeur prenne le risque de publier sur le sujet

[hotcryx]

Le problème reste quand même d'actualité: car c'est comment faire tourner du code lourd (3D), sans carte graphique sur un petit ordinateur de l'époque.
Ce concepte peut être appliqué à des jeux actuels plus lourds avec des effets de lumière, bump mapping sur un pc plus récent tout en réduisant l'utilisation d'une carte graphique.

[Paul TOTH]

Le problème reste quand même d'actualité: car c'est comment faire tourner du code lourd (3D), sans carte graphique sur un petit ordinateur de l'époque.
Ce concepte peut être appliqué à des jeux actuels plus lourds avec des effets de lumière, bump mapping sur un pc plus récent tout en réduisant l'utilisation d'une carte graphique.

c'est vrai, mais la technique de W3D ne me semble pas adaptée...son idée géniale était de calculer unique 320 points par image (la largeur de l'écran 320x200) selon un principe de raycasting. On lance un rayon de l'oeil de l'obervateur en direction du premier pixel de la ligne...peu importe sa hauteur vu que W3D et DOOM1 utilisent des niveaux 2D, dans W3D le sol est plat, dans DOOM1 il peut y avoir des escaliers, mais aucune sale ne peut se superposer à une autre, le plan reste donc en 2D. une fois qu'on a déterminé quel mur se trouve sur ce point, on calcule la distance pour pouvoir afficher toute la colonne de pixel avec un facteur de zoom adapté (et un décalage vertical dans DOOM pour refléter la différence de niveau), et on passe à la colonne suivante.

pour appliquer cela sur un moteur récent il faut cette fois calculer autant de points que la largeur de l'écran et conserver la limitation d'un plan 2D....on utilisera donc probablement d'autres méthodes (BSP Tree, Frustum culling,...) qu'on retrouve dans Quake par exemple.

[Guntha]

...ça m'échappe...je suis même surpris qu'un éditeur prenne le risque de publier sur le sujet

C'est simple: l'éditeur, c'est l'auteur:


Et le raycasting n'est qu'une petite partie du bouquin. Ce qui est intéressant, c'est toutes les petites merdes des PC et des OS de l'époque qui obligeaient à faire plein de bricolage:
->L'OS ne pouvait adresser qu'1 Mo de RAM, même si on en avait plusieurs dans sa machine. Pour pouvoir tout adresser, il fallait installer des drivers sur sa machine. Et bien sûr, il y avait plusieurs drivers différents avec des API complètement différentes, les applis qui avaient besoin de RAM devaient donc toutes les gérer. Et pour pouvoir en profiter, il fallait expliquer à l'utilisateur comment installer ces drivers.
->Et même pour le 1er Mo de RAM, il fallait se faire chier à construire un pointeur sur 20 bits pour pouvoir y accéder, sinon on n'avait accès qu'aux 64 premiers Ko.
->Il fallait gérer 3 marques de cartes son différentes, plus le bipeur de la machine quand l'utilisateur n'en avait aucune, chacune avec ses spécifités et ses limitations. De plus, chaque son devait être sauvegardé en 3 versions différentes, pour avoir la meilleure qualité possible selon la carte de l'utilisateur.
->Rien que le fait de rafraîchir un écran en 320x200 en VGA assez vite était compliqué, car pour être plus rapide, les cartes VGA avaient leur framebuffer répartis sur 4 banques séparées, dans lesquelles il fallait bien sûr écrire à la main
->Pour être optimisées pour la rasterization après un raycast, les sprites étaient stockés dans un format bien particulier. Pour gérer le scaling des sprites en software, pour ne pas avoir à scaler le sprite à la volée, ce qui serait lent, le programme générait au lancement un tas de fonctions de scaling qui retournaient directement les pixels à afficher.
->Et il fallait faire tenir le tout dans une seule disquette de 3 pouces et demi, pour que le jeu puisse être partagé le plus facilement possible :p Donc il a fallu ajouter de la compression à tout ça

J'oublie sûrement plein de trucs, et j'ai peut-être déformé certaines choses (j'avoue que je n'ai moi-même pas tout compris ) J'ai trouvé ça assez motivant à lire, on se dit que si on arrivait à faire tout ça à l'époque, avec toutes ces contraintes, on n'a aucune excuse pour ne pas arriver à faire le jeu qu'on veut aujourd'hui. Et à tous ceux qui fuient le C/C++ parce que "il faut gérer la mémoire"... Au moins aujourd'hui, on peut pointer où on veut dans la RAM sans avoir d'abord à créer un gestionnaire de mémoire pendant 3 semaines :p