Developpez.com - Rubrique 2D-3D-Jeux

Le Club des Développeurs et IT Pro

Comment DOOM et Wolfenstein affichaient leurs graphismes : apprendre les bases du ray-casting

Un tutoriel de Guy Grave

Le 2016-09-02 17:16:48, par LittleWhite, Responsable 2D/3D/Jeux
Bonjour à tous,

J'ai le plaisir de vous proposer un tutoriel écrit par Guy Grave, alias mewtow, sur le fonctionnement du rendu graphique des premiers jeux "3D" tels que DOOM et Wolfenstein.

Bonne lecture.

Lire le tutoriel
Voir les autres cours et tutoriels de la rubrique Hardware
  Discussion forum
6 commentaires
  • Kikuts
    Membre éprouvé
    Super intéressant.

    J'avais déjà suivit un tuto pour faire ça en mode brain off. Je ne faisais que suivre les instructions sans réfléchir.$*

    Cet article m'a fait comprendre beaucoup plus de choses. C'est passionnant à lire car très accessible

    Ceux qui ont pondu ces algos et pensé à tout ce joli bordel doivent être sacrément intelligent car même si les formules employées ne sont pas folles, il fallait y penser.

    Merci beaucoup !
  • richarno
    Membre à l'essai
    Merci pour cet article très intéressant.

    Un fait amusant est de comprendre l'historique d'une optimisation particulière.
    A l'époque de Doom, les cartes graphiques n'offraient que des optimisations hardwares basiques et 2D : BitBlt (copies de rectangles), masquages ou gestion du pointeur de la souris. Pour le calcul en temps réel des graphiques le CPU principal du PC était le seul moyen de faire le rendu graphique en mode 3D (2D et demi on disait à l'époque ) et il était fortement mis à contribution.

    On voit dans l'article de Guy Grave (traduit par LittleWhite, merci encore) l'importance du calcul de l'inverse de la racine carrée pour savoir positionner les objets à l'écran, mais ce calcul, s'il était fait en flottants, aurait été beaucoup trop lent pour permettre l'affichage temps réel.
    Et l'astuce de génie a été de trouver un algorithme entier (sans flottants) qui réalise cette opération de manière très rapide (InvSqrt). Je ne reviens pas sur le détail de cet algorithme (qui tient du génie), mais il est intéressant qu'une étude a été faite en 2012 sur l'algorithme originel, et que la rétro-ingéniérie a permis de découvrir un petit bug dans une constante de l'algorithme. Ce qui explique pourquoi sur Doom, on voyait parfois une raie noire verticale.

    L'article s'appelle "A Brief History of InvSqrt", en anglais et très intéressant.

    Bonne lecture.
  • LittleWhite
    Responsable 2D/3D/Jeux
    Je tiens à préciser que je ne suis pas traducteur, simplement, j'ai (avec l'accord du génialissime Guy Grave) publié l'article sur Developpez.com.
  • Kannagi
    Expert éminent sénior
    A croire que y'avait beaucoup de génie a l'époque
    La 3d existait depuis un moment (meme sur Atari ST), je rappel que chez nous on a eu le droit a un excellent Alone in the Dark sorti en 1992 est programmer en full ASM (donc 1 ans avant doom) .
    Pour moi ce jeu est un vrai précurseur autant la technique de Doom a vite était oublier après , autant la technique de Alone in the Dark a perduré ( perso en 3d et Background Precalculer comme Resident Evil ou Final Fantasy).

    A la même époque au Japon sortais Ridge Racer en 1993 (sur une machine tournant sur du 240,000 polygons/second) , les ingénieurs ont fait du bon boulot
  • guitz
    Membre éclairé
    Envoyé par richarno
    Merci pour cet article très intéressant.

    Un fait amusant est de comprendre l'historique d'une optimisation particulière.
    A l'époque de Doom, les cartes graphiques n'offraient que des optimisations hardwares basiques et 2D : BitBlt (copies de rectangles), masquages ou gestion du pointeur de la souris. Pour le calcul en temps réel des graphiques le CPU principal du PC était le seul moyen de faire le rendu graphique en mode 3D (2D et demi on disait à l'époque ) et il était fortement mis à contribution.

    On voit dans l'article de Guy Grave (traduit par LittleWhite, merci encore) l'importance du calcul de l'inverse de la racine carrée pour savoir positionner les objets à l'écran, mais ce calcul, s'il était fait en flottants, aurait été beaucoup trop lent pour permettre l'affichage temps réel.
    Et l'astuce de génie a été de trouver un algorithme entier (sans flottants) qui réalise cette opération de manière très rapide (InvSqrt). Je ne reviens pas sur le détail de cet algorithme (qui tient du génie), mais il est intéressant qu'une étude a été faite en 2012 sur l'algorithme originel, et que la rétro-ingéniérie a permis de découvrir un petit bug dans une constante de l'algorithme. Ce qui explique pourquoi sur Doom, on voyait parfois une raie noire verticale.

    L'article s'appelle "A Brief History of InvSqrt", en anglais et très intéressant.

    Bonne lecture.
    En fait cet Algorithme revient au Grand Génie Isaac Newton, mais là où John Carmack a fait très fort c'est de trouver cette constante qui réduit les étapes de cet algorithme
  • dancingmad
    Membre averti
    Pour aller plus loin, je recommande le livre "Zen of Graphics Programming" de Michael Abrash, qui explique en détail les algos de Doom et comment il a fait évoluer la technique jusqu'à Quake. C'est un peu rebutant au début (beaucoup d'assembleur mais on peut passer), mais super intéressant !