1 points par GN⁺ 2025-03-05 | 1 commentaires | Partager sur WhatsApp

Pourquoi FastDOOM est rapide

  • Durant l’hiver 2024, en restaurant un IBM PS/1 486-DX2 66Mhz, l’auteur a été amené à tester FastDOOM. Le DOOM d’origine tournait à 21,5 fps, tandis que FastDOOM atteignait 30 fps, soit 30 % plus vite.

Contexte historique

  • DOOM a été développé sur une NeXT Workstation, et les E/S DOS ont été écrites chez id Software. En 1997, le code source n’a pas été publié à cause d’une bibliothèque audio appelée DMX ; à la place, la version Linux a été rendue publique. Par la suite, la communauté a restauré la version DOS via PCDOOM v2.

Vue d’ensemble des gains de performances

  • Victor "Viti95" Nieto a consacré beaucoup d’efforts à améliorer les performances de FastDOOM. L’auteur a téléchargé 52 versions de FastDOOM et comparé leurs performances afin d’analyser les améliorations.

Archéologie Git

  • Viti95 a montré une excellente maîtrise de la gestion dans git : chaque commit accomplissait une seule tâche et chaque version était taguée. L’historique git de FastDOOM comprend 3 042 commits, ce qui a permis de benchmarker chaque fonctionnalité.

FastDOOM v0.1

  • Cette version comprend 220 commits, et l’optimisation principale consistait à réduire le rendu de la barre d’état, ce qui a apporté un gain de 2 fps.

FastDOOM v0.6

  • Dans cette version de 33 commits, des optimisations ont été réalisées, comme l’élimination de rendus inutiles et la suppression de l’indirection sur le pointeur du joueur.

FastDOOM v0.8

  • Cette version, qui comprend 282 commits, se concentrait sur le renderer en mode texte et incluait plusieurs optimisations.

FastDOOM v0.9.2

  • Cette version de 110 commits introduisait une optimisation de la comparaison skyflatnum ainsi qu’une optimisation de R_DrawColumn.

FastDOOM v0.9.7

  • Cette version de 293 commits incluait des tests de modifications x86 ASM et des optimisations de sélection du CPU.

Mode 13h contre mode Y

  • FastDOOM a tenté des optimisations adaptées à différents CPU et bus vidéo. Le mode 13h copie les données de la RAM vers la VRAM, tandis que le mode Y écrit directement dans la VRAM. Les performances de chaque mode varient selon la vitesse du CPU et du bus.

Optimisations supplémentaires

  • Des optimisations ont été tentées avec les flags spécifiques au processeur d’OpenWatcom, mais la version 386 s’exécutait toujours plus vite. FastDOOM cherche à passer du compilateur OpenWatcom v2 à DJGPP (GCC) afin de générer un code plus rapide.

Impression générale

  • Grâce à l’excellent travail de Victor Nieto, FastDOOM affiche des performances remarquables au fil de 3 000 optimisations. En réutilisant les améliorations existantes et en introduisant de nouvelles optimisations, le projet a attiré beaucoup d’attention.

1 commentaires

 
GN⁺ 2025-03-05
Commentaire Hacker News
  • Le build 36 du patch MPV v0.1 a grandement contribué aux gains de performances. L’« optimisation Cripy » a apporté un gain de 2 fps en transformant le rendu du pourcentage de la barre d’état en noop lorsqu’il n’avait pas changé. Cela paraissait difficile à croire au début, mais en appliquant le patch à PCDOOMv2, l’énorme gain de vitesse a bien été confirmé

    • Un goulet d’étranglement peut se trouver à un endroit inattendu, et il faut profiler et mesurer pour le découvrir
    • La structure de Doom peut sembler relativement claire pour les experts, mais en général, ce n’est pas un endroit où l’on s’attendrait à trouver un goulet d’étranglement
  • Pour comprendre l’évolution des performances, les 52 releases de fastDOOM, PCDOOMv2 et du DOOM.EXE d’origine ont été téléchargées, puis un RUN.BAT a été créé pour exécuter -timedemo demo1 sur toutes les versions

    • Cela a permis de découvrir que l’option de stockage via le réseau existait déjà à l’époque grâce à NETDRIVE de mTCP
    • NetDrive est un pilote de périphérique DOS qui permet d’accéder, comme à un périphérique local, à des images disque distantes hébergées sur un autre ordinateur
  • Le fil GitHub avec Ken Silverman est très instructif. Il est impressionnant de voir l’auteur de FastDOOM et Ken discuter de l’efficacité des registres 486 et des cycles d’horloge

    • C’est réjouissant de voir que les améliorations de performances de Doom se poursuivent encore
  • L’« IBM PS/1 486-DX2 66Mhz, "Mini-Tower", modèle 2168 » était l’ordinateur dont on rêvait adolescent sans jamais pouvoir l’avoir

    • En 1992, c’était déjà le quatrième PC assemblé soi-même qui était utilisé
    • Le salon informatique KCS était une excellente ressource pour acheter des composants, assembler un PC, l’utiliser, le revendre, puis recommencer avec de nouveaux composants
    • Fin 1992, un 486-DX3 100 et un coprocesseur mathématique ULSI 487 étaient utilisés
    • On pouvait affirmer posséder le PC le plus rapide du campus à l’époque
    • Les études portaient sur les sciences de l’environnement, mais la carrière a finalement été liée à l’informatique
  • Les modes vidéo uniques de FastDOOM n’ont pas été mentionnés

    • Mode texte IBM MDA
    • EGA & Plantronics ColorPlus
    • CGA bleu et rose classique
    • CGA, hack 320x200x16 « ANSI from Hell »
    • Hercules
    • La plupart offrent des performances inférieures au VGA
  • À l’époque, le 486DX50 aurait été préféré au DX2-66. L’interface de bus à 50 MHz était meilleure que celle à 33 MHz

  • Dans le document, le nom de famille de John Carmack est mal orthographié en « Carnmack »

  • L’expression « il fallait prendre de l’ibuprofène pour jouer, mais j’ai découvert fastDOOM » n’est pas comprise

  • Pour améliorer la lisibilité, on pourrait envisager d’ajouter une police system UI au HTML. Les blocs de code resteraient affichés dans une police à chasse fixe. Les polices à chasse fixe ne conviennent pas à la prose

  • Le sens de l’expression « il fallait prendre de l’ibuprofène pour jouer, mais j’ai découvert fastDOOM » n’est pas clair