15 Décembre 2023
Part 1: Les Apports du Mega-CD
Part 2: Les Downgrades du Mega-CD
Il y a quelques années j’ai écrit un billet sur le CD-ROM PC-Engine. Les extensions CD-ROM étant naturellement considérées comme des upgrades (multiplier par 1000 la capacité des jeux semblait inespérée), j’essayais d’expliquer en quoi c’était aussi parfois un downgrade. Je vous invite à le lire à l’occasion: PC ENGINE CD-ROM, UPGRADE OU DOWNGRADE?
Il se trouve qu’on peut faire plus ou moins ce constat avec le Mega-CD de la Megadrive mais pour des raisons techniques très différentes ce qui rend le sujet de nouveau intéressant à traiter. D’autant que ce sont des problématiques qu’on peut aussi associer au Super FX de la SNES, gardez ça en tête.
Donc ce billet est, en partie, dans la continuité de celui sur le CD-ROM PC-Engine. Je vais tenter d’expliquer pourquoi le Mega-CD est, dans certaines circonstances, un downgrade en résolution, palette, framerate et input lag.
Mais ce sera pour la seconde partie. Dans un premier temps, on va profiter de ce billet pour évoquer tout ce qu’apporte le Mega-CD, notamment par rapport au CD-ROM PC-Engine. Puis on terminera par une dernière partie bonus ou je partagerais d’autres analyses de jeux Mega-CD non évoqué dans les précédents chapitres. En effet ce billet est aussi un prétexte pour décortiquer quelques jeux Mega-CD (avec le peu d’outils qu’on a malheureusement pour cette plateforme) donc ne vous étonnez pas si on s’attarde parfois sur les jeux qui servent d’illustration. C’est le but.
Ce ne sera évidemment pas exhaustif, d’autant que je ne suis pas du tout un expert du support. Il existe des experts du Mega-CD et de son catalogue comme pour chaque machine. De vrais passionnés de la machine. Ce n’est pas mon cas. C’est juste guidé par ma curiosité et sensibilité à certaines questions qui m'intéressent et ensuite je fais comme je peux avec le temps que j’ai ^^.
Part 1: Les Apports du Mega-CD
Le Mega-CD débarque manifestement en réaction à la concurrence. Notamment pour réagir au CD-ROM PC-Engine et au mode 7 de la SNES ainsi qu'à son audio full sampling.
Le Mega-CD propose quelque chose de plus ambitieux que le CD-ROM PC-Engine, ou même feu le lecteur CD-ROM Sony de la SNES (très similaire au Super CD-ROM de la PC-Engine). C’est le moment d’essayer d’entrer dans les entrailles du Mega-CD.
Le lecteur CD-ROM de la PC-Engine est un simple lecteur qui a pour fonction de proposer beaucoup de stockage pour les jeux et des track CD audio, guère plus. Entre autres, il n’est pas vraiment conçu pour proposer de la vidéo par exemple (mais rappelons-le, c’est 3 ans avant le Mega-CD!).
A l’inverse, le Mega-CD est un addon qui embarque un système complet, en parallèle de la Megadrive, avec un gros CPU 68000, plus véloce encore que celui de la NeoGeo, accompagné d’un custom chip qui ajoute diverses fonctions hardware, ainsi qu’une architecture mémoire complexe en plusieurs blocs pour paralléliser au mieux toutes les tâches.
Tout ceci, combiné au DMA de la Megadrive (ses fonctions de transfert mémoire), permet non seulement de faire de la vidéo fullscreen (même si de faible qualité) mais aussi de faire tourner un jeu en parallèle car le Mega-CD peut traiter la vidéo de manière indépendante sans déranger la Megadrive (si ce n’est pour le transfert de l’image).
Ça marque déjà une nette différence avec le CD-ROM de la PC-Engine.
Faire de la vidéo sur ce dernier est une gageure. Il faut tout faire avec le CPU de la PC-Engine. Ce qui pousse à limiter l’usage de vidéo à une petite portion de l’image ou, bien plus souvent, à simuler de la vidéo en construisant des cut-scène avec des scrolling de plan et des sprites animés. Alors vouloir, en plus, faire tourner un jeu en parallèle de la vidéo devient un vrai défi.
Sur la fin de vie de la PC-Engine, le talent et l'ingéniosité des programmeurs ont permis des miracles (HuVideo) en contournant les fonctions du Bios. Mais, clairement, le CD-ROM PC-engine n’avait pas comme objectif initial de proposer de la vidéo contrairement au Mega-CD dont la conception visait, entre autres, les jeux FMV et au-delà.
rgical Strike Mega-CD
Pour illustrer cela je ne vais pas m’attarder sur les nombreux jeux FMV Mega-CD. Il y en a un certain nombre plutôt réussi qui amenait un peu de fraîcheur dans le paysage vidéoludique. Ca pouvait être parfois créatif et original d’une certaine manière. Les Surgical Strike, NovaStorm, Fahrenheit, Road Avenger, Night Trap… plusieurs dizaines de jeux de ce type. De quoi combler tous ceux qui, à cette époque, avaient très envie d'expérimenter ce genre encore nouveau. Sur ce point, le Mega-CD a parfaitement rempli son rôle. Ça a mal vieilli mais c’est tout de même un moment marquant de l’histoire du jeu vidéo.
Je vais plutôt m'arrêter sur quelques exemples de jeux qui ont mixé vidéo + jeu 2D classique par dessus. Quelque chose qui représente encore mieux les capacités du Mega-CD.
Bram Strocker Dracula est une sorte de Beat'em up qui utilise astucieusement une vidéo pour décors. En lieu et place d’un simple scrolling de plan, on a une vidéo dont l'exécution est indexée sur le déplacement du joueur pour donner un effet 3D complexe grâce à de la CGI. En parallèle, la Megadrive ajoute par dessus un vrai jeu 2D classique parfaitement réactif à 60 fps (même si plutôt médiocre dans cet exemple).
Un background vidéo dans Bram Strocker Dracula
Un autre exemple d’usage de vidéo in-game dans un jeu 2D classique.
Il s'agit de l’avant dernier boss de Puggsy, un platformer 2D. Un boss unique à cette version Mega-CD qui prend la forme d’une vidéo en interaction avec le joueur. Une autre combinaison de vidéo + jeux 2D classique à 60 fps sans lag.
Un boss sous forme de vidéo dans Puggsy CD
Silpheed, remastering d’un jeu PC-88, est probablement l’un des exemples les plus impressionnants techniquement.
En plus de proposer un vrai shmup 60 fps sans lag et tout ce que ça implique comme charge (c’est la Megadrive qui s’occupe de cette partie à priori), on profite d’un background en vidéo quasi fullscreen, lossless (sans artefact de compression) et 15 fps (le max que l’on trouve en vidéo Mega-CD).
Des caractéristiques élevées pour de la vidéo Mega-CD, surtout in-game, grâce à une compression astucieuse qui profite à la fois du format tilemap de l’affichage Megadrive combiné à une compression RLE et l’usage d’une fonction du custom chip plutôt destiné à la décompression de Kanji. Le rendu 3D flat simplifiant la compression vidéo tout en permettant de se contenter d’une seule palette 15 couleurs. Ca fonctionne clairement moins bien quand ce n’est plus le cas (cf. stage 10 et son flux vidéo CGI au framerate divisé par 2).
Un flux vidéo avec lequel le joueur et ses bullets peuvent occasionnellement interagir au travers de collisions (hitbox intégré au flux).
Silpheed, très spectaculaire
On pourrait s'arrêter là mais non. Le jeu se permet le luxe d’avoir des sprites (pour le joueur et les ennemis) rendus en 3D flat temps réel par le CPU du Mega-CD (qui s’occupe déjà de décompresser la vidéo). Ensuite encapsulé dans des sprites hardware de la Megadrive. Ça permet d’avoir des sprites très bien animés et avec de la perspective afin de s'intégrer au mieux dans la scène vidéo qui, elle même, mime de la 3D flat.
Un mélange de vidéo et de 3D temps réel qui rappelle la technologie de Galaxian 3 Arcade mais avec un type de caméra et un contrôle des ennemis qui permet un usage beaucoup plus modéré de la 3D temps réel.
Silpheed est quasiment l’unique jeu Mega-CD à faire de la 3D temps réel avec Racing Aces je crois. Il y en a encore moins que sur Megadrive. Une 3D certainement allégé en calcule par l’absence de contrôle sur la caméra mais une 3D temps réel tout de même.
Le traitement des sprites est particulièrement astucieux. L'update 3D des sprites par le Mega-CD se fait à seulement 15 fps, suffisant pour avoir une bonne animation, mais n'empêche pas pour autant la Megadrive de déplacer ces sprites à 60 fps, de son côté, comme des sprites 2D d’un shmup classique, d’une façon parfaitement fluide et réactive.
C’est un parfait usage de toutes les ressources combinées du Mega-CD et de la Megadrive (à l’exception des fonctions de scaling/rotation absentes ici). Quelque chose d’impossible à reproduire sur le CD-ROM PC-Engine ou la SNES.
Un mélange de vidéo et de 3D temps réel dans Silpheed
C’est l’autre gros morceau du Mega-CD. Celui-ci ne contient pas qu’un gros CPU couplé à une architecture mémoire complexe, mais aussi un custom chip conçu par Sega. Ce custom chip aura pour principale fonction d'être en quelque sorte le mode 7 de la Megadrive.
Dans un interview de Sega 16, Mark Cerny évoque l’embarras de Sega face au mode 7. Ils savaient que c’était quelque chose d’impactant qu’ils ne pouvaient pas reproduire sur Megadrive. Mark Cerny: “...Nintendo released their SNES, which had a “mode 7” that could be used to create all sorts of effects: rotating backgrounds, ground planes, and so on. It was a difficult time, as we had a huge head start on Nintendo, but our games simply couldn’t create the kinds of effects that the Nintendo games had.”
Le Mega-CD a clairement dans ses objectifs de répondre à cette problématique.
Ce custom chip n’est pas un chip graphique à proprement parler. On pourrait simplifier en disant que c’est un chip pour faire du scaling et rotation mais c’est pas tout à fait vrai non plus. Ce custom chip va remplir divers fonctions basiques qui ne peuvent pas l'être par les autres chip standard. Notamment il va arbitrer les communications entre les différents bus et faire aussi office de mapper. Et il a une fonction de “conversion de coordonnée” qui est celle qui nous intéresse ici pour la partie graphique.
C’est une fonction qui va aider pour le scaling et les rotations. Je dis bien “aider” car le custom chip en lui même n’est pas capable de scale/rotate tout seul. Il est plus rudimentaire que cela et va s’occuper de cette tâche uniquement dans sa dimension horizontale. Son champ d’action se limite au balayage d’une ligne sur laquelle il va effectivement appliquer un scaling/rotation par simple incrémentation de valeur prédéfinie tout en adaptant ces coordonnées à l'espace un peu complexe du set de tuile qui compose les objets graphiques.
Mais c’est bien le CPU du Mega-CD qui a pour tâche de calculer et fournir ces valeurs (les incréments et origines) nécessaires pour chaque ligne de l’objet à scaler. Ceci prend la forme d’une table (vector table) préparé par le CPU.
Donc une partie du boulot revient au CPU du Mega-CD. Notamment la dimension verticale. On peut faire l’analogie avec l’Atari 2600 dont le chip graphique a une autonomie d'une seule ligne. C’est seulement en le combinant avec le CPU, qui va l’alimenter pour chaque scanline, qu’on forme un vrai chip graphique 2D. Pour le Mega-CD c'est la même chose. C’est la combinaison de son CPU et du custom chip qui forme alors un chip de scaling/rotation qui va permettre de reproduire le mode 7 de la SNES… mais pas tout à fait.
Le combo custom chip + cpu permet effectivement au Mega-CD de scaler et rotationner un plan entier de background comme le ferait le mode 7 de la SNES. De plus, comme je l’ai expliqué, cette fonction prend la forme d’une table de paramètre pour chaque ligne ce qui permet alors de mimer aussi l’effet de perspective d’un F-Zero ou Mario Kart en faisant évoluer les valeurs de scaling pour chaque ligne d’écran comme le ferait une SNES (grâce à sa table HDMA).
Cet effet “F-zero” est même spécifiquement mis en exergue dans la documentation Sega de 1991 pour les développeurs. C'est dire à quel point le mode 7 de la SNES était particulièrement ciblé par Sega.
Donc on a bien une fonction conçue pour reproduire le mode 7.
Malgré tout, même en couplant le custom chip et le cpu du Mega-CD, on peine à obtenir ne serait ce qu’un tiers des performances du mode 7 qui est une fonction hardware complète et câblé au plus profond du PPU de la SNES pour produire cet effet au raster de façon très efficace.
Le fillrate du mode 7 de la SNES, appliqué sur un plan fullscreen de 224 lignes, atteint 4,6 Megapixels par seconde (encore plus en 240p). L’équivalent sur Mega-CD va plutôt culminer à environ 1,5 Mpixels/s (1,84 Mpixels/s théorique auquel il faut retrancher le temps de transfert de l'image vers la VRAM Megadrive et celui des vector tables vers la "VRAM" Mega-CD qui, tous les 2, nécessitent d’interrompre le travail du custom chip).
On pourrait trouver ça dommage mais il existe de toute façon un autre goulot d'étranglement (le transfert DMA de la Megadrive qu’on évoquera longuement dans la partie “downgrade” du billet) qui briderait, quoi qu'il arrive, à environ 15 fps un hypothétique mode 7 fullscreen. C’est un peu comme si le Mega-CD était calibré (fillrate et DMA) pour faire du mode 7 mais à 15 fps là où celui de la SNES est fondamentalement et intrinsèquement conçu pour tourner en fullscreen 60 fps.
D’un point de vue performance pure, le Mega-CD ne peut donc pas rivaliser avec le mode 7 de la SNES. Sans compter que le mode 7 SNES c’est du 8 bit par pixel (256 couleurs) contre 4 bpp (16 couleurs) pour le MCD. Un facteur x2 supplémentaire dans les performances brutes.
Ca peut sembler décevant, et ça l'est un peu quand même, mais cette fonction du Mega-CD à d’autres atouts que n’a pas le mode 7 de la SNES.
Le mode 7 SNES est efficace mais la contrepartie est d'être figé dans le métal et très rigide. Il ne peut traiter qu’un seul gros objet graphique (c’est à dire un unique plan de background et aucun sprite) et la répartition spatiale et temporelle des ressources ne peut pas être modifiée. Le scaling du Mega-CD est beaucoup plus flexible, d’autant plus qu’il est semi-hardware, semi-software.
Déjà il s'exécute dans un framebuffer, pas au raster, ce qui ouvre à plein d’autres possibilités. On peut utiliser le scaling/rotation sur plusieurs passes successives et donc sur plusieurs objets/blocs distincts qu’on superpose dans le framebuffer autant qu’on le souhaite. Ce qui veut dire la possibilité d'appliquer le scaling sur des “sprites”, chose qui manque cruellement à la SNES pour construire des scènes plus complexes.
On peut aussi répartir et concentrer les ressources à sa guise sur une plus petite portion d’image (répartition spatiale) ou sur plusieurs frames (répartition temporel). Par exemple, en visant les 15 fps on obtient 4x plus de ressources par frames qu’en 60 fps ce qui permet ainsi de manipuler suffisamment d’objets graphiques pour construire une scène intéressante même avec peu de ressource.
On peut faire une nouvelle analogie avec une autre console d’Atari, la Lynx, qui construit aussi son image en superposant des blocs graphiques dans un framebuffer. C’est cette approche, non conventionnelle pour une console de l’époque, qui lui a permis d'insérer une fonction hardware de scaling sur ces blocs. En visant une résolution faible et un framerate faible, on peut alors concentrer les ressources pour manipuler suffisamment d’objets. Dans ces conditions, pas besoin d'énormément de ressources pour avoir quelque chose de viable. C’est ce que fait plus ou moins le Mega-CD.
Cette fonction du Mega-CD a aussi d’autres atouts bien concrets comparé au mode 7 SNES. Elle permet de manipuler des objets plus gros que sur SNES, jusqu’a 4096x4096 pixels contre 1024x1024 pour l’unique plan du mode 7 SNES (une contrainte qui a donné naissance à Mario Kart, allez lire mon billet).
Tout en utilisant un set de tuile bien plus large. Sur SNES le set de tuile à disposition du mode 7 est très réduit, seulement 256 tuiles 8x8 pixels et sans flipping (mais en 8 bpp). Sur Mega-CD on est dans une situation bien plus confortable avec au moins 1024 tuiles 16x16 pixels avec flipping (mais en 4bpp), voire encore plus selon la place occupée par les autres buffers. Un confort qui n’est pas superflu si le but est d’afficher de multiples objets qui ont chacun besoin de leur set de tuile.
Finalement on est sur quelque chose de relativement différent du mode 7. Conçu pour mimer le mode 7 mais aussi pour mimer, plus modestement, les Super Scaler arcade de Sega, à condition de viser des résolutions et framerate faible.
L’un des exemples les plus flagrant de référence direct au mode 7 de la SNES et à Mario Kart/F-Zero, on le trouve dans les stages bonus de Sonic CD.
Stage bonus Sonic CD
Malgré un effet qui concentre toutes les ressources (tel que le permet le Mega-CD) dans seulement 93 lignes, le framerate culmine à 20 fps ( et avec beaucoup d’input lag). Mais il est difficile d’obtenir de meilleurs framerates sur Mega-CD. En comparaison, F-Zero c’est un mode 7 qui occupe 176 lignes en 60 fps avec une réactivité maximale.
Mais surtout ici le Mega-CD ne prend même pas en charge le scaling des montgolfières (dont la destruction est l’objectif des stages bonus) ce qui est un peu décevant. A la place on a un scaling entièrement précalculé en VRAM Megadrive. Un effet de scaling pas des plus réussi surtout quand on s’approche (sur les dernières frames la montgolfières rétrécie et glisse dans le coin inférieur). Un manque de cohérence entre distance et scaling qui rend le gameplay très approximatif et qui aurait pu être largement amélioré par le Mega-CD justement (Soul Star en est la démonstration dans une situation très comparable).
Malgré que ce soit un jeu Sega, on peut le dire, ces stages bonus ne sont pas une grande démonstration du Mega-CD. Le game design de ces stages lui-même trahit qu’il y a eu un problème de temps de conception car ça n'a pas beaucoup de sens sur pas mal de point comme si ce n’était pas achevé.
BC Racers est un autre jeu qu’on associe immédiatement à l’imagerie des jeux mode 7 de la SNES. A la différence prêt que dans celui-ci le Mega-CD peut habiller l’environnement avec des “sprites” scalés en temps réel pour donner un peu de volume à la scène. Chose qu’on ne peut pas faire de cette façon sur SNES.
Malheureusement le framerate et l’input lag est particulièrement médiocre mais on aura l’occasion d’y revenir dans les chapitres concernés plus loin.
BC Racers
A côté de ça on trouve aussi divers exemples qui font plutôt penser à des jeux de type “Sega super scaler” comme ces scènes très réussi (256x192, ~15 fps) de snowboard exclusive à la version Mega-CD de Cliffhanger (mais d’une difficulté absurde, très mal réglé).
Des séquences qui poussent au max les capacités du Mega-CD et qu’on ne peut pas reproduire sur SNES.
Séquence spectaculaire de snowboard dans Cliffhanger CD
Ce sont les mêmes développeurs que Batmans Returns dont la version Mega-CD propose aussi ce type de scène (avec les mêmes caractéristiques techniques) qui font partie des plus réussi du Mega-CD.
Ça montre ce qu’on peut obtenir en utilisant au mieux les ressources de scaling du Mega-CD.
Des séquences “super scaler” dans Batmans Returns
Le custom chip a aussi une seconde fonction qui touche aux graphismes et qui mérite quelques mots.
C’est un mode (non cumulable avec le mode “scaling/rotation”, il faut choisir l’un ou l’autre) qui ajoute des commodités. Ça permet au CPU Mega-CD de manipuler individuellement des pixels 4 bit (le format de pixel Megadrive) dans un framebuffer bitmap/chunky avec même une gestion de mask et de priorité pour faire du sprite software par exemple.
De l’autre côté, ce mode permet aussi au CPU Megadrive de voir ce framebuffer comme si c’était juste un gros set de tuile 8x8 qui est le format d’image de la Megadrive (et des consoles au raster).
De simple commodité qui ont pour but de permettre au CPU Mega-CD d'être totalement libre et efficace dans la construction software d’image dans un framebuffer (par exemple faire de la 3D, du raycasting ou certain type de décompression d’image…) tout en rendant ce framebuffer directement compatible avec l’affichage particulier de la Megadrive qui n’a, alors, plus qu'à se servir (c’est à dire à transférer le framebuffer du Mega-CD dans sa VRAM pour afficher le résultat).
Ce sont des fonctions assez basique qui tiennent plutôt du mapper (des fonctions de mapping mémoire) mais qui sont malgré tout très utiles pour offrir une flexibilité maximale. Combiné à une fréquence supérieure, ça permet au CPU du Mega-CD d'être bien plus efficace que celui de la Megadrive pour tout ce qui consiste à produire du graphisme de façon software.
C’est le genre de fonction qu’on peut d’ailleurs retrouver dans les chips Super FX ou SA-1 des cartouches SNES car ce genre de “system on cartridge” ont les mêmes problématiques que le Mega-CD. On y reviendra dans la 2ème partie.
J’ai peu creusé cette partie donc je vais faire relativement court mais c’est quand même un élément important du Mega-CD qu’il faut évoquer.
Le Mega-CD permet, bien entendu, de streamer des track CD audio. C’est à dire du son de très haute qualité, non compressé, au format PCM 16 bit 44 kHz sur 2 canaux (pour la stéréo) avec un oversampling (interpolation) x8 pour lisser le signal. C’est plus ou moins ce que l’on attend d’un support CD.
Cette simple fonction suffit à séduire beaucoup de joueurs. Mais le Mega-CD ne va pas se contenter de cela.
En effet, il embarque aussi un sound chip (Ricoh, comme dans le System32) qui offre 8 canaux de sampling PCM 8 bit 32 kHz accolé à un buffer RAM de 64 ko qui lui est dédiée pour stocker les samples.
Tous ces canaux PCM supplémentaires s'ajoutent en parallèle du streaming des track CD audio. Streamer des track CDA c’est cool pour la qualité de la musique mais ça bloque le lecteur pour le reste. Ce n’est donc pas toujours possible. On a parfois besoin de lire le CD pour d'autres choses (par exemple pour les FMV). Donc c'est bien d’avoir d'autres alternatives audio comme ici avec ces 8 canaux PCM.
Derrière la présence de tous ces canaux PCM, on devine à nouveau un choix technique en réaction à la SNES. En effet, l’autre élément différenciant majeur qui caractérise la SNES, en plus de son mode 7, c’est son audio entièrement basé sur le sampling qui marquait une rupture franche avec l’audio des précédentes consoles basé sur la synthèse.
Par l'intermédiaire du Mega-CD, Sega avait l’opportunité de répondre à cette autre problématique et ne s’en est donc pas privé.
Le chip audio de la SNES par Ken Kutaragi
On note d’ailleurs pas mal de similitudes avec la partie audio de la SNES aussi composée de 8 canaux de sampling 32 kHz avec 64 ko de buffer RAM comme le Mega-CD.
Malgré tout, le sound chip du Mega-CD est plus rudimentaire, sans aucune fonction avancée a priori. Et notamment il ne manipule rien d’autre que du sample PCM brute, pas d’ADPCM tel que sur SNES (ou tel que l’unique canal sampling qu’on trouve aussi sur le CD-ROM PC-Engine).
Le “AD” de “ADPCM” est là pour indiquer une forme de compression du format PCM (Adaptive Differential). Ça permet à la SNES de manipuler des samples avec une bonne quantification sans qu’ils ne pèsent trop lourd (4 bit et demi par échantillon, décompressé en 16 bit). Les samples du Mega-CD ont une quantification 8 bit sans compression donc occupent presque 2 fois plus de place à fréquence égale (mais sans les défauts de la compression) ce qui rend un peu étroit les 64 Ko de buffer.
Mais rien n'empêche de sacrifier une partie de la RAM CPU du Mega-CD pour élargir virtuellement le buffer sample au prix de quelques manipulations supplémentaires.
La partie audio de la SNES est pilotée par un petit CPU SCP700 à 1 mhz qui lui est entièrement dédié (comme le Z80 de la Megadrive). Dans le Mega-CD, c’est le 68000 qui joue très bien ce rôle de CPU audio.
Je ne l’ai pas précisé jusqu'à maintenant, et je ne le préciserai plus par la suite, mais le CPU du Mega-CD a aussi comme rôle secondaire de servir de CPU audio et de piloter le lecteur CD. Ce qui, pour un gros 68000 à 12,5 mhz, sont des tâches relativement anecdotiques d’autant que le microcontrôleur du lecteur CD et le sound chip des canaux PCM sont en grande partie autonome avec leur propre buffer (il y a même des fonctions DMA pour dispatcher le contenu du buffer CD vers les différent pool de RAM du Mega-CD sans interrompre trop longtemps le 68000).
Pour citer un exemple, le Street of Rage CD (Sega Classics Arcade Collection) profite de ces nouvelles capacités pour améliorer le peu de voice sampling du jeu original.
C’est encore plus flagrant dans Mickey Mania version CD dont les voix et bruitages profitent massivement des canaux PCM du Mega-CD mais aussi du stockage du CD. C’est d’ailleurs ce qui lui permet, au final, de faire mieux que la SNES car le sampling audio ca occupe de la place. Une place malheureusement précieuse sur les cartouches.
Une autre fonction que l’on pourrait attendre d’un lecteur CD-ROM serait de proposer des jeux 2D classiques, tel que ceux qu’on connaît déjà sur Megadrive, mais dans les conditions d’une cartouche de capacité supérieure à tout ce qu’on pouvait avoir à l'époque (jusqu'à 4 Mo pour les plus grosses cartouches Megadrive).
Je ne parle pas des cinématiques, cutscenes ou track audio dont, effectivement, la plupart des jeux CD vont largement bénéficier, mais bien du contenu in-game. Est ce que des jeux Megadrive 2D classiques (qui, de ce fait, n'utilisent pas les capacités “graphiques” du Mega-CD) peuvent réellement en profiter de manière plus directe et concrète?
On l’a vu avec mon billet sur le CD-ROM PC-Engine, pour ce type d’usage, il ne suffit pas d’un CD-ROM. Il faut aussi un gros buffer RAM pour simuler au mieux la ROM d’une grosse cartouche, ce qui a grandement manqué au premier lecteur CD-ROM de la PC-Engine.
Pour rappel, le CD-ROM PC-Engine proposait un buffer RAM de seulement 64 ko (et 256 Ko pour le Super CD-ROM) complété par un buffer sample audio de 64 Ko qui n’est pas accessible par le CPU, comme l’est le buffer RAM, mais peut dépanner occasionnellement pour stocker, de façon transitoire, des data graphiques en sacrifiant l’audio comme c’est le cas dans Monster Lair par exemple (une gymnastique tordu qui témoigne surtout à quel point le buffer RAM était plus que limitant à ce moment là).
Sur Mega-CD, on retrouve aussi un buffer sample audio de 64 Ko mais sans le support des samples compressés donc un peu plus étroit à l'usage.
Ce qui nous intéresse c’est surtout le buffer RAM qui remplace la ROM de la cartouche. Sur ce point, la comparaison avec le CD-ROM PC-Engine est plus difficile car l’architecture mémoire du Mega-CD est plus complexe pour répondre aux fonctions plus avancées qui s'exécutent en parallèle.
On peut résumer en disant qu’il y a 2 buffers RAM qui, potentiellement, sont tous les 2 directement accessibles par le CPU Megadrive (donc comme la ROM d’une cartouche) aussi bien que par le CPU Mega-CD. Mais dans les faits c’est un peu plus encadré.
L’un des 2 buffers RAM a une taille de 512 Ko, plutôt verrouillée pour le CPU Mega-CD. Et un autre de 256 Ko qui, lui, est plutôt destiné au custom chip pour faire les rotation/scaling, faire office de VRAM en quelque sorte et recevoir entre autre le framebuffer, mais aussi servir de tampon intermédiaire pour faire transiter les data entre le Mega-CD et la Megadrive. Un buffer qui peut d'ailleurs lui même se diviser en 2 buffers indépendants de 128 Ko avec chacun leur bus. L’un accessible par le CPU Megadrive pendant que l’autre l’est par le CPU Mega-CD, toujours dans le but de favoriser les tâches en parallèle qui est l’une des forces du Mega-CD.
Avec un peu de gymnastique on peut utiliser tout ça comme une sorte de gros buffer RAM mais c’est pas tout à fait additionnable et comparable.
En simplifiant, on peut estimer que c’est l'équivalent du double d’un Super-CD-ROM (ou du projet PlayStation SNES tel qu'observé sur le prototype qui avaient des capacités similaires au Super CD-ROM) ce qui est tout à fait convenable. Avec, en complément, plus de possibilité de compression grâce au CPU Mega-CD qui est disponible pour s’en occuper gratuitement (au prix d’une frame d’input lag supplémentaire en général).
On est donc pas du tout dans la situation des contraintes du premier CD-ROM PC-Engine évoqué dans mon billet, ce qui n'est pas une surprise 3 ans plus tard. Mais disons que l’idéal, pour alimenter une Megadrive, aurait été un gros buffer unique de 1 Mo je pense, ca aurait été plus confortable. Donc c’est bien mais pas parfait non plus.
Pour ultime comparaison on peut citer aussi l’Arcade Card de la PC-Engine qui ajoutait 2 Mo de buffer en complément des autres buffers déjà présents dans le Super-CD-ROM. Mais ce n’est pas un buffer RAM directement accessible par le CPU PC-Engine tel une ROM. Ça fonctionne plutôt comme le buffer de sample audio. Ce qui n'est pas vraiment un problème si c’est pour y stocker des données graphiques destinées à être chargées en VRAM, la fonction première de cette Arcade Card.
On a aussi l’exemple de la NeoGeo CD avec son énorme buffer RAM de 7 Mo (en réalité 4 Mo graphismes + 2 Mo samples + 1 Mo CPU).
Je vous ai exposé la théorie mais, concrètement, est ce qu’il y a des jeux Mega-CD classiques qui ont bien exploité cette fonction d'énorme cartouche?
Ca profite globalement aux jeux d’aventures, notamment les jeux d’aventures graphiques typés micro tels que Dune, Secret of Monkey Island ou Snatcher qui ont besoin de beaucoup de contenu graphique pour illustrer l’aventure (et qui ne sont pas juste des duplications de blocs). Ce sont des types de jeux plus compliqué à faire sur cartouche.
Dune Mega-CD
Ma curiosité personnelle se porte plutôt sur les jeux d’action 2D classiques (platformer, shmup, BTU…) qui sont le cœur du catalogue console en général et Megadrive en particulier. Est ce qu’ils en profitent in-game?
Le constat est plutôt décevant. Il est difficile de trouver des exemples de jeux Mega-CD d’action 2D classiques dont le contenu ne serait pas possible sur cartouche. La très grande majorité de ces jeux Mega-CD sont des portages de jeux qui existent déjà en cartouche Megadrive quasi à l'identique. Parfois en ajoutant quelques stages ou boss comme dans Puggsy mais rien de très frappant.
Le gain se concentre presque tout le temps sur le son. Au Delà de la musique, augmenter la qualité des bruitages est une façon d’améliorer ce type de jeux in-game mais c’est en partie grâce aux canaux PCM qu'ajoute le Mega-CD, pas seulement son stockage (qui compte tout de même pour cette fonction).
Final Fight Mega-CD
Final Fight CD fait partie de ces jeux Mega-CD qui n'utilisent en rien les capacités “graphiques” de celui-ci (comme quasiment tous les jeux 2D classiques du support car c’est difficilement possible), uniquement son stockage et ses capacités audio.
Et pour son stockage, c’est très discutable car si on regarde plus en détail et qu’on décortique sa track 1 qui contient le file system, on constate que le coeur du jeu tient dans 1708 ko (en réalité moins car sur CD on utilise de la redondance de donnée entre les fichiers pour optimiser les temps d'accès) auquel s’ajoute 633 Ko de sample et 540 Ko pour les cut-scene de début et de fin (+ les track audio bien entendu qui consomme 99,4% des données du jeu).
Donc en réalité c’est un jeu qui tiendrait sur une simple cartouche 2 Mo en faisant des compromis sur la partie samples et cut-scene. Et à l'exception des musiques, il pourrait même potentiellement être meilleur que la version CD avec une cartouche 4 Mo. C’est d'ailleurs ce qui est en train de se dérouler avec le projet Megadrive homebrew Final Fight Ultimate.
Ce n’est pas très surprenant quand on sait que la version arcade elle-même tient intégralement dans 3,3 Mo de ROM malgré des données graphiques qui utilisent une résolution supérieure à la version Megadrive.
Final Fight n’est pas l’exemple que l’on cherche pour démontrer sans ambiguïté l'intérêt du stockage CD sur un jeu 2D classique même si, au final, ça a permis, a minima, de proposer une grosse “cartouche” à moindre coût (et donc plus tôt) pour un résultat plutôt réussi.
On pourrait aussi citer Mortal Kombat dont la version CD ajoute des frames d'animation.
Mortal Kombat CD versus Cartouche
Mais il se trouve que Mortal Kombat 3 sur cartouche Megadrive fait encore mieux et avec 2 fois plus de personnages donc on ne peut pas dire non plus que ce Mortal Kombat CD soit un exemple très pertinent de contenu impossible sur les cartouches de l’époque.
Mortal Kombat 3 sur cartouche Megadrive
D’autant que ce Mortal Kombat CD fait plutôt la démonstration des faiblesses du support CD sur les jeux de versus fighting.
En effet, cette version ajoute des loading incongrus en pleine phase de jeu. Il y en a pour chaque Fatality ou lors des switch d’adversaire sur les combats d'endurance. Mais surtout lors de chaque transformation du boss final ce qui rend la séquence complètement absurde.
Des interruptions du combat toutes les 5 secondes
Le RAM buffer du Mega-CD est trop petit pour contenir tous les combattants nécessaires à cet effet de transformation. Une problématique qui n’existe pas sur cartouche puisque l’intégralité de celle-ci, et donc l’intégralité des combattants, est accessible à tout moment.
C’est un très bon exemple de ces situations de jeu ou la cartouche reste imbattable. Ce qui a longtemps rendu le portage des jeux NeoGeo compliqué même sur des machines bien plus modernes. En particulier, les jeux de versus fighting sont souvent problématiques pour les machines CD. Même la NeoGeo CD avec ses 7 Mo de RAM buffer n’est pas capable de supporter tous les jeux de versus fighting NeoGeo.
Sonic CD, a défaut d'être une bonne démonstration d'utilisation des capacités graphiques du Mega-CD, est sans doute un exemple plus intéressant en ce qui concerne l'utilisation du stockage. C’est l’un des rares qui semble montrer une volonté d’utiliser le support CD comme une très grosse cartouche sur un jeu d’action classique.
Pas tant pour proposer des graphismes et animations plus riches que ne le pourrait une cartouche, mais plutôt pour proposer une quantité très élevée de stage, ce qui n'est pas un usage très spectaculaire mais a le mérite au moins d’explorer cette voie.
En effet, le jeu est décomposé en 7 mondes, eux même découpés en 3 stages qui eux même existent, la plupart du temps, en 4 versions (Past, Present, Bad Futur, Good Futur).
C’est surtout cette dernière étape qui semble issue d’une volonté d’exploiter la capacité du support CD. En ajoutant les 8 stages bonus, ça donne un total de 78 stages “différents”, ce qui est très généreux. Malgré tout, il reste difficile d’estimer la taille réelle du jeu et affirmer avec certitude qu’elle dépasse celle d’une cartouche 4 Mo.
Sonic CD Present, Past, Good Future, Bad Future
Si on analyse un peu le file system de la track 1, on voit un jeu qui fait environ 20 Mo sans les track audio et vidéo. Effectivement, chacun des 70 stages a son propre fichier de 256 ko donc ça monte vite. Ils ont en quelque sorte standardisé le loading des stages.
Mais on devine qu’ils ne remplissent pas tous exactement les 256 ko du fichier. Et surtout, comme j’expliquais précédemment, le stockage sur CD est très différent du stockage sur cartouche. Il y a beaucoup de redondance de données.
Typiquement, ici, le fichier du stage doit probablement tout contenir. Aussi bien la tilemap de construction du stage que son set de tuile mais aussi probablement les ennemis qui parsèment le stage, voir les bruitages.
Sur CD on s’arrange pour tout réunir dans un seul fichier pour minimiser les seek time. C’est à dire les temps de déplacement de la tête de lecture, entre 2 fichiers, qui sont lent. Il n’est pas question par exemple d’avoir un fichier différent pour chaque ennemi. Ça rendrait les loading beaucoup plus longs. Donc ça implique que si un ennemi est récurrent et présent dans 30 stages par exemple, alors il est dupliqué 30 fois sur le CD. Pareille pour les bruitages ou les tuiles récurrentes d’autant que la nature des stages, qui sont les mêmes à différentes époques, implique beaucoup d’éléments redondants.
C’est ce mécanisme de redondance qui rend compliqué l’estimation réelle de la taille d’un jeu CD transposé sur cartouche. On peut supposer qu’il ne tiendrait pas dans une cartouche de 4 Mo, mais peut-être pas beaucoup plus malgré tout. A mon avis, en enlevant les stages bonus, ça rentre sans problème.
Au final je ne trouve pas de très bon exemple d’usage du Mega-CD comme une grosse cartouche. Notamment des exemples qui s’en serviraient pour vraiment enrichir le visuel du jeu.
J’aurais aimé voir des jeux classiques avec par exemple une gestion dynamique du set de tuile du décors pendant la progression pour s’affranchir des limites de la VRAM et avoir des stages graphiquement plus riches qu’habituellement. Un peu à l'image de ce que tente de faire Amaru avec le remake homebrew de Ghouls’N Ghosts sur cartouche Megadrive même si la comparaison est délicate car la cartouche originale est très petite (640 Ko).
Ghouls’N Ghosts Megadrive original versus Amaru remake
On aurait pu aussi peut-être avoir une tentative de moteur graphique de type “infinite tileset” tel qu’avait expérimenté Traveller's Tales dans Sonic 3D Blast.
La 3D isométrique n'étant pas très adaptée à une composition d’image par tuile, elle en consomme beaucoup. Ils avaient trouvé la parade en codant un moteur qui alimente continuellement la VRAM en nouvelles tuiles au file du scrolling.
Ça permet en théorie d'avoir des stages ou chaque tuile de décors peut être unique pourvu qu’on ait suffisamment de stockage. Les animations de tous les sprites aussi sont mises à jour au fil des besoins si bien que la VRAM contient uniquement les tuiles qui sont à l'écran (sprite et décors).
Cette solution a ses limites et ses contraintes propres mais ça aurait été intéressant de voir ce genre de tentative combinée aux capacités du CD.
Sonic 3D Blast et son moteur “infinite tileset”
Pour résumer, j’aurais voulu voir des choses qui s'approchent d’un jeu NeoGeo dont la force était, en grande partie, la taille des cartouches. Voir sur Mega-CD quelque chose qui ressemble à du Metal Slug par exemple. C’est à dire avec une quantité d’animation et une richesse de décors sensiblement supérieure à ce qu’on pouvait voir sur cartouche Megadrive.
Idéalement il aurait fallu un buffer RAM encore plus ambition, plus proche d’une Arcade Card (et bien coder tout ça pour contourner au mieux les contraintes VRAM/DMA qui n’existe pas sur NeoGeo). Et puis il y a les raisons économiques. Il s'agit peut être de projets trop coûteux pour un parc installé trop faible à l'avenir incertain.
En réalité, quand il s’agit de mimer les gros jeux NeoGeo, le Mega-CD n’est pas vraiment d’une grande aide. Rien ne serait plus efficace qu’une cartouche de très grande capacité (mais dans des proportions qui n'était pas possible à l'époque), surtout pour les jeux de versus fighting. Disposer, par exemple, d’une bank ROM de 16 Mbit de data en accès immédiat pour chaque combattant tel un jeu NeoGeo, seule une cartouche Megadrive le permettrait aujourd’hui en homebrew. Ce n’est pas possible avec le Mega-CD.
Part 2: Les Downgrades du Mega-CD
Évidemment le Mega-CD ne porte pas le downgrade en lui. Comme on l’a vu, il y a plein de façons de l’utiliser de manière 100% bénéfique (cinématiques, musiques, bruitages) et qui, pour beaucoup, seront des ajouts suffisants pour justifier la machine.
Parfois même des usages très originaux comme dans Paprium qui utilise le CPU du Mega-CD pour piloter l’IA du second joueur quand on est seul.
En ce qui concerne l’amélioration graphique c’est plus compliqué. Le Mega-CD n’a pas de sortie vidéo tel que sur 32X. Tout ce qu’on voit à l'écran passe par la Megadrive. Le Mega-CD n’a aucun moyen d’augmenter directement les capacités graphiques de la Megadrive. Par exemple, il ne va pas augmenter le nombre de couleurs ni la résolution (on va voir que c’est même plutôt l’inverse).
Donc son impact sur les graphismes est plus indirect. L’un des moyens serait d’exploiter la capacité de stockage pour augmenter la richesse visuelle globale (la variété, les animations…). Mais on l’a vu au chapitre précédent. Aucun jeu 2D classique n’en profite fondamentalement car ce n’est pas facile (d’autant que ce sont presque tout le temps de simples portages de jeux cartouches). A l’exception des jeux d’aventures très graphiques.
Les graphismes de quasiment tous les jeux 2D classiques du Mega-CD, tel les platformer et autres shmups par exemple, sont des graphismes strictement Megadrive. Les rares moments ou vous pouvez deviner une participation du Mega-CD dans l’aspect visuel de ce type de jeu c’est lorsque vous voyez un effet de scaling ou de rotation sur un sprite. C’est souvent très ponctuel et à la marge. Mais c’est compliqué de faire plus dans ce contexte.
Même le fameux Earnest Evans, qui a fait partie du line up du Mega-CD au Japon où il a été vendu comme un jeu exclusif et spécifiquement conçu pour lui (pour sortir quelques mois plus tard en cartouche au US), est, strictement, un jeu Megadrive graphiquement.
Évidemment il profite de cut-scènes et de musiques que l’on doit au support CD. Mais tous les effets de rotation et de scaling qui ont, sans doute volontairement, trompé les joueurs et créé la confusion, sont uniquement des effets précalculés et clairement conçus au départ pour tourner sur une Megadrive (grâce notamment à ce système de marionnette qui consiste à fragmenter le personnage, ennemi ou piège en pleins de petits segments stockés en multiple exemplaire pré-rotationné).
C’est pour cette raison que la version cartouche est exactement la même, pixel perfect, tout en tenant sur une simple cartouche de 1 Mo.
Earnest Evans CD, des effets 100% précalculés
Puis il y a les jeux qui choisissent spécifiquement d'utiliser les ressources du Mega-CD (CPU et custom chip) pour les graphismes. Ça nécessite alors de construire l’essentiel de l’image dans le Mega-CD et ensuite injecter cette image dans la Megadrive comme si c'était un simple plan de background. Une approche radicalement différente des jeux classiques.
C’est une catégorie de jeu Mega-CD, un peu à part, qui est très identifiable (dans laquelle on pourrait mettre aussi les jeux FMV). C’est ce qu’on pourrait appeler la catégorie “Super FX” car c’est la même approche technique.
Et lorsqu’on utilise le Mega-CD dans ce cadre là, pour un vrai boost graphique (qui est tout de même l’une des ses fonctions et probablement celle qui porte le plus d’attente des joueurs) alors les choses se compliquent et deviennent plus nuancées voire paradoxales.
C’est principalement de ce contexte là dont je vais parler dans cette seconde partie.
Je ne vais pas non plus évoquer le downgrade intrinsèque à tout support CD, les loading, mais, évidemment, vous pouvez l'ajouter aux 4 autres que je vais détailler dans cette seconde partie.
Parfois, même le son peut être downgradé d’une certaine façon, lorsqu'on remplace certains bruitages de pure synthèse (PSG ou FM) par un sample de basse qualité. La synthèse offre une certaine pureté de son (une quantification élevée). Par exemple, certains apprécient peu le nouveau son samplé pour le jump de Sonic CD. Mais c’est à la marge. Le son est le grand gagnant du Mega-CD donc je ne vais pas en parler dans cette partie.
Pour commencer, il est bon de rappeler que les jeux consoles 8/16 bit sont très majoritairement des jeux 60 fps. Tout simplement parce que ce sont des hardwares intrinsèquement calibrés pour accompagner le balayage écran (construction de l’image au raster, c’est à dire au fil du balayage écran, et pas dans un framebuffer). Faire un jeu à 30 fps, ou moins, sur ces machines est un usage non optimal du hardware.
La question du downgrade du framerate des jeux Mega-CD implique d’évoquer tout de suite ce qui est au cœur de la plupart des problèmes qui vont suivre.
Je reviens donc sur ce que j'expliquais en introduction car c'est important de comprendre. Si l’on souhaite, par exemple, utiliser pleinement les capacités de scaling/rotation du Mega-CD pour proposer quelque chose de neuf graphiquement, ça nécessite de déléguer au Mega-CD l’essentiel de la construction de l’image. Et construire l’image à l'extérieur de la Megadrive pose un problème majeur car il faut ensuite transférer cette image dans la VRAM de la Megadrive pour pouvoir l’afficher comme un simple plan de background.
C’est exactement la problématique qu’on retrouve pour les jeux SNES qui utilisent le Super FX pour construire l’image dans la cartouche tels Starfox, Stunt Race ou Doom.
Même si les consoles 16 bit ont amené de nouvelles fonctions hardwares de transfert rapide de données (DMA) qui n'existaient pas sur les consoles 8 bit, ça reste des transferts lent.
De plus, les transferts en question ont comme destination la VRAM qui n’est pas vraiment accessible pendant le balayage de l’écran (car utilisé par le chip graphique a ce moment-là). Les transferts vers la VRAM sont donc réduits à une petite fenêtre temporelle, entre l’affichage de 2 images, qu’on appelle le Vblank. Typiquement la Megadrive va pouvoir transférer entre 6 et 7 Ko par frame (ou plutôt par Vblank) mais une image standard Megadrive 320x224 pixels c’est 35 Ko donc très long à transférer dans ces conditions.
Vous comprenez alors toute la problématique d’externaliser la construction de l’image et vous comprenez par la même occasion pourquoi le 32X intègre une sortie vidéo. Cela lui permet de simplement mixer son flux vidéo avec celui de la Megadrive pour être totalement indépendant et s’affranchir des contraintes de transfert d’image (ou de palette) vers la Megadrive.
C’est ce transfert de l’image qui va brider structurellement le framerate de ce type de jeu Mega-CD (ou Super FX) autour de 15 fps pour avoir le temps de charger l’image Mega-CD dans la VRAM Megadrive (en utilisant en moyenne 4 Vblank, ou frames, successif).
Cela veut dire que même si les performances du Mega-CD (ou du Super FX) étaient cent fois supérieur à ce qu’elles sont, ça ne changerait strictement rien à cette fatalité du low framerate, dans ce contexte, à cause du coût du transfert d’image. C’est vraiment ça qu'il faut comprendre.
Pour illustrer le propos, prenons l’exemple des scènes de Batmobile, dans Batman Returns, qui font partie des démonstrations techniques exploitant le mieux les capacités du Mega-CD.
Ce sont des scènes de type “Sega super scaler” (en alternance avec les stages de platformer classique venu de la version cartouche) qui exploitent au maximum les fonctions de scaling/rotation du Mega-CD. Toute la scène de jeu est alors une image construite dans le Mega-CD, par son CPU et son custom chip, dans un framebuffer qui, lui-même, se trouve dans l’une des RAM du Mega-CD.
Batman Returns CD
Que ce soit la route, les bâtiments, la batmobile, les véhicules, les ennemis, les missiles, les explosions… même le timer. Toute la scène est construite dans le Mega-CD. Une scène 256x192 pixels soit 24 Ko qui doit alors être transférée dans la VRAM de la Megadrive pour être affichée comme un simple layer de background Megadrive.
De son côté, la Megadrive va aussi participer à l'image finale en utilisant son second layer de background pour ajouter le ciel violet en arrière-plan ainsi que le HUD en bas (qui ajoute 32 lignes pour une image finale de 256x224). Et les sprites hardwares de la Megadrive me direz vous?
Ils sont utilisés uniquement pour ajouter un autre layer en arrière plan. La ville que vous voyez sur l’horizon est composée par les sprites hardware de la Megadrive qui sont donc relayés à une tâche très secondaire. Ce ne sont évidemment pas eux qui composent les objets mobiles de la scène (c’est le job du Mega-CD).
Cet exemple permet d’illustrer que la composition d’une image de jeu Mega-CD peut être relativement contre-intuitive.
Voici un screenshot de l’image 256x192 produit dans le Mega-CD et envoyé ensuite dans la VRAM de la Megadrive. Il y a quasiment tout le jeu dedans.
Le layer Mega-CD de Batman Returns
Ces séquences ont majoritairement un framerate de 15 fps comme on peut s'attendre pour ce type de jeu Mega-CD. Quelquefois 12 fps mais parfois 20 fps ce qui est plutôt impressionnant dans ce cas.
C’est possible parce que le jeu choisie volontairement une résolution un peu plus faible qu’un jeu Megadrive standard (ou que les phases de plateformes). Mais aussi parce qu’il met en place un transfert d’image plus complexe en exploitant la particularité de la VRAM Megadrive d'être disponible pas seulement pendant le Vblank mais aussi lors de bref moment durant le balayage écran contrairement à la SNES par exemple. C’est plus lent que pendant le vblank mais ça permet d’ajouter quelques Ko de transfert bien utile car, sans cela, il ne serait pas possible de transférer les 24 Ko d’image en seulement 3 Vblank (60 hz / 3 = 20 fps).
C’est une astuce qui n’est pas utilisée seulement pour accélérer le transfert d’image mais aussi pour économiser de la VRAM.
En faisant des transferts VRAM de façon synchrone avec le balayage (pour le suivre ou le précéder selon la frame), ça permet de réduire l’emprunte du double framebuffer qu’il faut réserver dans la VRAM de la Megadrive pour réceptionner l’image du Mega-CD. Il est alors possible de se contenter d’un double framebuffer partiel dont une partie (12 Ko) est partagée entre les 2 frames (celle en cours d’affichage et celle en cours de transfert) pour un total de 36 Ko. Sans cette astuce, il faudrait réserver 2x24 = 48 Ko sur les 64 Ko de la VRAM Megadrive (soit les 3/4) juste pour contenir ce double framebuffer.
Toutes les caractéristiques techniques de ces séquences de Batman Returns se retrouvent à l'identique dans les séquences de snowboard de Cliffhanger (même développeur) qui sont très réussies aussi.
A l’inverse, les séquences Batmobile de Batman & Robin, qui ressemblent beaucoup à celles de Batman Returns, ne viennent pas du même studio mais sont peut-être encore plus impressionnantes.
Elles sont maintenant au cœur du jeu (pas de phase platformer dans cet épisode) et probablement très proche du max qu’on peut tirer du Mega-CD en mode “super scaler”. Même les cut-scenes vidéo sont très réussi techniquement.
Batman & Robin CD
Comme pour Batman Returns, c’est le Mega-CD qui s’occupe de l’essentiel de l’image de Batman & Robin. C’est lui qui construit toute la scène. Le nombre d’objets ainsi que leurs tailles sont impressionnants quand on connaît les limites de fillrate des fonctions Scaling/Rotation du Mega-CD évoqué dans le chapitre sur le mode 7. Ça trahit indiscutablement une optimisation très poussée.
Le second layer background de la Megadrive est utilisé encore une fois pour le décors d’arrière-plan mais en combinant la ville et le ciel dans le même layer ce qui donne un résultat plus réussi en termes de composition d’image et de palette, en plus de libérer les sprites hardware de la Megadrive qui, cette fois, sont utilisé pour composer le HUD qui vient s’ajouter par dessus la scène comme un 3ème layer.
Ils ont fait un choix de format d’image un peu différent de Batman Returns. Du 240x208 pixels avec donc l’ajout de petites bandes noires sur les côtés pour réduire la charge de transfert d’image et compenser le petit supplément de verticalité.
Au total c’est un poil plus de pixel que Batman Returns mais ca reste très proche. Et surtout ils ont enlevé le HUD en bas ce qui, malgré la plus grande verticalité de la scène, permet d'avoir un Vblank plus long et donc une marge confortable pour le transfert d’image.
Donc en terme de transfert d’image, le jeu n’a aucun mal à tenir les 15 fps et même quelques fois 20 fps comme pour Batman Returns. C’est surtout le fillrate du custom chip qui souffre lors des scènes un peu chargé ce qui va parfois faire descendre le framerate à 12 fps voire un peu moins.
Je vous ai exposé 2 exemples de jeu Mega-CD (3 avec Cliffhanger) plutôt représentatif de ce qu’on peut obtenir de mieux dans ce contexte si on fait bien les choses, et du type de framerate qu’on peut en attendre.
Mais il y a aussi les élèves un peu moins doués. Les cancres du framerate comme par exemple BC Racers. Une sorte de Mario Kart avec un environnement plus chargé pour donner un peu de volume grâce aux fonctions de scaling du Mega-CD.
Entre 8 et 10 fps pour BC Racers
Le jeu fait un choix de composition d’image pas inintéressant, à la manière d’un Battlecorps ou Soul Star, qu’on développera dans les chapitres suivants. Mais malgré une fenêtre de jeu plutôt réduite (256x128), le framerate peine entre 8 et 10 fps (parfois moins). On atteint des seuils qui ne sont plus tellement acceptables (en plus d’avoir une désynchronisation entre la mise à jour du sol et des “sprites”).
Malgré tout, les versions 3DO et 32X ne font pas tellement mieux. La version 3DO a un framerate aussi bas que cette version Mega-CD pour un visuel très similaire avec juste plus de couleurs, un peu plus d’objets et moins de clipping. La version 32X a le visuel de la version 3DO mais en améliorant un peu le framerate (10-12 fps, attention certains émulateurs le font tourner à 30 fps).
Si la version Mega-CD est un peu décevante, elle l’est peut-être moins que les autres au final.
Comme on peut le deviner dans ce dernier exemple, le transfert d’image (DMA) n’est pas le seul goulot d'étranglement. Les faibles performances en scaling/rotation du Mega-CD limitent assez vite le framerate aussi. Le fillrate de cette fonction est relativement faible (environ 1,5 Mpixel/s). Donc même si il était possible de faire un transfert d’image instantané, ça n'aurait pas permis pour autant de faire grand chose à 60 fps.
On a quand même quelques exemples d’usage de cette fonction scaling/rotation du Mega-CD en 60 fps mais alors limité en général à un seul objet de la scène pour que le transfert se fasse en un seul Vblank. Un usage parcimonieux, relativement similaire à celui du Super FX dans Yoshi’s Island. L’idée est simplement d’agrémenter avec quelques FX un jeu 2D classique qui tourne sur la Megadrive.
Puggsy CD est un bon exemple de cela. C’est une version améliorée du jeu cartouche Megadrive, lui-même portage d’un jeu Amiga. Dans cette version CD ils ont ajouté quelques stages et boss. Notamment ce gros crabe qui exploite les fonctions du Mega-CD pour ce FX de rotation en 60 fps sur les pinces et la tête.
A savoir que ce sont les gars de Traveller's Tales derrière ces versions. Ce sont d'anciens demomaker qui maîtrisent et aiment programmer des FX un peu compliqué. Ca explique leur désir d'exploiter un minimum les capacités du Mega-CD dans ce portage.
Rotation dans Puggsy CD
Le jeu est entièrement géré par la Megadrive. Ce qui permet d’avoir un jeu 60 fps parfaitement réactif. Le layer traité par le Mega-CD se limite ici à cette petite fenêtre de 128x96 pixels qui contient la tête et les pinces du boss. Suffisamment petite pour pouvoir être transférée dans la Megadrive en un seul Vblank pour tenir les 60 fps (et aussi pouvoir être traitée à cette cadence par le fillrate limité du custom chip Mega-CD).
Ce format 128x96 pixels (soit 6 Ko) est proche de la limite si on veut ajouter un FX Mega-CD à 60 fps dans un jeu Megadrive.
Le layer 128x96 produit par le Mega-CD
Ce boss à tête de renard est un autre bon exemple. Cette fois c’est un FX de scaling plutôt que de rotation mais une nouvelle fois en 60 fps.
Scaling dans Puggsy CD
A première vue, cet objet 256x128 pixels pourrait sembler trop gros pour un transfert à 60 fps. Et effectivement c’est le cas. Il ne serait pas possible de transférer un objet aussi gros entre le Mega-CD et la Megadrive en un seul Vblank.
L’astuce ici consiste à exploiter la symétrie du visage. En effet le Mega-CD ne va scaler et transférer qu’une moitié de visage soit 128x128 pixels. C’est la Megadrive qui va se charger de créer la seconde moitié par simple symétrie grâce à sa fonction hardware de flipping de tuile.
Le layer 128x128 produit par le Mega-CD
Les gars de Traveller's Tales savent toujours être ingénieux. Mais 128x128 pixels c’est quand même plus que les 128x96 pixels du FX du crabe dont je vous disais qu’il était proche de la limite.
Effectivement, 128x128 pixels ça fait 8 Ko de données. C’est un peu trop à transférer en un seul Vblank. Mais encore une fois Traveller’s Tales va trouver la parade en prolongeant artificiellement le Vblank. Ça revient à raccourcir la verticalité de l’image du jeu (qui passe de 224 lignes à 219 lignes) et donc ajouter une petite bande noire de 5 lignes que vous pouvez voir au sommet du gif précédent. C’est d'ailleurs le seul moment du jeu ou vous verrez cette bande noire.
Il faut savoir que ce boss n’est pas exclusif à la version Mega-CD contrairement au crabe. Les compétences de Traveller’s Tales leur ont permis de reproduire ce scaling en software, juste avec le CPU de la Megadrive, et toujours a 60 fps!
La résolution est plus faible que pour la version Mega-CD mais un scaling software de cette taille (même s'ils profitent là aussi de la symétrie) à 60 fps sur Megadrive, c’est quelque chose de vraiment rare. En général les effets de scaling (Space Harrier, Outrun, Afterburner…) sont précalculés, ce sont des simulacres.
Donc même si moins spectaculaire, cette version du boss est peut être encore plus impressionnante techniquement.
La version cartouche du boss, un défi technique étonnant
Le 6ème boss aussi est exclusif à la version Mega-CD comme le crabe et utilise aussi un FX de rotation produit par le Mega-CD.
Par contre attention aux pièges. Le 2ème boss sur le bateau est exactement le même sur Megadrive car l’effet de rotation utilise simplement les tables de scrolling de la Megadrive. Notamment la capacité à créer des bandes verticales de parallaxes qui permettent de simuler un léger effet de tangage sur quelques degrés et qu’on retrouve dans beaucoup de jeux Megadrive (par exemple dans Batman & Robins à plusieurs reprises).
Effet de tangage qui utilise uniquement les fonctions hardwares de la Megadrive
Ce type d’usage parcimonieux de scaling / rotation à 60 fps on en trouve aussi dans la version CD de Chuck Rock 2 mais de façon encore plus discrète. Notamment sur les rochers qui roulent.
Mais ce genre d'exemples d’usage du Mega-CD dans des jeux classiques sont très rares au final. Il faut donc les savourer.
Il est aussi possible d’agrémenter un jeu 2D classique Megadrive 60 fps avec des FX Mega-CD qui ne sont pas en 60 fps. Ce genre de mélange est possible.
On l’a vu d’une certain façon avec l'exemple de Silpheed qui demande au Mega-CD de produire des animations 3D flat à 15 fps que la Megadrive se charge d’encapsuler ensuite dans des sprites hardwares classiques qu’elle déplace alors à 60 fps comme un shmup traditionnel.
On retrouve un peu ça dans Robot Aleste mais de façon très anecdotique.
A (seulement) deux occasions dans le jeu, on voit un effet de scaling à 20 fps (avec tearing), sur un ennemi. Un FX pris en charge par le Mega-CD et encapsulé dans des sprites hardwares.
Et une troisième fois dans le combat final, cette fois sur tout le background, mais à 12 fps.
les 3 effets de scaling de Robot Aleste
Mais tout ceci sont des usages plus anecdotiques et limités. Lorsque l’usage graphique du Mega-CD est plus massif et central comme on l’a vu pour les jeux de type “super scaler” (ou FMV) alors il est guère raisonnable d’espérer plus de 15 fps.
Il faut même plutôt s’en réjouir quand c’est le cas car ça peut être moins. Mais il y a aussi des exceptions comme Soul Star qui arrive à relativement bien tenir les 20 fps la plupart du temps grâce à des choix ingénieux que je développerais plus loin dans ce billet.
La dégradation du framerate entraîne inévitablement une forte dégradation de l’input lag. Les 2 vont de pair. Mais faire simplement le rappel de cette corrélation ne justifierait pas un chapitre.
En effet, la question est plus intéressante que cela. Le downgrade de l’input lag dans ce type de jeu Mega-CD ne vient pas seulement du downgrade du framerate. Il y a autre chose qui s’ajoute à ça et dégrade encore plus l’input lag. L’externalisation de la production de l'image en dehors de la Megadrive en est à nouveau la cause. En procédant de cette manière on ajoute des étapes intermédiaires ce qui rallonge le pipeline graphique et donc l’input lag.
La chaîne complète d’input lag d’un jeu Megadrive standard est assez simple à schématiser.
Pipeline d’un jeu Megadrive standard
Ce schéma représente un jeu Megadrive standard 60 fps. Le temps s'écoule verticalement de haut en bas. Chaque bloc correspondant à une durée de 1/60ème de seconde (1 frame soit 17 millisecondes) et les couleurs correspondent à des tâches/composants différents.
Le bloc vert représente le cœur de l’input lag. C’est le temps nécessaire à la machine pour traiter toute la logique du jeu, mettre à jour les éléments mobiles et préparer les données pour le chip graphique. Données qui passeront par des transferts (DMA).
Toute cette phase s'appuyant bien entendu sur les dernières inputs du joueur récupéré par le jeu. Ce moment où le jeu décide d'interroger le contrôleur est indiqué ici par le repère “Input Polling”.
Mais le joueur n’a pas appuyé au moment exact ou le jeu interroge le contrôleur (polling). Ce serait une drôle de coïncidence. Le joueur a forcément appuyé avant. Quelque part entre deux polling, symbolisé ici par le bloc jaune, ce qui ajoute une part aléatoire d’input lag compris entre 0 et 1 frame.
On a donc potentiellement jusqu'à 2 frames d’input lag au total (sans compter le temps d’affichage de l’image, le bloc violet, à considérer surtout si le feedback de l’action se trouve dans la partie inférieure de l’écran).
Mais dans le cas d’un jeu Mega-CD de type “super scaler” à 15 fps on obtient un schéma autrement plus complexe avec bien plus de blocs (et donc d’input lag) qui ressemble plutôt à ça.
Pipeline d’un jeu Mega-CD “super scaler” standard à 15 fps
En premier lieu, on remarque que chaque étape du pipeline est maintenant composée de 4 blocs ce qui est la conséquence du framerate de 15 fps qui implique un étalement de chaque tâche sur 4 frames. Même la partie aléatoire de l’input lag (bloc jaune) peut maintenant atteindre 4 frames.
En plus de cela, le pipeline a des étapes supplémentaires. La préparation des données graphiques par le CPU Mega-CD inclut maintenant une étape de construction des tables de vecteur qui sont ensuite utilisées par l’autre chip du Mega-CD, le custom chip, pour exécuter les scaling et rotation.
Cette autre étape de rendu de l’image dans un buffer par le custom chip est nouvelle aussi comparé à un jeu Megadrive standard qui construit l’image au raster, juste au moment du balayage écran. Et surtout il y a maintenant cette étape de transfert de l’image du Mega-CD vers la Megadrive qui nécessite 4 Vblank successif de DMA vers la VRAM (en rose). Un transfert qui coûte chère aussi en input lag.
Dans cet exemple de jeu a 15 fps, on peut donc potentiellement avoir 10 frames (170 ms) d’input lag supplémentaires comparé à un jeu Megadrive standard. Heureusement l’input lag d’un jeu Megadrive, qui plus est sur CRT, est très faible donc même en ajoutant 10 frame de lag ca reste plus ou moins jouable mais c’est un downgrade du game feel vraiment pas négligeable.
Et si jamais le jeu a un framerate encore plus bas alors ça devient vraiment compliqué. Si on reprend l’exemple de BC Racer avec son framerate qui peut descendre sous les 7 fps alors on constate un input lag qui peut monter jusqu'à 23 frames (380 millisecondes).
BC Racer, jusqu'à 23 frames d’input lag
Le schéma que j’ai exposé ci-dessus représente un scénario de pipeline parmi d'autres. Probablement le plus courant mais pas le pire.
Par exemple, le jeu Formula One World Championship est un jeu de Formule 1 Mega-CD de type “super scaler” plutôt sympathique avec un framerate relativement stable entre 12 et 15 fps donc sensiblement supérieur à BC Racer. Et pourtant j’ai pu constater un input lag très élevé qui peut atteindre 21 frames.
Formula One peut aussi dépasser les 20 frames d’input lag
Une explication probable serait un scénario qui dissocie complètement la phase de construction des tables de vecteur par le CPU Mega-CD, de celle du rendu de l’image par le custom chip, travaillant alors chacun sur des frames différentes pour éviter les dépendances et mieux paralléliser ces tâches afin de les pousser plus facilement.
On serait donc plutôt sur un pipeline de ce type (ici pour du 15 fps).
Un scénario de pipeline encore plus long
Et on peut même imaginer des scénarios encore pire si par exemple on dissociait le traitement de toute la logique du jeu pour l'exécuter dans la Megadrive.
Mais vous comprenez l’idée. Faire du jeu de type “super scaler”, qui plus est en externalisant tout le traitement de l’image, ajoute beaucoup d’étapes à la construction de l’image. Si jamais, en plus, le framerate est très bas alors on atteint des niveaux d’input lag très pénibles qui peuvent rappeler certains des pires moment de la 3D et des TV LCD.
Il y a un fait qui est parfois encore mal connu. La résolution standard des jeux Megadrive est supérieure à celle des jeux SNES. 90% des jeux Megadrive utilisent une résolution horizontale de 320 pixels contre 256 dans 99% des jeux SNES.
Ce mode vidéo est appelé H40 pour “Horizontal 40 tiles”. 40 tuiles de 8 pixels de large donnant bien 320 pixels.
Malgré tout, la Megadrive dispose aussi d’un mode vidéo alternatif H32 qui est un mode 256 pixels comme sur SNES. Tout simplement parce que c’est devenu une sorte de standard industriel sur le marché console de l’époque. Plus précisément le dot clock 5.37 Mhz, hérité du chip graphique TMS9918 de Texas Instrument qu’on trouvait dans la Colecovision, le MSX ou la SG-1000, et qu’on va revoir ensuite dans la Master System, MSX2, PC-Engine, SupergrafX, SNES et Megadrive. Ce mode H32 assurant, entre autres, à la Megadrive une rétrocompatibilité avec la Master System tout en simplifiant par la même occasion le travail des développeurs pour les jeux multiplateforme.
Il se trouve que c’est ce mode “Lo-Res” 256x224 pixels qui est utilisé dans la plupart des jeux Mega-CD et plus précisément dans la totalité des jeux de type “super scaler” qui construisent leur image dans le Mega-CD.
Si vous avez lu le chapitre sur le framerate, vous comprendrez probablement pourquoi cet impératif. Le transfert de l’image Mega-CD vers la Megadrive est déjà un défi compliqué dans des résolutions de type 256x192 pixels. Utiliser le mode H40 de la Megadrive qui ajoute +25% de pixels, rendrait le casse-tête infernal. Et pas seulement pour le temps de transfert de l’image, mais aussi pour faire entrer un double framebuffer de cette résolution dans la petite VRAM de la Megadrive puisque ce type de jeu nécessite de bufferiser l’image.
Choisir systématiquement le mode lores 256x224 pixels de la Megadrive pour ce type de jeux Mega-CD fait partie des compromis incontournables pour réduire la charge de pixel.
C'est une première nécessité mais qui n’est pas suffisante. Vous pouvez constater qu’aucun de ces jeux n’est totalement full screen. Il faut généralement compléter aussi ce downgrade par une réduction de la fenêtre de jeu prise en charge par le Mega-CD.
Par exemple en ajoutant des bandes noires sur les côtés et en bas comme dans Batman & Robins qui réduit légèrement sa fenêtre à 240x208 pixels.
L’autre méthode étant simplement d’ajouter un gros HUD qui a l’avantage d'être entièrement pris en charge par la Megadrive (ne fait donc pas partie du transfert) comme dans Batman Returns et Cliffhanger qui réduisent le layer Mega-CD à 256x192 pixels grâce à un HUD de 32 lignes.
Mais ça, ce sont plutôt les exemples de ceux qui tentent de garder une fenêtre de jeu maximale malgré les contraintes. Souvent c’est un peu plus radical comme Formula One qui ajoute des bandes noires tout autour de l’image + un énorme HUD de 64 lignes pour réduire la fenêtre de jeu à 240x152 pixels.
Formula One 240x152 pixels
Ou BC Racers qui encore une fois sait se distinguer avec de grosse bande noire + un énorme HUD pour réduire la fenêtre de jeu à seulement 256x128 pixels. Encore moins que Formula One.
BC Racers 256x128 pixels
Thunderhawk use aussi de l’astuce du HUD pour réduire la fenêtre à 256x152 pixels. Un sacrifice qui, au moins, lui permet parfois d’atteindre les 20 fps et même d'ajouter une petite map 72x48 pixels prise en charge aussi par le Mega-CD.
Il fait plutôt un bon usage de ce compromis.
Thunderhawk 256x152 pixels
Le record revient probablement à Battlecorps dont le HUD est si imposant que la fenêtre de jeu se réduit à un dérisoire 256x96 pixels (partiellement recouvert par les excroissances du HUD). C’est la moitié des pixels de Batman & Robin et 3 fois moins qu’un jeu Megadrive standard. Et pourtant ça n'empêche pas le jeu de tomber parfois sous les 10 fps même s'il tient quand même bien les 15 fps.
Malgré tout, c'est plutôt réussi visuellement. Beaucoup de scaling et de couleurs. On en reparlera un peu plus loin. Le HUD, lui même, est particulièrement jolie.
Battlecorps seulement 256x96 pixels
Il y a moult autres exemples de ce type. L’idée est toujours la même, et semblable d’ailleurs à celle d’un Starfox, Stunt Race ou Doom Super FX, pour les mêmes raisons. Réduire au maximum la quantité de pixel à traiter et à transférer vers la VRAM de la console sans que le subterfuge soit trop visible et gênant pour le jeu.
Des compromis qui n’existent pas sur les jeux Megadrive standard qui construisent leur image au raster.
La problématique des couleurs est un peu plus subtile à comprendre. Pour ça il faut d’abord revenir aux fondamentaux de la composition d’une image Megadrive. L’image Megadrive pioche parmi 4 palettes de 15 couleurs (+1 couleur de fond d’écran). Chaque tuile de background, aussi bien que chaque sprite, pointe vers l’une des 4 palettes au choix et se trouve donc limitée à 15 couleurs.
C’est la chose importante à comprendre. Sur console, il n’y a pas seulement des contraintes globales de couleurs affichables. Il y a aussi des contraintes locales de couleurs, à l'échelle de la tuile ou du sprite. Même une NeoGeo qui, théoriquement, peut afficher plusieurs milliers de couleurs à l'écran, est limitée à 15 couleurs par tuile de 16x16 pixels (qui pourrait pourtant en contenir jusqu’à 256).
Et ce sont bien ces contraintes locales de couleurs qui différencient vraiment une NES (seulement 3 couleurs par tuiles/sprites) d’une Master System (15 couleurs). Pas vraiment les contraintes globales qui sont proches (25 couleurs affichables vs 31), ni la palette totale (54 vs 64).
De la Master System à la NeoGeo, en passant par l’arcade, on retrouve cette même contrainte locale de 15 couleurs issu d’un mode d’affichage devenu standard dans le jeu vidéo de cette époque et qui permet d’afficher tout de même plein de couleurs à l'écran (des centaines en arcade, des milliers en théorie) tout en manipulant des pixels léger possédant une faible profondeur (4 bit).
Mais c’est une méthode optimisée pour une image construite en assemblant des tuiles et des sprites. Lorsque l’on souhaite utiliser le Mega-CD comme boost graphique et que l’on sort du champ classique pour proposer un jeu de type “super scaler” par exemple (encore plus si on veut faire de la 3D ou du raycasting, ou meme de la vidéo), on a besoin des libértés d’un framebuffer, sans contraintes locales de couleur, tel qu’on trouvait plutot sur les micro à cette époque.
Et le moyen le plus simple de s’affranchir des contraintes locales de couleurs sur Megadrive est d’utiliser qu’une seule des 4 palettes pour tout le layer que va construire le Mega-CD soit 15 couleurs.
Si on reprend l’exemple des scènes “super scaler” de Batman Returns, ça signifie que toute la scène prise en charge par le Mega-CD utilise uniquement 15 couleurs.
Ce qui inclut la Batmobile, les ennemis, les véhicules, les projectiles, les explosions, la route, les bâtiments, les lampadaires, les items, le timer… car le custom chip accumule tous ces éléments dans un unique layer, comme un seul gros objet graphique, qui sera transféré d’un seul bloc dans la VRAM de la Megadrive et n’utilisera alors qu’une seule des 4 palettes de la Megadrive. Un peu comme si toute la scène était un unique gros sprite 15 couleurs.
L’intégralité des 15 couleurs utilisées par le layer Mega-CD
Toutes les séquences en Batmobiles utilisent ces mêmes 15 couleurs qui sont toutes présentes sur ce screenshot du layer Mega-CD du jeu.
C’est seulement l’ajout de l’arrière plan et du HUD, pris en charge par la Megadrive, qui permet d’utiliser les autres palettes disponibles et ainsi ajouter un peu plus de couleur mais le mal est fait. L’essentiel de la scène de jeu est bridé à 15 couleurs et ça se ressent.
Quand on sait que la Megadrive est déjà principalement critiquée pour son manque de couleurs, un downgrade sur ce point n’est pas très bien venu.
La scène complète avec l’arrière plan et le HUD
Le downgrade de palette est d’autant plus visible sur ces séquences de Batman Returns qu’ils ont fait des choix peu judicieux.
En effet, le ciel utilise la deuxième palette et le HUD s'approprie les 2 dernières. Ça signifie que le layer des sprites Megadrive, qui affiche la ville sur l’horizon (et qui cache une bonne partie du ciel), utilise la même palette que le layer Mega-CD comme s'il en faisait partie. Ce qui rend la scène encore plus monochromatique (sans parler du choix de couleur violette pour les ennemis, couleurs deja présente dans la palette du ciel).
Sur ce point, Batman & Robin a un usage plus habile des palettes et une composition d’image plus judicieuse. Les contraintes sont strictement les mêmes que Batman Returns avec donc l’essentiel de la scène de jeu (le layer “super scaler” du Mega-CD ) bridé à 15 couleurs (une seule palette).
Mais cette fois le ciel et la ville sur l’horizon sont fusionnés dans un seul plan de background de la Megadrive. Un arrière plan plutôt réussi avec des teintes rosées qui complètent bien le layer du Mega-CD et ses teintes nocturnes bleutées en lieu et place du dégradé de gris de Batman Returns. Le HUD (en sprite Megadrive) utilise légèrement la 3ème palette pour ajouter une touche de vert bien distinct du reste de la scène. Et le jeu n’utilise même pas la 4ème palette. Pourtant le résultat est plus séduisant que Batman Returns.
Une palette mieux maîtrisé dans Batman & Robin
Malgré tout, cette limite de 15 couleurs se fait à nouveau bien ressentir lors de certains stages comme celui du parc d'attractions sur le thème de la savane.
Vouloir représenter les arbres, girafes, rhinocéros, zèbres, avec cette même palette de 15 couleurs, devient un défi qui semble insurmontable. Même s'il s’agit toujours d’installer une ambiance nocturne bien pratique, le résultat est un peu triste et vient nous rappeler le downgrade de palette de ces types de jeux Mega-CD.
Une séquence qui subit difficilement son unique palette
Les mêmes contraintes s'appliquent sur Cliffhanger. Seulement 15 couleurs pour la scène de jeu qui, dans ce contexte de décors enneigé, passe plutôt bien.
Cliffhanger, même combat, 15 couleurs
La même chose pour Thunderhawk. 15 couleurs pour toute la scène (sol, arbres, montagnes, tanks, hélicoptères, missiles, fumée, explosion…) à l'exception, encore une fois, du ciel qui est un plan de background Megadrive avec sa propre palette.
Thunderhawk et la malédiction des 15 couleurs
Il existe des solutions pour tenter d’utiliser non pas une mais deux palettes 15 couleurs pour la scène traité par le Mega-CD.
C’est ce que fait Battlecorps pour proposer quelque chose de plus coloré d’autant qu’il va volontairement piocher dans des couleurs primaires plutôt saturées (rouge, vert, bleu) pour que l’effort soit encore plus notable.
Battlecorps brise la barrière des couleurs
L’idée est de profiter de la capacité de la Megadrive à afficher 2 plans de background pour diviser la scène Mega-CD en 2 layers distincts avec chacun leur palette 15 couleurs soit potentiellement 30 couleurs pour la scène de jeu Mega-CD.
Ca donne une composition d’image un peu complexe qu’on peut diviser en 5 layers.
Le premier layer, pris en charge par le Mega-CD, contient les “sprites” scalés et occupe toute la fenêtre de jeux qui fait seulement 256x96 pixels. Il utilise la première palette 15 couleurs de la Megadrive.
Battlecorps, Layer 1, Mega-CD
Le second layer Mega-CD est en quelque sorte le layer “mode 7” pour représenter le sol. Il occupe seulement la moitié inférieure de la scène de jeu (48 lignes) et utilise la deuxième palette 15 couleurs de la Megadrive.
Battlecorps, Layer 2, Mega-CD
Le troisième layer, pris en charge cette fois par la Megadrive, affiche simplement l'arrière-plan sur l’horizon en utilisant la troisième palette 15 couleurs de la Megadrive.
Battlecorps, Layer 3, Megadrive
Le quatrième layer, qui est aussi à la charge de la Megadrive, a pour fonction l’affichage du HUD. Un HUD vraiment joli qui utilise très bien la quatrième et dernière palette 15 couleurs disponible.
Battlecorps, Layer 4, Megadrive
Le cinquième et dernier layer va profiter de la disponibilité des sprites hardwares de la Megadrive, qui ne sont pas du tout utilisés par la scène de jeu, pour étendre le HUD par dessus la scène.
C’est le seul moyen technique pour faire cela car les 2 plans de background de la Megadrive sont déjà utilisés dans cette zone de l’écran pour y injecter les 2 layers Mega-CD. Et puisque c’est le prolongement du HUD, ce layer utilise la même palette que celui-ci.
Battlecorps, Layer 5, Megadrive
Et maintenant une petite animation pour visualiser l’assemblage des 5 layers.
Le compositing de l’image de Battlecorps
C’est donc un exemple rare de jeu Mega-CD “super scaler” plutôt riche en couleurs.
Évidemment cette méthode n’est pas magique et sans contraintes. Diviser la scène Mega-CD en 2 layers n’augmente pas vraiment la charge pour le custom chip du Mega-CD mais par contre ça augmente la charge pour le transfert DMA de ces layers vers la VRAM Megadrive.
Comme ils ne sont pas idiot, l’idée dans Battlecorps est d’avoir un second layer qui soit juste un demi-layer (le sol) mais malgré tout, au total c’est quand même 1,5 fois la fenêtre de jeu comparé aux exemples précédents qui encapsulaient toute la scène dans le même unique layer.
C’est en partie cette méthode qui explique le choix d’une fenêtre de jeu très réduite (de façon exagérée tout de même). Il ne serait pas possible, par exemple, d’utiliser cette solution pour les jeux Batman tout en préservant le quasi full screen de la scène et le framerate.
BC Racers, par le même éditeur Core Design que Battlecorps, utilise exactement la même méthode de composition d’image avec une fenêtre de jeu 33% plus grande (256x128, ce qui reste loin du full screen). Mais au détriment du framerate médiocre déjà évoqué plus haut (8-10 fps).
BC Racers, même composition d’image que Battlecorps
Et l’autre problème de cette méthode qui favorise les couleurs, c'est d‘augmenter aussi l'empreinte des framebuffers de la scène Mega-CD dans la VRAM Megadrive (déjà très limitée) puisque maintenant il faut 2 framebuffers (un par layer Mega-CD).
C’était déjà difficile de double-bufferiser un seul layer Mega-CD, avec deux ça devient quasi impossible. Pour cette raison, il ne double-bufferise pas le demi-layer du sol qui est suffisamment petit pour être transféré en VRAM Megadrive en un seul Vblank. Mais la conséquence c’est une désynchronisation pas très agréable entre les 2 layers du Mega-CD qu’on peut constater aussi bien dans Battlecorps que BC-Racers. Ici au ralenti.
La désynchronisation entre les 2 layers
Les problèmes causés par cette méthode d'optimisation des couleurs ne sont donc vraiment pas négligeable car ça augmente les goulots d'étranglement qui sont déjà les plus problématiques dans ce type de jeu Mega-CD.
Ces jeux “super scaler” ne sont qu’une succession de lourds compromis entre résolution, framerate et couleurs. C’est ce qu’on peut retenir. Il n’y a pas de miracle. Quand on veut modestement tirer l’un de ces critères un peu vers le haut, on fait sensiblement baisser les deux autres sans qu'aucun n'atteigne jamais de toute façon le niveau d’un jeu Megadrive standard.
Il reste tout de même à évoquer le cas Soul Star qui fait partie des cas les plus intéressants du catalogue Mega-CD.
Il aurait eu sa place dans des chapitres précédents mais celui sur les couleurs me paraît opportun pour en parler car il a une composition d’image encore différente des autres et plutôt ingénieuse. Et puis ça permet de bien terminer ce billet.
C’est le 3ème jeu Mega-CD codé par Sarah Jane Avory.
A l’inverse des deux premiers, Jaguar XJ220 et Thunderhawk, qui étaient des sortes de portages de jeux Amiga, Soul Star, lui, est un jeu exclusif au Mega-CD et qui profite de l'expérience acquise. Ça se sent. Il y a probablement peu de gens qui ont eu le temps de programmer 3 jeux Mega-CD.
Soul Star, une belle réussite technique
Le jeu réussit à trouver un très bon équilibre entre résolution, framerate, input lag et couleurs.
C’est probablement le seul dans sa catégorie à tenir aussi bien les 20 fps ce qui lui permet aussi un input lag acceptable. Tout ça dans une scène de jeu qui n’est pas fullscreen (et en mode vidéo Lo-Res H32 comme les autres) mais qui occupe une surface très correct comparé à d'autres. Avec juste une petite bande noire en haut et en bas pour étendre le Vblank + un HUD de 32 lignes.
Et, on en arrive à ce qui nous intéresse ici. Il le fait en s’affranchissant des contraintes sur les palettes. C’est à dire qu’il dispose des palettes tel qu’on pourrait le faire dans un jeu Megadrive classique (donc avec des contraintes toujours fortes mais qui sont celles qu’on connaît de la Megadrive).
Pour ça le jeu choisit une composition d’image différente des cas qu’on a vu précédemment. Au premier coup d'œil ça fait penser au cas de Battlecorps ou BC Racers.
On a effectivement un sol en “mode 7”, qui fait environ la moitié de la scène (80 lignes), traité et transféré par le Mega-CD de façon indépendante du reste de la scène (les “sprites”), le tout complété, comme d’habitude, par un arrière plan et un HUD pris en charge par la Megadrive.
Le sol “mode 7” par le Mega-CD
L’arrière plan par la Megadrive
D’ailleurs, pour les stages dans l’espace, le sol est remplacé par la station spatiale (l’objectif du stage) qui subit un scaling extrême. Vous me direz, à raison, que la station spatiale occupe tout l’écran en fin de stage et représente donc une charge bien supérieure au simple “sol” de 80 lignes des autres stages?
Et bien non. Le jeu utilise ici l’astuce de la symétrie horizontale qu’on a déjà vu dans l’un des boss de Puggsy. Finalement, la charge réelle n’est qu’un demi-écran comme pour le sol. C’est la Megadrive qui s’occupe de dupliquer la partie gauche à droite, par symétrie, de façon hardware. Astucieux encore une fois.
Un scaling extrême qui profite de la symétrie
Mais les similitudes avec Battlecorps et BC Racers s'arrêtent là car le sol n’est pas le seul objet qui va être traité et transféré vers la VRAM de la Megadrive de façon indépendante. Tous les autres objets de la scène, ou “sprite”, le seront aussi.
C’est l’inverse par exemple d’un Batman qui va faire tout le compositing de la scène dans le Mega-CD afin de transférer uniquement le résultat final dans la VRAM de la Megadrive.
Au contraire, Soul Star va traiter indépendamment chaque objet graphique dans le Mega-CD et les transférer, un par un, en les encapsulant individuellement dans des sprites hardware de la Megadrive (ou dans un plan background Megadrive pour le sol). Puis c’est la Megadrive qui va faire le compositing de la scène comme un jeu classique.
Cette approche offre deux avantages. Le premier est de pouvoir potentiellement réduire la charge de transfert (et de buffer VRAM) puisqu’on évite ainsi de devoir transférer un layer complet qui contiendrait tous les “sprites” de la scène. En se restreignant sur le nombre et la taille des objets de la scène, on peut s'arranger, comme ici dans Soul Star, pour que la somme des pixels des “sprites” ne dépasse pas l'équivalent d’un demi layer la plupart du temps.
L’autre avantage, celui qui nous intéresse ici, est la disparition des contraintes de palettes. Puisque chaque objet graphique est indépendant, il peut pointer librement l’une des 4 palettes Megadrive. Elles vont donc pouvoir être toutes utilisées et pas seulement par l'arrière-plan ou le HUD.
Des phases de jeu libre très similaire à Thunderhawk
Bien sûr il y a des contreparties négatives à cette méthode. La première est d'être alors limité par la quantité de sprite hardware de la Megadrive comme un jeu classique. Notamment les contraintes de sprites par scanline qui sont vite atteintes dans ce type de jeu. Des limitations dont on s'affranchit dans les autres jeux ou l’on construit la scène dans un unique layer Mega-CD.
L'autre contrepartie est plus subtile. Plutôt que d’avoir une charge de transfert (et de buffer VRAM) fixe comme dans les autres jeux, celle-ci devient variable et indexée à la quantité d’objet de la scène et surtout à leur taille.
Pour le dire autrement, la charge devient sensible à l’overdraw. L’overdraw ce sont les objets graphiques qui se superposent les uns sur les autres dans la scène et cachent donc une partie de leurs pixels. Par exemple, dans les scènes de Batmobile, les bâtiments les plus proches s'affichent en partie par dessus les plus éloignés et les cachent partiellement, tout comme le sol. Mais comme le compositing se fait dans le Mega-CD, ce sont uniquement les pixels visibles du layer final qui sont transférés vers la Megadrive.
A l’inverse, puisque dans Soul Star tous les objets sont transférés individuellement avec un compositing qui se fait dans la Megadrive, ça signifie que tous les pixels, même ceux cachés par d'autres objets, sont transférés et stockés dans la VRAM de la Megadrive.
Par exemple, les pixels du sol cachés par une structure rocheuse posée dessus, vont être transférés malgré tout. Aussi bien que les pixels d’un vaisseau ennemi cachés par un autre devant lui ou par notre propre vaisseau. Cette méthode implique de transférer tous l’overdraw, pas seulement les pixels visibles. Ça peut donc monter très vite en charge si on ne fait pas attention. Ça oblige à contrôler plus précisément le nombre d'objets dans la scène et leurs tailles, ce qui laisse donc moins de liberté. Comme toujours, c’est une histoire de compromis.
Concrètement, avec cette méthode, il serait inenvisageable de faire ce type de scène Batmobile en traitant individuellement ces énormes bâtiments et arbres, tout ça en full screen. Ca serait beaucoup trop de pixels à transférer et stocker en VRAM de la Megadrive.
Une scène impossible à reproduire sur Soul Star
Malgré ces limites, c'est un choix intéressant. Ça permet à Soul Star de se distinguer sur certains points et de trouver un équilibre vraiment très bon entre toutes les limitations qu’implique ce type de jeu sur Mega-CD.
Le jeu propose même un système de synchronisation de la musique avec le scrolling pour que la musique soit toujours parfaitement calée avec la séquence de jeu même s'il y a des chutes de framerate durant le stage.
Et puisqu’on parle des couleurs, il y a un autre point surprenant du jeu que je voudrais souligner pour terminer. En effet, Soul Star ce permet le luxe de faire une sorte de shading temps réel pour créer un effet “Fade In” sur les objets qui entrent dans la scène.
Au lieu d'apparaître subitement, ils se fondent dans la couleur dominante sur l’horizon et apparaissent progressivement dans le but de cacher en partie le clipping. Un effet créé en software par le CPU du Mega-CD (qui doit déjà s’occuper des tables de vecteur pour le scaling) et appliqué aussi sur le sol.
Il ne s’agit pas d’une simple modification de la palette pour simuler le shading puisque les palettes sont utilisées par d'autres objets. Il faut donc modifier les pixels de l’objet, un par un, pour simuler une sorte de gradient en piochant parmi les 15 couleurs de la palette qui sont pourtant disparates. Dit de cette façon, ça ne devrait même pas fonctionner. Et pourtant c’est bien le cas même si la plupart du temps c’est peu visible.
Effet de Fade In grâce au CPU du Mega-CD
On peut citer un dernier exemple de composition d’image encore différente. Une sorte d’intermédiaire entre les différents cas que j'ai déjà exposé.
Dans Formula One, le Mega-CD construit l’essentiel de la scène dans un unique layer à la façon d’un Batman ou Cliffhanger… sauf les véhicules adverses qui sont bien pris en charge par le Mega-CD (pour le scaling évidemment) mais transféré indépendamment du reste de la scène et encapsulé dans des sprites hardwares de la Megadrive.
Cela leur permet de pouvoir piocher dans une palette différente de celle utilisée pour la scène principale (tout comme le véhicule du joueur qui utilise un plan de background de la Megadrive) et donc avoir une scène plus coloré mais au prix d’un surcoût net de transfert et de buffer VRAM qui explique, au moins en partie, la fenêtre de jeu relativement réduite (240x152 pixels) et le framerate plutôt moyen (12-15 fps).
Formula One, scène complète
Uniquement le layer principal du Mega-CD
Je n’ai pas connu le Mega-CD à l'époque mais il semble que beaucoup ont été tout de même satisfait par celui-ci malgré les critiques. Parfois ce qu’on attend c’est juste un peu de changement, des choses différentes. Surtout dans une période ou les jeux consoles pouvaient commencer à se répéter. Le Mega-CD a au moins pu apporter un peu de fraîcheur aux joueurs qui étaient tombés dans une certaine routine sur les consoles 8/16 bit.
La déception vient probablement des attentes sur les améliorations graphiques qui sont souvent des attentes un peu excessives et naïves à la fois car les add-on CD ne sont jamais une très bonne solution pour améliorer les graphismes des jeux classiques.
De ce fait, la responsabilité de cette déception a souvent été reportée sur les développeurs qui n'auraient soit disant pas fait l'effort d’exploiter le Mega-CD alors qu’il y a quand même aussi des réponses techniques pour expliquer en partie la situation.
Évidemment, je le répète, ce billet n’a rien d’exhaustif. J’avais surtout envie d'évoquer les problématiques, à cette époque, de vouloir externaliser la construction de l’image d’un jeu dans un addon, ou une cartouche, ce qui bride structurellement le résultat, quelque soit la quantité de ressources et performances que l’on met derrière. Il me semble que c’est une problématique mal connue. C'était mon point de départ et mon biais puis j’ai élargi le sujet.
Mais parfois il faut peut être juste accepter que certaines voies d’évolution technique passent par des downgrades comme on l’a par exemple expérimenté avec le passage à la 3D qui était un downgrade en framerate et input lag, ou la VR, qui, à l'inverse, incitait à une grosse upgrade du framerate et de l’input lag mais en échange d’un downgrade de la résolution et de la complexité graphique.
Mais cette problématique que j’ai exposé ici me rappelle aussi le grand regret que j’ai vis à vis du hardware Megadrive. La Megadrive a failli être un monstre de DMA.
Je le rappelle, le DMA est une fonction hardware qui permet de déplacer rapidement des blocs de données entre différentes mémoires. Mais sa fonction première c’est surtout de mettre à jour la VRAM avec de nouvelles données graphiques. C'est donc une fonction qui a un impact sur le visuel.
En l’état, la Megadrive n’a pas à rougir. Son DMA est une grosse évolution comparé aux consoles 8 bit et même plus rapide que celui de la SNES sortie 2 ans plus tard (mais avec sensiblement moins de fonctions et de flexibilité). Malgré tout, il aurait pu être encore 2 fois plus rapide pour charger la VRAM si cette dernière ne l’avait pas bridée. En effet, la Megadrive est une machine entièrement 16 bit, CPU, bus ROM, bus RAM, DMA… sauf le bus entre la VRAM et le chip graphique qui est 8 bit. C'est largement compensé en lecture (VDP) par des fréquences élevées, mais en écriture (DMA) rien ne peut compenser. Et c’est malheureux car la force première de cette machine, être une vraie console 16 bit, ne peut pas pleinement s’exprimer au final.
Je ne vais pas entrer dans les détails mais il y a eu des choix de RAM particulier pour la mémoire vidéo de la Megadrive. Des choix conjoncturels, sur un marché incertain à ce moment-là, qui auraient probablement pu être différents avec un peu plus de chance et permettre un bus 16 bit entre le chip graphique et la VRAM (comme c’est le cas sur PC-Engine et SNES mais bridé par leur bus CPU 8 bit, l’inverse de la Megadrive). Ça s'est sans doute joué à pas grand-chose. Le VDP de la Megadrive garde même des traces de ces errements.
Si la Megadrive avait pu exprimer pleinement ses 16 bit jusqu'au bout, c'est à dire jusqu'à la VRAM, alors elle aurait eu un DMA VRAM 2,5 fois plus rapide que la SNES.
En début de vie de la machine ça n'aurait pas été un atout important. Mais sur le long terme, ces capacités DMA supérieures auraient eu un impact non négligeable. Plus les cartouches grossissent, plus cette capacité devient le nerf de la guerre pour la richesse graphique et la dynamique de l’image. Et aujourd’hui, avec le marché homebrew florissant de la Megadrive, cet atout aurait été incroyable à exploiter à son maximum.
Et, bien entendu, dans le cas du Mega-CD, ce DMA boosté aurait permis sans difficulté de faire tourner à 30 fps les jeux qui construisent en partie leur image dans celui-ci (dans la limite du fillrate).
Pour terminer, je vais tout de même vous partager les 3 jeux Mega-CD qui m’ont paru les plus notables si on souhaite explorer le potentiel technique de la machine. En plus d'être ludiquement très correct voir bon.
Un podium qui n’a aucune valeur scientifique en plus de ne pas être très original.
Silpheed exploite très bien les capacités de stockage du CD ainsi que le CPU du Mega-CD pour un flux vidéo de qualité avec une technique de compression originale + de la 3D temps réel simultanément. Et tout ça avec la réactivité de gameplay d’un jeu 60 fps.
Soul Star exploite moins la capacité du CD mais beaucoup plus celle du custom chip en trouvant un équilibre très habile entre les différentes contraintes de la machine. Un visuel vraiment très séduisant (avec une inspiration Galaxy Force, de l’aveu même de Sarah Jane Avory).
Batman & Robin pousse vraiment au bout les capacités de scaling du Mega-CD sur de très nombreux gros objets en full screen. Sans doute imbattable sur ce point. Même la qualité vidéo des cut-scènes est ce qui se fait de mieux sur Mega-CD. Ce sont probablement les vidéos les plus convaincantes du support.
Au final, je pense que les capacités du Mega-CD ont été plus exploitées que ne l’imagine la plupart des joueurs. En composant avec des limites qui sont probablement mal comprises par les gens.
C’est l’ultime partie de ce billet. Une partie bonus pour continuer d'évoquer quelques autres faits techniques et anecdotes sur des jeux que je n’ai pas pu placer dans le billet.
Pour commencer, il serait bon de compléter le chapitre vidéo en évoquant la technique de quelques jeux FMV.
Souvent ce sont des technologies partagées qu’on retrouve dans plusieurs jeux FMV. Et en général, plus on pioche tard dans le catalogue, plus la technique vidéo est avancée. Dans les premiers il n’y avait même pas de compression pour la vidéo (ou le son) ce qui nécessitait des formats d’images ou framerates très limitée pour tenir dans les 150 Ko/s de débit offert par le disque. Et très souvent une seule palette utilisée (donc 15+1 couleurs), toujours dans le but de simplifier la gestion des contraintes locales de couleurs.
Mais la vidéo est un support d'images "précalculées". Des images sur lesquelles ont peut donc se permettre d'appliquer des algorithmes de plus en plus complexes et intelligents car ils n'ont pas besoin d'être "temps réel". Notamment pour forcer l'usage de plusieurs palettes simultanées en cherchant les meilleurs compromis malgré les contraintes locales tout en trouvant des moyens de réduire la quantité de données nécessaire (compression). Ça donne des résultats variables avec parfois beaucoup d'artefact blocky quand l'algorithme semble un peu perdu dans les compromis, mais ca à quand même permis quelques gains.
Fahrenheit est un bon exemple de la fin de vie du Mega-CD.
Introduction de Fahrenheit
De la vidéo cette fois 100% fullscreen sans compromis (256x224 pixels) à 10-11 fps.
C’est les mêmes caractéristiques techniques que Surgical Strike. A la différence que les vidéos de Fahrenheit utilisent les 4 palettes de la Megadrive simultanément, là où Surgical Strike, comme pas mal d’autres, en réserve une pour le HUD. Tous les potards sont au max dans Fahrenheit.
Un peu de gameplay
Et comme pour Surgical Strike, le jeu fait l’effort d’approfondir un peu le gameplay avec un semblant de navigation/exploration.
Il est même accompagné d’un second disque qui contient une version optimisée 32X pour une qualité de vidéo encore supérieure qui profite de la capacité de traitement de la 32X, de sa palette et de sa sortie vidéo.
Dans la même catégorie, Wirehead est aussi très convaincant en termes de qualité vidéo (même développeur que Surgical Strike).
La version Mega-CD du cultissime Dragon’s Lair n'est pas inintéressante.
Un moyen d’améliorer la qualité vidéo consiste à superposer 2 plans (ce que permet la Megadrive). Ça permet de réduire les contraintes locales de palette ou d’exploiter les fonctions shadow/highlight du VDP.
Mais c’est très coûteux… si ce n’est que, dans le cas de Dragon’s Lair, il est possible de profiter de sa nature de dessin animé qui se décompose naturellement en 2 plans. En effet, un dessin animé c’est en général une peinture de décor fixe par-dessus laquelle on superpose les celluloïds des éléments animés.
La version Mega-CD va donc reproduire cette composition d’image qui n’existait pas dans la version originale (il y a donc quelqu’un qui s’est amusé à détouré à la main l’intégralité de la version originale).
Un décor fixe (inclus dans le flux vidéo) qui utilise le premier plan de background de la Megadrive avec une seule palette (le résultat est très réussi pour du 15+1 couleurs). Et, par-dessus, on trouve le layer d’animation qui est le vrai flux vidéo (à 12 fps) et qui utilise les 3 autres palettes de manière dynamique.
Ça reste tout de même un défi, notamment pour faire entrer tout ça dans la petite VRAM 64 Ko de la Megadrive. Je vous ai fait un gif qui dissocie les 2 layers.
Les 2 layers qui composent le flux de Dragon’s Lair
Mais ce n’est pas la seule particularité du flux vidéo de Dragon’s Lair. Ils utilisent aussi un type de dithering peu habituel.
Les vidéos Mega-CD utilisent du dithering qui permet de simuler des teintes intermédiaires qui n’existe pas. La Megadrive en a effectivement bien besoin.
Mais au lieu d'utiliser un dithering ordonnée comme quasiment toutes les vidéos, Dragon’s Lair utilise un dithering diffus qui donne un résultat plus efficace, moins numerique.
Bien sûr, toutes ces vidéos Mega-CD gagnent à être visionnées sur CRT plutôt qu’en gif. Le dithering fonctionnera bien mieux.
D’autant plus que Dragon’s Lair a une autre particularité. Il fait partie des 2 ou 3 jeux qui utilisent le mode vidéo “HiRes” de la Megadrive (H40) pour son flux vidéo. Le mode 320x224 pixels.
Ce n’est pas tant pour afficher plus de pixel. Ce n’est d’ailleurs pas le cas. Fahrenheit en affiche un peu plus car Dragon’s Lair n'est pas fullscreen. Ils ont ajouté une bande noire de 16 pixels qui fait tout le tour du cadre de la vidéo bridé à 288x192 pixels. Non, ça sert surtout à gagner en densité de pixel (en “résolution” au sens premier du terme) pour rendre le dithering plus fonctionnel encore.
Un autre jeu FMV qui utilise le mode H40 (pas en fullscreen non plus, 288x200 pixels), et qui pousse fort aussi les potards, c’est Mad Dog II: The Lost Gold. Il fait partie des exemples qui nous montrent à peu prêt ou sont les limites du Mega-CD.
Mais ma préférence va aux séquences vidéo de Batman & Robin qui nous font oublier qu’on est sur Mega-CD. Ce sont celles qui me convainquent le plus, probablement aidées par le support dessin animé mais pas seulement. C’est très maîtrisé.
La partie technique de Cadillacs & Dinosaurs m’intrigue fortement.
Ça concerne évidemment son flux vidéo. Un flux in-game de bonne qualité qu’on ne trouve que dans les meilleurs jeux FMV. Quasiment fullscreen, 12 fps, et qui combine 3 palettes (ce qui oblige à intégrer en partie la tilemap dans le flux pour la mettre à jour en continu, en plus des palettes qui changent à chaque frame).
A cela s’ajoute beaucoup d’intéraction/collision avec la vidéo (des hitbox probablement intégré aussi au flux) avec la possibilité de détruire divers éléments pourtant intégré à la vidéo (ce ne sont pas des sprites) et qui disparaissent de celle ci quand on les détruit (rochers, troncs d'arbre, ossements, animaux) ce qui est techniquement étonnant.
Un flux vidéo in-game de qualité
On peut faire disparaître certains éléments du flux vidéo
On voit mieux la disparition des éléments quand je retire les autres layers (ce qui assombrit l’image car il y a un usage du shadow/highlight qui m’échappe aussi).
Le flux vidéo change selon ce que l’on détruit
Mais en plus de tout ça, le jeu se permet des embranchements en pleine action. Ce qui revient à choisir entre 2 flux vidéo différents. Il le fait d’une façon parfaitement seamless. Sans aucun freeze ni drop de frame malgré qu’on puisse choisir la direction au tout dernier moment.
Dans cet exemple, je choisis la direction tardivement, sur la première frame du gif. Et immédiatement, dès l’apparition de l’impacte jaune, le flux vidéo à déjà changé (même si c’est difficile a voir).
Un changement de flux vidéo au tout dernier instant
Gérer un flux vidéo aussi complexe en résolution, palette, collision, overlay d’objets destructibles, et ajouter à cela des embranchements totalement seamless (qui nécessite probablement de bufferiser partiellement un double flux à un moment ou l’autre) semble un défi insurmontable quand on sait que le débit du lecteur est de seulement 150 ko/s et qu’il y a aussi le seeking à cacher.
Une belle prouesse technique (pour un jeu ludiquement pauvre) qui méritait d'être évoquée mais qui reste à creuser. C’est encore mystérieux pour le moment.
Cette version Mega-CD de Starblade fait partie aussi des curiosités techniques du Mega-CD qui m’intrigue.
Starblade a un parcours assez sinueux. Le concept de la version arcade était de proposer une version low-cost de Galaxian 3 (que j’ai eu la chance de connaître à l’époque en arcade). C’est à dire sur une borne d’exploitation standard pour un seul joueur, un seul écran, et sans lecteur laserdisc coûteux en maintenance. Pour cette raison le jeu était intégralement en 3D temps réel plutôt qu’un mixe 3D et vidéo comme Galaxian 3.
Mais il se trouve qu’avec l'arrivée des consoles 3D + CD tel que la Playstation, les portages de Starblade sont revenus aux origines de Galaxian 3 en mixant 3D temps réel et vidéo. Pour, au final, retrouver le véritable Starblade arcade dans Tekken 5 sur PS2.
Quand est il de cette version Mega-CD développée par Technosoft?
Le jeu propose une fenêtre de jeu relativement modeste de 192x144 pixels en 15 fps. Mais de quelle nature?
Le Mega-CD a eu sa version de Starblade
Il n’est jamais facile de trier ce qui est 3D temps réel, précalculé ou vidéo dans cette série. Ça se vérifie pour cette version. Surtout en l'absence d’outils d’analyses corrects sur Mega-CD malheureusement.
Même les propos de Naosuke Arai dans Untold History of Japanese Game Developers Volume 3 sont très nébuleux et difficile à interpréter: "The indestructible background elements were indeed streaming off the CD based on the player's coordinates. So it was partially real-time, in a way. Other elements were real-time, but there were no actual polygonal calculations."
Il est possible que ce soit quelque chose d'intermédiaire. Le CPU du Mega-CD pourrait être chargé de rasterizer, au moins en partie, les polygones de la scène, un par un, comme on le ferait pour de la 3D temps réel.
Mais puisque c’est un rail-shooter, toute la dynamique de la scène est prédéterminée. Ainsi, pas besoin de faire les lourds calculs mathématiques de transformation / projection / clipping / tri que nécessitent la vraie 3D temps réel. Il suffit de précalculer tout cela sur le CD et d’envoyer juste le flux de coordonnées finales des polygones résultant pour chaque frame, tel un flux vidéo. Le support CD permet largement ce luxe.
Le CPU Mega-CD n’aurait plus qu’à tracer ces polygones (avec probablement des offsets précalculés aussi). A la manière de l’intro d’Another World, ou plus frappant, de la démo Megadrive MD-NICCC by TiTAN.
Beaucoup d’objets à rasterizer dans cette scène
Au final ça ne serait pas très différent d’une sorte de méthode de compression vidéo qui serait très spécifique à ce type d’image 3D flat (et donc très efficace en terme de taux de compression).
Et puis le fait que ce ne soit pas un flux vidéo classique expliquerait pourquoi ils auraient pu facilement intégrer la possibilité de détruire certaines parties des gros vaisseaux tel qu’on pourrait le faire en 3D temps réel. C’est quelque chose qui est plus présent que dans d’autres versions (PS1). C’est plus simple d’adapter le flux de la scène en bloquant la rasterization de certains blocs de polygones.
La scène s’adapte en fonction des destructions du joueur
Mais tout ça reste vraiment pas clair (contrairement à Silpheed par exemple).
Ce qui me fait douter c’est la présence d’objets en wireframe. Une distinction qui m'amène à pencher vers une autre hypothèse.
Toute la partie 3D flat serait plutôt un flux vidéo avec une compression lossless de type RLE qui donc ne génère pas d’artefact visible comme pour Silpheed. La 3D flat étant bien adaptée à cela.
Seuls les éléments en wireframe seraient tracés, ligne par ligne, par le CPU du Mega-CD à partir d’un flux de polygone précalculé. Cette distinction en 2 couches (flat et wireframe) permettrait alors de simplifier la scène 3D flat d'arrière-plan pour rendre la compression du flux vidéo plus efficace et tenir dans les limites.
Utiliser ce type de compression RLE me semble avoir plus de sens. Ça reste probablement plus simple qu’une rasterization de polygone. Et le débit du Mega-CD est suffisant a priori pour la fenêtre réduite du jeu (192x144 pixels). Pas besoin d’une solution plus économique en data. A vous de votez!
Jaguar XJ220 est le premier jeu Mega-CD codé par Sarah Jane Avory (Soul Star).
Le jeu a un game feel plutôt sympathique pour son genre et il a une particularité technique singulière. C’est un jeu de type “super scaler” mais qui n’utilise pas le custom chip du Mega-CD pour le scaling. Si ça c'est pas curieux?
En effet, Sarah Jane Avory avait fait une mauvaise estimation des performances du custom chip ce qui l’avait amené à la fausse conclusion qu’elle pouvait obtenir mieux en software, juste avec le CPU du Mega-CD et un bon algo optimisé pour ses besoins spécifiques. Elle changera d’avis dès son deuxième jeu (Thunderhawk).
Jaguar XJ220, du scaling 100% software
Malgré tout, on obtient un jeu qui construit une scène “super scaler” dans le Mega-CD (avec un traitement de la piste plus classique, propre à ce type de jeu de course). A la façon d’un Batman, en incluant tout, même les véhicules, dans un seul layer (donc 15 couleurs) de 240x208 pixels (presque full screen) et 15-20 fps.
Ce qui est un résultat très impressionnant pour du scaling software (le jeu propose même un mode 2 joueurs en split-screen à 10-12 fps).
Il y a sans doute une tambouille interne qui permet de tricher sur certains points. Mais ça permet de rappeler que le custom chip du Mega-CD ne fait pas de miracle (et que le 68000 du Mega-CD est costaud, supérieur à celui de la NeoGeo).
Comme j'expliquais dans le chapitre sur le mode 7, ce n’est pas vraiment un chip graphique, plutôt une assistance au CPU sur certaines tâches (même si non négligeable, encore plus pour les rotations), ce qui permet de lui libérer du temps. De ce fait, sur Jaguar XJ220, le CPU Mega-CD est sans doute très occupé et peu disponible pour autre chose.
J’ai déjà évoqué brièvement Thunderhawk, le deuxième jeu Mega-CD codé par Sarah Jane Avory, juste avant Soul Star. Un jeu au gameplay plutôt efficace (on retrouve exactement le même gameplay dans les stages libres de Soul Star) avec un rendu très correct (256x152, 15-20 fps). Et il a lui aussi son lot d’anecdotes techniques qui mérite un bonus.
Attention, ça tangue un peu
Ça concerne l’effet de tangage. On pourrait penser que c’est un effet de rotation produit par le custom chip lors de la construction de la scène dans le Mega-CD mais ce n’est pas possible avec ce type de fonction hardware (tout comme le mode 7 + HDMA de la SNES en est incapable aussi).
L’effet de tangage est alors produit en partie au moment du transfert de l’image vers la Megadrive. En appliquant un offset (décalage) sur les adresses de transfert en VRAM. Ça permet, à moindre coût, de découper l’image en fine bande verticale que l’on peut décaler verticalement les unes par rapport aux autres, au pixel, comme un effet de parallaxe verticale, pour simuler l'inclinaison de l’image.
C’est ni plus ni moins que le type d’effet de tangage qu’on trouve déjà fréquemment dans les jeux Megadrive qui, eux, utilisent pour cela ses tables de scrolling hardware (généralement en ajoutant du line-scroll horizontal au mouvement de parallaxe verticale pour que le simulacre de rotation fonctionne vraiment).
Je vous en ai déjà montré un exemple dans ce billet avec le boss pirate de Puggsy mais on en trouve plein d'autres. Par exemple, on peut constater au moins 3 usages de cet effet rien que dans Batman & Robin Megadrive.
Effet de tangage sur Megadrive grâce aux tables de scrolling hardware
Reproduire cet effet dans Thunderhawk à l’aide de cette astuce d’offset lors du transfert de l’image, plutôt qu'en utilisant les tables de scrolling de la Megadrive, permet une plus grande finesse de bande (mais en 20 fps au lieu de 60 fps avec les tables de scrolling). En effet, la table de scrolling verticale de la Megadrive autorise un découpage vertical de l’image mais plus grossier, par bande de 16 pixels de large (ce qui permet au moins de mieux visualiser et comprendre le fonctionnement de cet effet sur ces derniers gifs).
Cette méthode dans Thunderhawk donne une finesse d’inclinaison très convaincante même si ce type d’astuce est limité à des rotations faibles de 10 ou 20 degrés.
Et puisque l’intégralité de la scène de jeu est incluse dans un unique layer, ça permet d’appliquer l’effet de tangage sur tous les éléments, même les “sprites” tel que les arbres par exemple. Ce qui n’est pas possible sur un jeu Megadrive standard ou l’effet s'applique uniquement sur des plans de background.
Dernière chose amusante sur cet effet. La réactivité (input lag) de l’effet de tangage dans Thunderhawk est meilleure que le reste de la scène car cet effet n’attend pas la prochaine image en construction. Il est appliqué dès la prochaine image transférée dans la Megadrive puisque c’est une astuce de transfert.
La version Mega-CD de The Secret of Monkey Island nous fait la gratitude d’une bizarrerie qui ressemble plus à un bug qu'à un choix assumé tant ça semble absurde.
En effet, le jeu active par défaut le mode “shadow” de la Megadrive. C’est un mode qui, à l'inverse du mode “highlight”, permet plus de nuances dans les teintes sombres mais en divisant la luminosité de la palette par 2. Pour simplifié, on ne peut plus afficher de blanc, juste 50 nuance de gris...
Ça rend le jeu anormalement sombre (vraiment). Heureusement il existe un hack qui désactive le mode shadow pour utiliser le mode d’affichage normal. Je vous ai fait un comparatif.
Comparaison entre la version Mega-CD originale et le hack
Et ne me dites pas que c’est pour s’adapter au contexte nocturne. Dans ce comparatif j’ai pris le début du jeu mais c’est pareille tout le long, même en plein jour sur la plage (ou tout simplement en intérieur comme la salle du bar dans laquelle on ne voit rien).
Ca vous semble trop gros pour être une erreur? Et bien, ce genre d’erreur est plus courante que vous ne le pensez.
Par exemple, dans Back to the Futur 3 sur Megadrive on a un problème similaire.
Back to the Futur 3
On constate à nouveau une luminosité divisée par 2 mais pour des raisons un peu différentes de Monkey Island. Ici c’est une erreur de conversion des palettes.
La Megadrive utilise un format RGB 9 bit encapsulé dans un mot 16 bit d’une façon un peu particulière: xxxx BBBx GGGx RRRx (car les bits de poids faibles sont utilisés par les modes shadow/highlight). Mais dans Back to the Futur 3, ils ont mal converti les couleurs en utilisant ce format: xxxx xBBB xGGG xRRR.
Ainsi, en ayant tout décalé d’un bit vers la droite, ils ont divisé par 2 la luminosité.
Il ne faut jamais sous-estimer à quel point certains jeux étaient produits dans la précipitation à cette époque. Et puis il suffit de pousser la luminosité du moniteur pour que le développeur n’y voit aucun problème.
J’ai aussi constaté ce genre d’erreur de conversion de palette sur le Space Harrier Game Gear (pour rester encore une fois chez Sega).
Le jeu est un vulgaire ROM hack du Space Harrier Master System ce qui nécessite une conversion de palette pour passer du RGB 6 bit de la Master System aux RGB 12 bit de la Game Gear. Et là aussi il y a eu une petite erreur de conversion mais moins grave. Au lieu d’une baisse de luminosité de -50% tel les 2 cas précédents, on a cette fois un “modeste” -20%. Mais sur un jeu console portable, où l’autonomie est en partie indexé à la luminosité de l’image, c'est presque plus condamnable encore.
Comparaison Space Harrier Game Gear et Master System
Il faut bien comprendre qu'assombrir les valeurs RGB sur un écran LCD ne réduit pas la consommation (contrairement à de l’OLED). C’est le backlight de l’écran LCD qui fait la consommation et à cette époque il a une intensité fixe, peu importe que t’affiches du blanc ou du noir.
Donc un simple petit patch de correction de la ROM du jeu permet alors de gagner +25% de luminosité sans augmenter la consommation de pile.
/image%2F2902198%2F20221023%2Fob_3f70a8_arthur.png)
/image%2F2902198%2F20220606%2Fob_54c361_miniature.png)
/image%2F2902198%2F20230228%2Fob_ab04a3_miniature2.png)
/image%2F2902198%2F20220714%2Fob_ca2383_18287-zelda-no-densetsu-the-hyrule-fa.png)