24 Août 2018
Je ne sais plus exactement quand, ni dans quel magazine, mais je me souviens bien de la première fois ou j'ai lu un article sur l'arrivée d'un lecteur CD-ROM pour la PC-Engine. À cette époque, on découvrait la Master System et la NES en France. Avoir des jeux sur des "disques compact", c’était une idée qui paraissait saugrenue. On assimilait plutôt la fonction d'un CD à celle d'un vinyle à ce moment-là. Même du côté des micro-ordinateurs, il était peu probable d'entendre parler de ce nouveau support. C’était un concept encore confidentiel, un "proof of concept".
C'est donc à NEC que l'on doit l'arrivée sur console de ce nouveau support de façon excessivement prématurée, 3 ans avant le Mega-CD. Je crois que c’était vraiment la première fois que j'entendais parler de cette possibilité et c'était accompagné d'une promesse incroyable. La promesse d'un support équivalent à plus de 1000 cartouches ou HuCard ! On était clairement face à un changement de paradigme et c’était excitant.
L'article en question était accompagné des premières images de Street Fighter (nommé Fighting Street dans cette version). Ni plus ni moins que le tout premier jeu sur CD-ROM de l'histoire si je ne m'abuse (et si on fait abstraction du "jeu" d'idole anecdotique qui l'accompagnait). Mais la découverte du jeu m'avait laissé un peu sceptique. Il y avait une sorte de contraste entre la promesse et le résultat mais difficile de juger et de mettre des mots sur ce ressenti à l'époque car il n'y avait pas tellement de point de comparaison pour un jeu de combat et même la PC Engine restait quelque chose de nouveau. On était fin 88.
Ce qui est certain par contre c'est que je n'avais, à cette époque, aucune idée des tenants et des aboutissants de cette technologie. Aujourd'hui, les choses sont bien plus claires et si ce lecteur CD-ROM était un upgrade spectaculaire sur la partie audio et permettait d'enrichir la narration des jeux ainsi que tout le contenu, il cachait aussi en lui une forme de downgrade des capacités graphiques de la console. Je vais tenter d'expliquer le pourquoi de ce paradoxe.
Il y a une notion vraiment très importante à comprendre sur les consoles 8 et 16bits : les cartouches contiennent une ROM incluant le code du jeu ainsi que toutes les données qui le constituent et cette ROM est en accès direct par le processeur comme si c’était une extension de la RAM interne de la console. Le code (le programme) est donc directement exécuté depuis cette ROM de la cartouche sans passer par la RAM. Du point de vue du CPU il n'y a aucune distinction entre la RAM interne de la machine et la ROM dans la cartouche. Pour lui, c'est exactement la même chose. Les 2 se côtoient et s’entremêlent dans le même espace d'adressage et la seule distinction est juste qu'on ne peut pas écrire dans la ROM. On peut demander au CPU de le faire, ça ne produira aucun bug, juste que l’écriture n'aura aucun effet.
C’était la force des consoles 8 et 16bits. On avait donc l’intégralité du jeu (code et données) directement accessible à tout instant par le CPU. C'est aussi pour ça qu'on n’avait pas vraiment de loading pour le code et c'est aussi cela qui explique que les consoles avaient si peu de RAM CPU comparé aux micros. Une console Atari 2600, c'est 128 octets de RAM, une NES c'est 2 ko, une PC Engine c'est 8 ko, une Neo·Geo c'est 64 ko, pas besoin de plus. Là ou sur un simple micro-ordinateur ZX Spectrum ou un C64 du tout début des années 80, on peut vite monter à 64 ko de RAM (l'équivalent d’une Neo·Geo). Mais sur ces micros, plus de 90% de la RAM CPU (hors buffer vidéo) sert en général uniquement en lecture (donc comme de la ROM au final). La ROM des cartouches remplit donc très bien cette fonction.
Comme je disais, l'arrivée du CD-ROM est un changement de paradigme sur la capacité du support mais il est aussi responsable d'un autre changement de paradigme, moins évident, qui concernait spécifiquement les consoles. Un CD-ROM est radicalement différent des cartouches de nos consoles 8/16bits. Ce n'est pas une grosse cartouche. C'est un support passif, plutôt comme les cassettes ou disquettes des micros. Ce ne sont pas des données en accès direct par le CPU comme l'est la ROM d'une cartouche. Cette époque bénie prend donc fin et pousse les consoles à prendre le chemin des micros, c'est-à-dire intégrer un gros buffer RAM intermédiaire qui remplace la ROM et dans lequel on va devoir loader les données du CD dont on a besoin pour le stage en cours par exemple, comme un micro.
La conséquence du CD-ROM n'est pas seulement d'infliger les fameux loadings qui ont souvent été pointés du doigt. Quand on avait une grosse cartouche avec une grosse ROM (typiquement les jeux Neo·Geo), c’était alors comme avoir une énorme buffer RAM. C'est cet aspect qui sera difficile à reproduire en se passant de ces cartouches car la quantité de RAM contenue dans ces machines était limitée. Elle n’était pas toujours suffisante pour remplacer la fonction des ROM des cartouches.
Prenons maintenant l'exemple concret du lecteur CD-ROM² de la PC Engine dans sa toute première itération de 88 qui accompagnait Street Fighter. Pour remplacer la ROM des HuCard, le lecteur CD-ROM embarque donc un buffer RAM qui sert d’intermédiaire entre le CD et la PCE et qui a pour fonction plus ou moins d'émuler/remplacer la ROM des HuCard.
Le buffer RAM de cette première version du CD-ROM² fera exactement 64 ko (0,5 Mbit). C'est peu (le Famicom Disk System a un buffer RAM de 32 ko pour une capacité de disquette 5000 fois plus faible que les CD) mais à cette époque, les HuCard font seulement 2 Mbit soit 256 ko (les HuCard 4 Mbit arrivent à peu près en même temps que le CD-ROM). Et comme il ne s'agit évidemment pas de charger l’intégralité du jeu dans ce buffer RAM intermédiaire, on pourrait se dire que 64 ko est suffisant. D'autant que les données graphiques peuvent être chargées directement dans la RAM vidéo de la console qui fait aussi 64 ko.
Il se trouve que la PC Engine est une machine qui a été beaucoup bridée par la taille des HuCard. La production de HuCard était probablement un process plus rare et coûteux qu'un chip ROM ordinaire et le CPU de la PCE est exigeant en fréquence d’accès mémoire. Il fallait de la ROM de grande qualité. En comparaison, la Master System avait déjà des cartouches 4 Mbit depuis quelque temps quand la PCE, bien plus performante, était encore sur des HuCard 2 Mbit. Dans ce contexte, c’était effectivement simple pour le lecteur CD-ROM de faire illusion. Mais qu'en aurait-il été si le potentiel de la PCE avait pu s'exprimer avec des ROM à la hauteur de ses capacités ?
Les HuCard étant coûteuses, l’évolution a été difficile et limitée. Les HuCard 4 Mbit ont fini par se généraliser mais ça reste trop peu pour le potentiel de la PCE (pour comparaison, les 3 derniers Mega Man sur NES sont en 4 Mbit). Des HuCard 8 Mbit (1 Mo) commencent à être une proposition correcte pour la PCE (et à mettre à mal le lecteur CD-ROM et son buffer de 64 ko) mais, malheureusement, il y en a eu très peu et bien plus tard (ça se résume principalement à Parodius, Bomberman 94 et PC Genjin 3).
Reste l'exception Street Fighter 2 sortie mi 93 sur une HuCard de 20 Mbit (2,5 Mo). Ce n'est pas incroyable non plus comme capacité au vu du nombre de cartouches Mega Drive et SNES qui font 16 Mbit ou même 32 Mbit (voire 48). Et c'est seulement 0,4% de la capacité d'un CD-ROM donc une broutille en comparaison. Mais pour une HuCard, c'est beaucoup et ça a permis à la PCE nue de montrer enfin son réel potentiel. Street Fighter 2 est tout simplement impossible à reproduire graphiquement sur le lecteur CD-ROM² de 88 malgré ses capacités de stockage largement supérieures. Le CD-ROM² de 88 pouvait proposer des musiques inégalables et des cutscenes sympathiques mais une fois in-game, impossible de rivaliser graphiquement avec un jeu comme SF2 qui pose des contraintes particulières (et ça concerne les jeux de combat en général, j'y reviendrai plus loin). C'est peut-être ça qu'on devinait déjà sur les premières images mitigées du premier Street Fighter CD-ROM.
Hudson et NEC étaient vraisemblablement conscients de cela. Conscients que le CD-ROM pouvait être une forme de downgrade graphique dans certaines situations. C'est pourquoi fin 91, face au Mega CD, ils ont proposé une nouvelle version du CD-ROM². Le Super CD-ROM² qui va quadrupler le buffer RAM en passant de 64 ko (0.5 Mbit) à 256 ko (2 Mbit). C'est effectivement suffisant pour rivaliser in-game avec n'importe quelle jeu HuCard... sauf Street Fighter 2 qui reste encore trop gourmand pour pouvoir tourner sur Super CD-ROM² tel quel, sans modification/optimisation. C'est d'ailleurs sans doute ce qui explique le choix de développer ce jeu sur HuCard et pas sur Super CD-ROM² à une époque (93) ou, pourtant, la production de jeux CD prend le pas sur la production de jeux HuCard. Certains diront que le choix de l'HuCard est pour toucher un max de joueurs PCE étant donné la popularité de la licence SF2. Mais, selon moi, il y a aussi ces raisons techniques. À ce moment-là, rien n'est mieux encore qu'une grosse HuCard malgré l’évolution du lecteur CD. D'ailleurs, on devine que c'est le développement de SF2 qui a initié la troisième évolution du lecteur CD-ROM en 94 sous la forme de l'Arcade Card qui multiplie encore par 9 le buffer RAM en ajoutant 2 Mo pour un total gigantesque de 2,25 Mo (18 Mbit). Cela permet enfin de supporter SF2 et bien plus. L'Arcade Card aura d'ailleurs pour fonction d'accueillir les jeux de combat SNK calibrés pour en profiter au mieux.
Transition parfaite pour faire une analogie brève avec le cas de la Neo·Geo. La force de la Neo·Geo, c'était ses énormes cartouches. La Neo·Geo, c'est seulement 64 ko de RAM CPU mais pour les raisons que j'ai expliquées, grâce aux énormes ROM de la cartouche, c’était comme avoir un micro ou une console CD avec énormément de RAM (certains jeux Neo·Geo atteignent les 90 Mo de ROM ou 716 Mbit). C'est pour ça que la PlayStation et la Saturn, pourtant bien plus évoluées technologiquement, seront bien incapables, avec leur 2 ou 3 Mo de RAM, de faire tourner correctement les gros jeux Neo·Geo (la Saturn se verra même affublée d'une extension de RAM de 4 Mo pour mieux supporter les jeux de combat).
La Neo·Geo CD, qui embarquait pourtant 7 Mo de buffer RAM (on est loin des 64 ko du premier lecteur CD de la PCE), n'était pas capable non plus de reproduire les plus gros jeux SNK (notamment parce qu'il y a "seulement" 4 Mo de RAM graphique parmi ces 7 Mo). Encore une fois, c'était les jeux de combat qui posaient le plus de problème. Un jeu comme King of Fighters 2003, selon mes estimations, aurait nécessité 12 ou 13 Mo de RAM dans la Neo·Geo CD, à cause des combats en team. Proposer des combats 3 vs 3 en team, plutôt que du classique 1 vs 1, sur un jeu cartouche ça ne change rien car l'intégralité des combattants sont constamment accessibles sur la ROM. Mais pour des consoles CD comme la Neo·Geo CD, ou la PlayStation et la Saturn, ce ne sont plus du tout les mêmes contraintes de faire du 3 vs 3 car il faut tout faire entrer dans la RAM.
Pour information, le Mega-CD propose un buffer RAM qui se situe à mi-chemin entre le Super CD-ROM et l'Arcade Card. Quant à l’hypothétique lecteur CD-ROM de la SNES (ou Play Station pour Sony) qui n'a jamais été commercialisé, on sait, par l’intermédiaire du prototype, qu'il embarquait l’équivalent du buffer RAM du Super CD-ROM² de la PC-Engine mais probablement upgradable car intégré à une cartouche qui accompagne le lecteur. L'équivalent d'un Super CD-ROM² pour une SNES serait décevant.
Je vous ai partagé mon avis sur la question sans trop entrer dans les détails mais rien de mieux qu'un exemple concret et détaillé pour bien comprendre la problématique (mais vous pouvez aussi passer directement à la conclusion).
Pour ça, l'exemple de Street Fighter et Street Fighter II' est intéressant. Le gouffre visuel qui sépare les 2 jeux est assez patent, à l'inverse de ce qu'on aurait pu attendre d'une confrontation CD-ROM vs HuCard. Et ce n'est pas seulement la faute aux années qui les séparent et au matériau de base, même si ça joue aussi. Un Street Fighter sur une grosse HuCard 20 Mbit (improbable à l'époque) aurait pu être très proche de l'arcade alors que c'est loin d’être le cas de cette version CD malgré tous les efforts (nombreux) qui ont été faits pour relever le défi. Car, contrairement à ce que certains pourraient penser, le jeu est vraiment optimisé pour faire au mieux avec ce support. Ce n'est pas de ce côté qu'il faut chercher l'explication du piètre résultat.
La problématique du jeu de combat est l'impossibilité de faire tenir l’intégralité des sprites des combattants dans la RAM Vidéo de la console à cause des très nombreuses frames d'animations (c'est valable pour les autres consoles). Chaque combattant a un set de tuiles énorme. Ça représente même la majorité des données dans un jeu de combat. La solution, appliquée sur tous les jeux de combat console, est d'avoir une gestion dynamique de la VRAM. Dans la VRAM se trouve alors uniquement la pose actuelle des combattants à l'écran. Puis, chaque fois qu'un combattant change de pose dans son animation, on modifie les tuiles en VRAM, entre 2 frames, pour remplacer les précédentes par celles qui correspondent à la nouvelle pose du combattant. Ainsi ça consomme très peu de VRAM.
Ce type de gestion dynamique des tuiles en VRAM est lourde (ça prend du temps à déplacer) mais assez courante pour contourner les limites de la VRAM. Pour les jeux de combat, c'est vraiment indispensable comme méthode. Mais dans le cas d'un jeu sur CD-ROM cela implique d'abord que toutes les patterns de toutes les animations des 2 combattants actuellement dans l’arène soient tout de même stockés dans le petit buffer RAM du lecteur CD-ROM. Ce n'est évidemment pas sur le CD, bien trop lent, que le jeu va aller les chercher entre 2 frames. C'est donc ici que ça coince.
Commençons par quelques chiffres au sujet de ce Street Fighter II' PCE sur HuCard. Heureusement, il est possible d'identifier dans la ROM du jeu le set de tuiles qui compose chacun des combattants car les tuiles ne sont pas compressées. En effet, étant donné la gestion dynamique de la VRAM imposée par ce type de jeu, qui nécessite de transférer beaucoup de tuiles entre 2 frames, il est préférable de ne pas compresser les tuiles pour ne pas alourdir drastiquement cette tâche déjà lourde. Donc c'est rarement le cas dans les jeux de combat.
Il y a 12 combattants dans le jeu et 20 Mbit dans l'HuCard. Ma première estimation, sans comptage, uniquement par rapport à mon expérience, était de 1 Mbit (128 ko) en moyenne pour le tileset de chaque combattant. C'est effectivement ce que je vais plus ou moins trouver en comptant plus précisément dans la ROM. Mais la répartition n'est pas équitable entre tous les combattants. Je me suis donc intéressé aux plus lourds d'entre eux. On a Zangief dont le tileset complet est composé de 1376 tuiles 16x16 soit 172 ko (~1,3 Mbit) et Honda avec 1259 tuiles soit un peu plus de 157 ko (~1,2 Mbit). Ryu et Ken sont pas mal non plus. Au total, ils ne pèsent pas très lourd, 186 ko à deux (Ça fait 93 ko chaque si on coupe en 2) mais en réalité c'est parce qu'ils partagent 114 ko de tileset en commun (+ 36 ko propre à chacun) donc individuellement ils occupent quand même 15 0ko et font donc partie des plus gros.
À partir de ces chiffres, imaginons alors un combat Zangief vs Honda sur une hypothétique version CD-ROM. On se retrouve donc déjà avec 330 ko rien que pour le tileset des 2 combattants. Ça dépasse déjà largement les 64 ko de buffer RAM du lecteur CD-ROM originel et dépasse même les 256 ko du Super CD-ROM. Et il y a encore tout le reste à faire entrer ! Tout le code pour faire tourner le jeu, les autres data qui permettent d'assembler les tuiles pour construire les metasprites ou composer les animations ainsi que leurs hitboxes, le gameplay de chaque combattant, les bruitages (et, idéalement, avoir le menu de sélection dans le buffer RAM n’est jamais superflu pour éviter trop de loading mais oublions). On peut arrondir le total à 400 ko. C'est donc à peu près ce qu'il faudrait comme buffer RAM pour faire tourner confortablement le jeu dans une version CD-ROM, tel quel, sans avoir à repenser et adapter/altérer la conception du jeu. Seule l'Arcade Card répond (largement) à ces besoins avec ses 2,25 Mo de buffer RAM.
J'en ai profité pour faire les comptes aussi sur la version Arcade (en arcade, les tuiles ne sont jamais compressées étant donné que les chips graphiques y accèdent directement comme sur NES ou Neo·Geo) et ça tourne autour de 350 ko de tileset par combattant (600 ko pour Zangief) donc plus du double de la version PCE (au total il y a 4,5 Mo de tuiles juste pour les sprites et 1,5 Mo pour les backgrounds). Ainsi, ça serait intéressant d'imaginer ce que pourrait donner une version Arcade Card de SF2 (et en utilisant le dotclock 7,16 MHz de la PCE pour mieux approcher la résolution 8 MHz originelle du jeu). Avec les 2,25 Mo de buffer RAM de l'Arcade Card, il y a largement de quoi faire tenir les frames complètes du jeu d'arcade. Le bottleneck devient alors uniquement la bande passante vers la VRAM pour la gestion dynamique des tuiles qui peut alors limiter la taille des sprites des combattants.
Passons au cas Street Fighter CD-ROM que j'ai un peu décortiqué. Il y a eu beaucoup d'efforts pour relever le défi malgré le résultat pas très glorieux et c'est ça qu'il faut garder à l'esprit. Ce n'est pas un portage bâclé. Il y a un véritable effort d'optimisation, le problème ne vient pas de là.
Dans la version Arcade, le set de tuile de chaque combattant fait environ 150 ko (ça va de 64 ko à 224 ko selon le combattant). On peut donc supposer qu'une version sur CD-ROM nécessiterait un buffer RAM d'au moins 400ko juste pour le set de tuiles des combattants si on voulait être parfaitement fidèle à l'arcade et c'est évidemment loin d’être le cas avec les 64 ko de RAM buffer du premier CD-ROM.
Si on va trifouiller dans le buffer RAM de la version CD-ROM, on trouve un buffer dérisoire de seulement 30 ko dédié aux tilesets cumulé des 2 combattants (bien loin des 400 ko nécessaires). En effet, dans le buffer RAM de 64 ko du CD-ROM, il y a aussi d'autres choses à faire entrer (dont le code du jeu). De ce fait, il en reste à peine la moitié pour les tilesets des combattants. Mais on peut alors se demander comment s'en sortir avec si peu ? Ce n'est même pas 10% de ce qu'il faudrait.
En réalité, le jeu utilise différentes astuces et compromis pour s'en sortir.
Premièrement, une partie de la VRAM est détournée de son usage et utilisée, tel un buffer CPU, pour venir au secours du CD-ROM (donc de façon peu conventionnelle, car ce n'est évidemment pas à ça que sert la VRAM normalement) et forme alors une extension du buffer RAM du CD-ROM. Ce sont 24 ko de VRAM (sur les 64 ko) qui vont être détournés pour cet usage et vont alors s'ajouter au 30 ko précédents pour former un buffer (discontinu) de 54 ko pour les tilesets des 2 combattants. Ça permet de presque doubler le budget mais ceci se fait au détriment de la qualité du background car ces 24 ko de VRAM "volés" aurait pu servir à augmenter fortement le tileset du background et l'enrichir (voire ajouter un peu d'animation).
Mais ce n'est toujours pas suffisant. À cela s'ajoute donc l'utilisation d'une forme de compression pour le set de tuiles des combattants. Ça n'a pas l'air d'une compression RLE mais ça consiste probablement en partie à enlever au moins l'un des 4 bitplans des tuiles (donc de passer de 4 bpp a 3 bpp) ce qui explique la pauvreté de la palette des combattants qui, au final, utilise plutôt des demi-palettes (plutôt 7 ou 8 couleurs que 15).
Le downgrade est évident par rapport au jeu d'arcade ou tout simplement par rapport à SF2 PCE. Ce n'est pas du tout à la hauteur de ce que peut faire la PCE en termes de palette. Et c'est encore la faute à la pression exercée par la taille trop faible du buffer RAM du CD-ROM.
Autres astuces complémentaires, le tileset des combattants est découpé en tuile 8x8 (alors même que les sprites hardwares imposent un format 16x16 minimum) dans le but certainement d'optimiser encore une fois le set de tuiles. Mais, de ce fait, cela demande sans doute une reconstruction software complexe des metasprites. Pour cette raison, on remarque l'assemblage très curieux des metasprites. C'est un empilement de sprites de 16x8 ou 32x8 avec donc beaucoup d'overdraw (superposition de sprites) car normalement les sprites hardware font minimum 16 pixels de haut (pas 8) et ne sont donc ici utilisés qu'à moitié. Ce qui doit par moment frôler la limite d'affichage par scanline malgré la simplicité de ce qui est affiché.
Toute cette phase de décompression et de construction software pour optimiser la taille du tileset prend alors beaucoup de ressource CPU (je rappelle qu'on est sur un CPU 8 bits) ce qui a donc une autre conséquence. À chaque changement de pose d'un combattant (donc chaque fois qu'il faut mettre à jour les tuiles en VRAM), le jeu freeze pendant une frame ce qui dégrade la fluidité et les sensations.
Dernière astuce plus anecdotique qui est utilisée : la pose finale de la victoire ne fait pas partie du set de tuiles courant du combattant pour ne pas l’alourdir (l'animation d'introduction aussi semble-t-il). Cette pose est chargée à partir du CD à la fin du combat car elle n'a pas besoin d’être disponible pendant le combat. À chaque round, l’intégralité des data sont, de toute façon, rechargées.
Donc on constate quand même énormément d'effort et d'optimisation pour réussir à faire tourner le jeu sur CD-ROM. Tout simplement parce que c’était un vrai défi pour un jeu de combat. Le niveau de trick de programmation est vraiment très élevé ici, au-delà de la normale pour ce type de jeu. Mais le résultat, très mitigé malgré tous ces efforts, en dit long sur les compromis que cela implique. Pas seulement le manque de richesse des animations de combat dû à la faiblesse du buffer RAM de ce lecteur CD-ROM mais aussi toutes les conséquences plus indirectes qui en découlent comme la qualité restreinte du background, la palette appauvrie des combattants, le framerate altéré, les contraintes excessives sur l'overflow de sprites... Des compromis qui n'auraient pas été nécessaires avec une hypothétique version sur grosse HuCard comme SFII. Et je ne parle même pas des loadings jamais agréables évidemment (même si, sur ce premier lecteur CD-ROM de 88, ils sont quasi transparents. Ça sera le seul avantage d'avoir un si petit buffer RAM à remplir).
Au final, si on enlève les pistes audio, le jeu doit faire à peine 1 Mo, ce qui est dérisoire au vu de la capacité d'un CD-ROM (640 Mo). Ce trop faible buffer RAM ne bride pas seulement la PC-Engine mais aussi l'usage du support CD lui-même, l'un ne va pas sans l'autre.
Un ultime trick salvateur pour contourner la faiblesse du buffer RAM consiste à sacrifier le sampling audio. En effet, le lecteur CD-ROM propose un canal audio supplémentaire de type ADPCM pour faire du sampling (à dissocier de la capacité à lire les tracks CD audio qui est une autre fonction parallèle). Et ce canal ADPCM a son propre buffer 64 ko réservé pour les samples soit l’équivalent du buffer RAM ou de la VRAM de la PC-Engine. Une RAM plus simple et basique mais qui peut être détournée comme buffer intermédiaire pour stocker des tuiles graphiques. C’est ce que fait par exemple Monster Lair CD, lui permettant d’avoir un visuel correct malgré les contraintes du buffer RAM (ils ont notamment stocké toutes les animations du sprite du joueur dans cette mémoire audio). Sans ce sacrifice, le jeu aurait été sensiblement limité graphiquement et n’aurait pas été à la hauteur des attentes d’un jeu CD-ROM.
Ce trick n’est pas utilisé sur Street Fighter. Ils ont choisi de ne pas sacrifier le sampling et donc d’utiliser le buffer ADPCM réellement pour y stocker plein de samples. Il se trouve que le voice sampling (les annonces de speaker, les cris, les attaques) et les bruitages sont importants pour un jeu de versus fighting. Et puis, pour un jeu du line up, il était sans doute important aussi de faire la démonstration de cette feature du lecteur CD-ROM (c'est-à-dire l’ajout d’un canal audio ADPCM en plus de la lecture de track CDA).
/image%2F2902198%2F20231022%2Fob_905fd1_monstelaircd-pce.gif)
La promesse du lecteur CD-ROM était, en quelque sorte, de nous montrer le véritable potentiel d'une console si on s'affranchissait des limites de capacité mémoire des jeux. Le lecteur CD-ROM de la PC Engine, en arrivant si prématurément, n'a pas pu tenir cette promesse à cause d'un buffer RAM trop petit posant des contraintes fortes sur les graphismes in-game. Cela sera rectifié petit à petit, au fil des évolutions du lecteur CD-ROM et de la baisse du coût de la RAM.
Le CD-ROM n'est donc pas simplement une sorte de grosse HuCard, c'est plus compliqué que ça. Avec des HuCard contenant seulement 1% de la capacité d'un CD-ROM, on ferait beaucoup mieux en terme de graphismes in-game qu'on ne pourrait jamais espérer sur cette première version du lecteur CD-ROM² de la PCE (mieux aussi que sur le Super CD-ROM²). Mais la capacité des HuCard a toujours été très limitée, sans jamais vraiment décoller pour diverses raisons, et il n’y a donc eu peu, ou pas, d'opportunité de constater ce paradoxe. En conséquence, le CD-ROM a finalement bien rempli son rôle. Il a pallié autant que possible la faiblesse des HuCard qui brident la PC-Engine.
/image%2F2902198%2F20231214%2Fob_fe1742_megacdmini2.png)
/image%2F2902198%2F20230228%2Fob_ab04a3_miniature2.png)
/image%2F2902198%2F20221023%2Fob_3f70a8_arthur.png)
/image%2F2902198%2F20220714%2Fob_ca2383_18287-zelda-no-densetsu-the-hyrule-fa.png)