Quelle ne fut pas ma surprise de découvrir que Elite etait sorti sur NES. Et c’est pas du homebrew, c’est une vrai sortie officiel (uniquement en PAL) en 1991 et codé par les 2 codeurs (Bell et Braben) du Elite originel. La seule version console . Décidément la NES a vraiment récolté tous les classiques même les plus improbables en plus d’avoir fait naître des IP historiques. Cette version est meme plutot fidèle aux versions micro de l’époque (avec une interface modifié pour etre utilisé au pad et enrichie graphiquement ). Et en plus de ca cette version propose le choix du langage et le français. Si vous n’aviez jamais joué a Elite (comme moi) c’est plutot une bonne occasion.
Mais ca veut dire surtout que la NES a donc des jeux 3D!! Sachant a quelle point la machine n’est pas vraiment adapté pour cela c’est évidemment cette aspect qui m’a interpellé dans cette découverte. Elite c’est de la 3D wireframe avec du back-face culling (les polygones retournés sont éliminés pour éviter de tracer la face arrière des objets en transparence et gagner en lisibilité). Evidemment le framerate est relativement bas. Ca peut monter potentiellement a 25 fps mais ca tourne plutot entre 4 et 12 fps ce qui n’a rien de surprenant. J’ai fais un script qui permet de calculer et afficher le framerate interne du jeu (indépendamment du framerate de l’emulation ou de l’affichage) comme vous pouvez voir sur les gifs.
La NES doit évidemment tracer toute la 3D dans des tuiles (y a pas de framebuffer a proprement parler) et en software avec son CPU. Une etape qui se fait dans un buffer en RAM. Un buffer qui n’est pas dans la RAM principale (trop petite) mais utilise 20% (un peu moins de 2Ko) de la mémoire dans la cartouche qui sert aux sauvegardes. C’est l’avantage des jeux NES qui proposent des sauvegardent, la RAM (combiné a une pile) utilisé a cette effet peut servir aussi d’extension de la RAM console. On fait d’une pierre deux coup.
Mais une fois que toutes ces tuiles qui composent l’image 3D ont été construite par le CPU en RAM il faut déplacer ce buffer (C’est a dire ce tileset) vers la VRAM pour pouvoir l’afficher. Une tache lourde pour la NES car c’est une tache qui ne peut etre fait que pendant le court instant du Vblank... Sauf que sur les consoles PAL le Vblank est bien plus long (+350%) ce qui simplifie grandement le probleme et qui nous donne probablement une réponse sur l’absence de version NTSC. Un vrai jeu codé pour les NES PAL en quelque sorte. D'ailleurs si vous switcher en 60hz pour simuler une NES NTSC sur l'émulateur le jeu va complètement glitcher.
Reste ensuite le probléme du double buffering en VRAM car il faut pouvoir transférer la prochaine image en VRAM pendant que la précédente est en cours d’affichage donc il faut 2 buffers (Ca veut dire ici doubler le tileset et la tilemap). La NES est prévu pour avoir 2 tilemap en VRAM mais par contre doubler le tileset ca pose probleme d’autant que l’interface utilise déjà beaucoup de tuiles. La solution a été de stocker 2 tuiles dans une meme tuile en utilisant indépendamment chacun des 2 bitplans qu’utilise la NES (sur NES les pixels utilisent 2 bits et les tuiles ont donc 2 bitplan) . On transforme ainsi les tuiles 4 couleurs (2 bpp) de la NES en 2 tuiles monochrome (1bpp). Ca consiste donc a superposer 2 motifs sur une meme tuile mais en jouant avec la palette pour n’en faire apparaître qu’un a l’ecran en traçant l’autre en noir sur fond noir pour le rendre invisible.
J’ai fais un script qui permet de faire apparaître ce qu’on nous cache a l’ecran, les lignes sombres correspondent en réalité a des lignes normalement affiché en noir pour etre caché et qui nous montre la prochaine image en train d’etre transférer avant d'être affiché.
Si les lignes sombrent semble en vrac c’est juste parce que ces tuiles du second buffer nécessite d’etre associé aussi a une seconde tilemap pour etre remis dans le bon ordre ce qui ne se fait qu’au moment de switcher l’affichage.
La conséquence de cette astuce c’est que la partie 3D est donc forcement monochrome. Heureusement égayé par l’interface plus coloré et par les etoiles qui sont ici des sprites et donc géré comme un layer indépendant même si calculé en 3D aussi.
Cette methode de superposer 2 motifs distinct dans une seule tuile en jouant avec les bitplans et les palettes n’est pas si rare. C’etait souvent utilisé pour les polices de caractères qui se contente tres bien du monochrome ce qui permettait alors de stocker 2 polices differentes en une seule. Notamment les jeux japonais donc les polices peuvent etre lourdent et occuper une grande partie du tileset de la NES. On a ca par exemple dans le premier Dragon Quest.
C’est aussi quelque chose qui a été utilisé par exemple dans Sonic 3D Blast sur Megadrive. Le logo Sega d’introduction ainsi que le game over sont des séquences vidéo full screen a 30fps ce qui n’est normalement pas vraiment possible. En réalité ce sont des vidéo en 7.5 fps mais chaque image contient en fait 4 images monochrome 1bpp superposé (la Megadrive c’est du 4bpp, 4 bit par pixel) et suffit en suite de jouer avec la palette pour les faire apparaître.
À noter que le programmeur de Sonic 3D Blast, Jon Burton, a fait une courte vidéo pour expliquer la technique derrière le logo : <br />
<br />
https://www.youtube.com/watch?v=c-aQvP7CUAI