Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Responsable 2D/3D/Jeux

    [Livre] Game Engine Black Book: Wolfenstein 3D
    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]



    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  2. #2
    Membre confirmé
    Autres livres & Doom
    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 !

  3. #3
    Responsable 2D/3D/Jeux

    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).
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  4. #4
    Membre confirmé
    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.

  5. #5
    Expert éminent sénior
    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.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  6. #6
    Expert éminent
    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é ).

  7. #7
    Expert éminent sénior
    Citation Envoyé par Kannagi Voir le message
    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
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  8. #8
    Membre extrêmement actif
    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.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  9. #9
    Expert éminent sénior
    Citation Envoyé par hotcryx Voir le message
    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.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  10. #10
    Membre éprouvé
    Citation Envoyé par Paul TOTH Voir le message
    ...ç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

###raw>template_hook.ano_emploi###