Tu connais le mythe : la Neo Geo, la Rolls des consoles 16-bit, capable d'afficher des sprites géants et des jeux d'arcade parfaits. Alors pourquoi elle n'a jamais eu son Doom ? Ce n'est pas une question de puissance brute, mais d'architecture. Les deux ne parlent tout simplement pas le même langage graphique.
Une bête d'arcade pensée pour la 2D
La Neo Geo a été conçue exclusivement pour gérer de la 2D à base de sprites stockés sur cartouche. Son processeur principal, un Motorola 68000 cadencé à 12 MHz, est plus rapide que celui de la Mega Drive, mais il ne dessine jamais directement l'image.

Le principe est rigide : le CPU écrit simplement des numéros de tuiles, des positions et des valeurs de scaling dans la VRAM, puis laisse le processeur vidéo aller chercher les bons sprites dans la ROM graphique pour les afficher.
Le système ne possède ni framebuffer ni bitplanes façon Amiga qui permettraient de dessiner librement des pixels n'importe où sur l'écran. Même un moteur Doom entièrement calculé en logiciel n'aurait donc aucun moyen direct d'afficher son résultat à l'écran.
Il y a un autre mur : cette ROM graphique n'est même pas adressable par le bus du 68000. Impossible pour le CPU d'échantillonner des textures ou de relire des pixels de sprites pour les retravailler. Pour la mémoire de travail, c'est tout aussi serré : 64 Ko de RAM pour le 68000, 2 Ko pour le Z80 qui gère le son, et pas de DMA pour déplacer rapidement des blocs de données.
En clair, la Neo Geo est excellente pour empiler des décors 2D prêts à l'avance. Elle est incapable de peindre une image pixel par pixel à chaque frame.
Ce que Doom exige vraiment
Doom fait exactement l'inverse. Le jeu original affiche du 320x200 en 256 couleurs, avec un accès au framebuffer dans un mode planaire entrelacé proche du Mode X. Il n'utilise que 200 lignes au lieu de 240 pour mettre à jour moins de pixels et aller plus vite, et il jongle entre trois pages d'affichage, comme le décrit le site fabiensanglard.net.
Concrètement, le moteur a besoin de trois choses que la Neo Geo ne lui donne pas :
- écrire librement dans un framebuffer en VRAM ;
- lire ses textures murales, sols, plafonds et sprites à tout moment pour les plaquer sur les murs ;
- garder assez de RAM pour le triple buffering et les calculs de visibilité.
Sur Neo Geo, tu peux calculer tout ce que tu veux avec le 68000, tu restes bloqué au moment de l'afficher : pas de pixels libres, pas d'accès aux textures en ROM, pas assez de RAM rapide.
Le raycasting en sprites ne fait pas un Doom
Des bidouilleurs ont essayé de contourner le problème avec du raycasting détourné : afficher des couloirs en 3D en étirant des bandes verticales de sprites.
Le résultat montre la limite. Le raycaster simple et non optimisé du vidéaste MVG tourne à seulement huit images par seconde en émulation, sans ennemis ni logique de jeu. Et même optimisé, ce système resterait largement insuffisant pour les éléments typiques de Doom comme les plateformes surélevées, les escaliers, les ascenseurs, les murs et plafonds texturés.
Pour MVG, la seule solution réaliste pour faire tourner un vrai Doom sur cartouche Neo Geo serait d'ajouter du matériel de calcul supplémentaire dans la cartouche, comme la puce Super FX2 qui a rendu possible le portage limité sur SNES.
Le projet homebrew DoomGeo le confirme à sa manière. Comme l'explique son auteur sabino, ce n'est pas un portage classique du code source avec framebuffer. Les outils lisent les données WAD au format Doom hors ligne et convertissent la carte et les assets en structures compatibles Neo Geo. Ensuite, le programme sur 68000 anime la scène en mettant à jour des blocs de contrôle de sprites plutôt qu'en dessinant des pixels, pour afficher des bandes étirées.
Ça donne une vraie sensation de FPS sur Neo Geo, mais ce n'est pas Doom : c'est une adaptation qui triche intelligemment avec la logique sprite de la machine.
La Neo Geo n'a pas raté Doom par manque de puissance ou d'envie : sa logique arcade 2D, à base de sprites en ROM et sans dessin libre, reste incompatible avec un moteur qui doit peindre chaque pixel et jongler avec ses textures.