Overblog
Editer l'article Suivre ce blog Administration + Créer mon blog
upsilandre retrogaming

PC ENGINE CD-ROM, UPGRADE OU DOWNGRADE?

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. A cette époque, on découvre 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 est 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 a 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 est fin 88.

Ce qui est certain par contre c'est que j'avais a cette époque aucune idée des tenants et aboutissants de cette technologie. Aujourd'hui les choses sont bien plus claire et si ce lecteur CD-ROM était une 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 pourquoi ce paradoxe.

 

 

 

Le CD-ROM, un downgrade graphique?

Il y a une notion vraiment très importante a comprendre sur les consoles 8 et 16bit: Les cartouches contiennent une ROM qui contient 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 16bit. On avait donc l’intégralité du jeu (code et data) directement accessible à tout instant par le CPU. C'est aussi pour ça qu'on 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 Atari 2600 c'est 128 octets de RAM, une NES c'est 2 Ko, une PC Engine c'est 8 Ko, une NeoGeo c'est 64 Ko, pas besoin de plus. Là ou sur un simple ZX Spectrum ou C64 on peut vite monter à 64 Ko de RAM mais sur les micros plus de 90% de la RAM CPU (hors buffer vidéo) sert en général de buffer 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 n'est pas une ROM. C'est un support passif plutôt comme les cassettes et 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énite 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 pouvoir 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 loading qu'on connait bien et qui ont souvent été pointés du doigt. Quand on avait une grosse cartouche avec une grosse ROM (typiquement les jeux NeoGeo), c’était alors comme avoir un énorme buffer RAM à disposition et c'est cet aspect qui sera difficile à reproduire en se passant de ces cartouches car la quantité de RAM contenu dans ces machines pour remplacer la ROM était limité.

 

 

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 64Ko (0.5Mbit). C'est peu (Le Famicom Disk System a un buffer RAM de 32ko pour une capacité de disquette 5000 fois plus faible que les CD) mais à l'époque les HuCard font seulement 2Mbit (les HuCard 4Mbit arrive a peu prêt en même temps que le CD-ROM) et comme il ne s'agit évidement pas de charger l’intégralité du jeu dans ce buffer RAM intermédiaire (un stage + 2 ou 3 trucs suffit) on pourrait se dire que 64Ko 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 64Ko.

Il se trouve que la PC Engine est une machine qui a été beaucoup bridé par la taille des HuCard. La production de HuCard était probablement un process plus rare et coûteux qu'un chip ROM ordinaire et puis le CPU de la PCE est exigent en fréquence d’accès mémoire, il fallait de la ROM de grande qualité. La Master System avait déjà des cartouches 4Mbit depuis quelques temps quand la PCE bien plus performante était encore sur des HuCard 2Mbit donc dans ce contexte c’était effectivement simple pour le lecteur CD-ROM de faire illusion mais qu'en serait il si le potentiel de la PCE avait pu s'exprimer avec des ROM a la hauteur de ses capacités? Les HuCard étant coûteuse l’évolution a été difficile et limité. Les HuCard 4Mbit ont finit par se généraliser mais ça reste trop peu pour le potentiel de la PCE (pour comparaison la série Megaman sur NES c'est dans l'ordre 1Mbit, 2Mbit, 3Mbit, 4Mbit, 4Mbit, 4Mbit). Des HuCard 8Mbit (1Mo) ca commence a être correct pour la PCE (et à mettre à mal le Lecteur CD-ROM et son buffer 64Ko) 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 20Mbit (2.5Mo). Ce n'est pas incroyable non plu comme capacité au vu du nombre de cartouches Megadrive et SNES qui font 16Mbit ou même 32Mbit (voir 48) et c'est seulement 0.4% d'un CD-ROM donc une broutille en comparaison mais pour une HuCard c'est beaucoup et ça a permit à la PCE nu 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 séquences cinématiques sympathiques mais une fois in-game impossible de rivaliser graphiquement avec un jeu comme SF2 qui pose des contraintes particulières (les jeux de combat en général, j'y reviendrais plus loin) et 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. Conscient 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 64Ko (0.5Mbit) à 256Ko (2Mbit). C'est alors 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 sur PC Engine la production de jeux CD prend le pas sur la production de jeux HuCard. Certains diront que le choix de l'HuCard c'est pour toucher un max de joueurs PCE vu la popularité de la licence SF2 mais pour moi il y a aussi ces raisons techniques. A ce moment la 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 2Mo pour un total gigantesque de 2.25Mo (18Mbit) qui cette fois permettrait 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 avec le cas de la NeoGeo. La force de la NeoGeo c'était ses énormes cartouches. La NeoGeo c'est seulement 64Ko de RAM CPU mais pour les raisons que j'ai expliqué, grâce aux énormes ROM de la cartouche, c’était comme avoir un micro ou une console CD avec énormément de RAM (certain jeux NeoGeo atteignent les 90Mo de ROM ou 716Mbit). C'est pour ça que la Playstation et la Saturn pourtant bien plus évolués technologiquement seront bien incapables avec leur 2 ou 3Mo de RAM de faire tourner correctement les gros jeux NeoGeo (La Saturn se verra même affublé d'une extension de RAM de 4Mo pour mieux supporter les jeux de combat). La NeoGeo CD qui embarquait pourtant 7Mo de buffer RAM (on est loin des 64Ko du premier lecteur CD de la PCE) n'était pas capable non plus de reproduire les plus gros jeux SNK (notamment parce que sur ces 7Mo il y a "seulement" 4Mo de RAM graphique). Encore une fois c'était les jeux de combat qui posaient le plus de problème. Un jeu comme King of Fighting 2003 selon mes estimations aurait nécessité 12 ou 13Mo de RAM dans la NeoGeo CD a 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 accessible sur la ROM alors que pour des consoles CD comme la NeoGeo CD ou la Playstation et la Saturn c'est plus du tout les mêmes contraintes de faire du 3 vs 3 car il faut tout faire rentrer dans la RAM.

Pour information le Mega-CD proposait un buffer RAM qui se situe a mi-chemin entre le Super CD-ROM et l'Arcade Card. Quand a 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. Ça aurait pas été fou encore une fois pour les potentiels jeux de combat SNES.

 

 

 

STREET FIGHTER versus STREET FIGHTER II'

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 sauter à 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 20Mbit (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é fait pour relever le défi car le jeu est vraiment optimisé pour faire au mieux avec ce support, c'est pas de ce côté qu'il faut chercher l'explication du faible 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 tuile é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 c'est d'avoir une gestion dynamique de la VRAM. Dans la VRAM se trouve alors uniquement la pose dans laquelle se trouve actuellement les combattants à l'écran et chaque fois qu'un combattant change de pose dans son animation alors on modifie les tuiles en VRAM entre 2 frames pour écraser les précédentes avec celle qui correspond à 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 et pour les jeux de combat c'est vraiment indispensable comme méthode. Mais dans le cas d'un jeu sur CD-ROM ça 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é dans le petit buffer RAM du lecteur CD-ROM car c'est évidemment pas sur le CD, bien trop lent, que le jeu va aller les chercher entre 2 frames, et donc c'est la que ça coince.

 

Street Fighter PCE CD-ROM
Street Fighter II' PCE HuCard

 

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 tuile qui composent chacun des combattants car les tuiles ne sont pas compressés. En effet étant donné la gestion dynamique de la VRAM imposé par ce type de jeu qui nécessite de transférer beaucoup de tuiles entre 2 frames il est alors préférable de ne pas compresser les tuiles pour pas alourdir drastiquement cette tache déjà lourde.

Il y a 12 combattants dans le jeu et 20Mbit dans l'HuCard. Ma première estimation sans comptage, uniquement par rapport à mon expérience était de 1Mbit (128Ko) 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 172Ko (~1.3Mbit) et Honda avec 1259 tuiles soit un peu plus de 157Ko (~1.2Mbit). Ryu et Ken sont pas mal aussi. Au total ils ne pèsent pas très lourd, 186Ko à deux (Ça fait 93Ko chaque si on coupe en 2)  mais en réalité c'est parce qu'ils partagent 114Ko de tileset en commun (+ 36Ko propre a chacun) donc individuellement ils occupent quand même 150Ko et font donc partie des plus gros.

A 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 330Ko rien que pour le tileset des 2 combattants. Ça dépasse déjà largement les 64Ko de buffer RAM du lecteur CD-ROM originel et dépasse même les 256Ko 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 hitbox, le gameplay de chaque combattant, les bruitages (et idéalement avoir le menu de sélection dans le buffer RAM serait sympathique pour éviter trop de loading) on peut arrondir le total à 400Ko. C'est donc à peu prêt 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 la conception du jeu. Seul l'Arcade Card répond (largement) à ces besoins avec ses 2.25Mo de buffer RAM.

 

J'en ai profité pour faire les comptes aussi sur la version Arcade (en arcade les tuiles ne sont jamais compressé étant donné que les chips graphiques y accèdent directement comme sur NES ou NeoGeo) et ça tourne autour de 350Ko 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 tuile juste pour les sprites et 1,5 Mo pour les background). Ainsi ça serait intéressant d'imaginer ce que pourrait donner une version Arcade Card de SF2 (et en utilisant le dotclock 7.16mhz de la PCE pour mieux s'approcher de la résolution 8mhz originelle du jeu). Avec les 2.25Mo 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. 

 

Street Fighter version Arcade

 

Street Fighter PC Engine CD-ROM

 

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é et trop vieux. Il y a un véritable effort d'optimisation, le problème ne vient pas de là.

Dans la version Arcade, le tileset de chaque combattant fait environ 150Ko (ça va de 64Ko a 224Ko 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 tileset des combattants si on voulait être parfaitement fidèle à l'arcade et c'est évidemment loin d’être le cas avec les 64Ko 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 30Ko dédié au tileset cumulé des 2 combattants (bien loin des 400Ko nécessaires). En effet, dans le buffer RAM de 64Ko du CD-ROM il y a aussi d'autres choses à faire entrer (dont le code du jeu) du coup il en reste à peine la moitié pour le tileset 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é de son usage et utilisé tel un buffer CPU pour venir au secoure du CD-ROM (donc de façon peu conventionnel, c'est évidement pas à ça que sert la VRAM normalement) et forme alors une extension du buffer RAM du CD-ROM. Ce sont 24Ko de VRAM (sur les 64Ko) qui vont être détournés pour cet usage et vont alors s'ajouter au 30Ko précédent pour former un buffer (discontinu) de 54Ko pour le tileset des 2 combattants. Ça permet de presque doubler le budget mais ceci se fait au détriment de la qualité du background car ces 24Ko de VRAM "volé" aurait pu servir à augmenter fortement le tileset du background et l'enrichir (voir ajouter un peu d'animation).

En rouge les 24Ko de VRAM détourné de leur usage pour aider le CD-ROM

 

Mais ce n'est toujours pas suffisant. A cela s'ajoute donc l'utilisation d'une forme de compression pour le tileset des combattants. Ça n'a pas l'aire d'une compression RLE mais ça consiste probablement en partie à enlever au moins l'un des 4 bitplans des tuiles (donc passé de 4bpp a 3bpp) 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. C'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.

Un usage très bridé des palettes PCE sur Street Fighter

 

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 bute certainement d'optimiser encore une fois le tileset mais du coup ça demande sans doute une reconstruction software complexe des metasprites. On remarque aussi que l'assemblage des metasprites est curieux. C'est un empilement de sprite de 16x8 ou 32x8 avec donc beaucoup d'overdraw, de superposition de sprite, car normalement les sprites hardware font minimum 16 pixels de haut (pas 8) et sont donc ici utilisé qu'a 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 rappel qu'on est sur un CPU 8bit) ce qui a donc une autre conséquence. A 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é. La pose final de la victoire ne fait pas partie du tileset courant du combattant pour pas l’alourdir (l'animation d'introduction aussi semble t'il). Cette pose est chargé a partir du CD à la fin du combat car elle n'a pas besoin d’être disponible pendant le combat. A chaque round l’intégralité des data sont rechargé de toute façon.

 

Donc on constate quand même énormément d'effort et d'optimisation pour réussir à faire tourner le jeu sur CD-ROM car c’était un vrai défi pour un jeu de combat mais on voit aussi tous les compromis que cela implique. Pas seulement le manque de richesse des animations de combat du à la petitesse du buffer RAM de ce lecteur CD-ROM mais aussi toutes les conséquences plus indirects qui en découlent comme la qualité restreinte du background, la palette appauvrie des combattants, le framerate altéré, les contraintes excessive sur l'overflow de sprite... Tous ces compromis qui n'auraient pas été nécessaires avec une hypothétique version sur grosse HuCard. Et je ne parle même pas des loading jamais agréable é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 a remplir). Et au final si on enlève les pistes audio le jeu ne doit même pas faire 1Mo ce qui est dérisoire au vu de la capacité d'un CD-ROM (640Mo). Ce trop faible buffer RAM ne bride pas seulement la PCE mais aussi l'usage du support CD lui-même, l'un ne va pas sans l'autre.

Street Fighter PC Engine CD-ROM
Street Fighter II' PC Engine HuCard

 

 

Conclusion

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 qui pouvait poser une 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é. Avec des HuCard contenant seulement 1% de la capacité d'un CD-ROM on ferait beaucoup mieux en terme de graphisme in-game qu'on ne pourrait jamais espérer sur cette première version du lecteur CD-ROM² de la PCE (voir mieux aussi que sur le Super CD-ROM). Mais la capacité des HuCard ont toujours été très limitée sans jamais vraiment décoller pour diverses raisons et donc peu ou pas d'opportunité de constater ce paradoxe. En conséquence, le CD-ROM a finalement bien rempli son rôle. Il a pallier autant que possible la faiblesse des HuCard qui bridaient la PC-Engine.

 

 

 

Trivia

Parmi les anecdotes autour de Street Fighter, il y en a une que j'aime beaucoup car elle est assez lourde de conséquence et c'est l'occasion ou jamais pour l'évoquer.
C'est le premier Street Fighter qui a initié le jeu de combat à 6 boutons que Capcom va ensuite réutiliser à foison et qui fait qu'aujourd'hui on trouve ça ordinaire comme configuration, pourtant au départ ce n'est pas du tout un choix de gamedesign, c'est juste un accident. 

Les premières bornes de Street Fighter utilisaient seulement 2 boutons (un pour les poings et un pour les pieds) mais c’était de gros boutons analogiques qui mesuraient la pression et dans lesquels il fallait taper physiquement pour exécuter des coups plus ou moins fort dans le jeu. Mais rapidement il a fallu revoir la copie à cause de la lourde maintenance que ça impliquait et avec laquelle Capcom n’était pas habitué (et aussi de la fatigue pour les joueurs qui ne pouvaient pas jouer longtemps et enchaîner les pièces, ainsi que le coût de la borne). Et comme ces boutons analogiques étaient utilisés pour mesurer seulement 3 niveaux de pression, l'idée était donc de les remplacer chacun par 3 boutons ordinaires ce qui donnait alors un jeu à 6 boutons. Un choix difficile car à cette époque proposer un jeu d'arcade à 6 boutons ça semblait une hérésie en terme de complexité, le meilleur moyen de faire fuir les joueurs, et les cadres de Capcom était vraiment pas convaincu par cette idée mais en réalités ces boutons avaient en quelques sortes tous la même fonction: frapper (et pas à sauter, s'accroupir...) et donc se tromper de bouton avait peu de conséquence. Il a été jugé que ça pourrait être viable malgré tout... 

 

La borne originel de Street Fighter

 

 

Partager cet article
Repost0
Pour être informé des derniers articles, inscrivez vous :
Commenter cet article
X
Merci pour cet article !<br /> Concernant le buffer de 64ko (et ceux plus gros des System Card) : est-ce que le CPU peut l'utiliser comme de la RAM classique, notamment écrire dedabs, afin de ne plus être limité aux 8Ko de base ? Ou est-ce limité à des transferts (DMA?) vers la VRAM, plus du de la lecture seule pour le code du CPU ?
Répondre
U
Salut!. Oui c'est utilisable comme une extension de la RAM. C'est la même chose par exemple sur le Famicom Disk. T'as un buffer RAM de 32 Ko pour remplacer la ROM CPU des cartouches (et 8 Ko pour le PPU) et qui de ce fait peuvent être bien utile aussi pour s'affranchir des 2 Ko de RAM de la console.<br /> D'une façon plus général, du point de vue du CPU les consoles 8/16bit ne font pas de distinction entre RAM de la console et ROM de la cartouche (si ce n'est que si t'essaie d'écrire dans la ROM ca ne sera pas mémorisé mais ca ne fera rien bugger) donc si tu remplace la ROM elle même par de la RAM alors ca devient exactement comme la RAM de la console.
C
Hello,<br /> <br /> Il y a tout de même une différence d'archi au sein des consoles à cartouches. La Neo Geo a un accès direct à la ROM comme si c'était de la RAM, et ne doit que gérer ses palettes. Elle n'a pas une vraie VRAM de travail dans laquelle faire des transformations etc... C'est pourquoi on ne voit aucun effet spécial sur cette machine. Elle peut par contre "streamer un dessin animé" directement depuis sa ROM. Et elle gère le dé-zoom (uniquement dans ce sens) via un système à part de masque de lignes (donc pas via une opération en VRAM).<br /> <br /> La MegaDrive elle dispose d'une VRAM et ne peut travailler son affichage qu'avec ça. C'est aussi le cas de la SNES etc... Il y a donc nécessité de charger les données dans ce "buffer" VRAM même pour ces consoles. Par contre, les autres données intéressantes sont accessibles rapidement donc on peut effectivement charger à la volée en étant malin (ce qui est impossible quand la source est un CD).
Répondre
U
D'ailleurs j'en parle longuement aussi sur mon billet sur Sunsoft car ils aimaient particulièrement exploiter les spécificités de la NES :)
C
Merci je regarde les vidéos à l'occasion. Et en effet, la NES fonctionne selon le même procédé :)
U
Oui tout a fait! :)<br /> C'est d'ailleurs un sujet dont je parle très souvent, je saoule tout le monde avec ca car c'est une nuance effectivement importante à comprendre. J'en parle souvent notamment parce que c'est l'une des forces de la NES qui est quasiment la seule avec la Neogeo a partager cette particularité issu de l'arcade. La ou sur les consoles classiques le port cartouche fait juste passer le bus CPU et une ROM CPU, dans la NES y a aussi le bus PPU qui est câblé directement sur le port cartouche ce qui permet au chip graphique d'accéder directement a une ROM dédié comme sur NeoGeo ou en arcade sans avoir besoin de passer par un buffer VRAM intermédiaire ce qui est bien pratique (sauf que la NeoGeo y a encore bien plus de bus et ROM dédiés, y a 5 bus différents qui passent dans le port cartouche et faut minimum 7 ROM pour les alimenter, dans la NES y a juste 2 bus et 2 ROM minimum contre 1 dans les autres consoles) <br /> Mais pour cette article ca n’aurait fait qu’ajouter de la confusion d’expliquer cette nuance, c’était pas vraiment le sujet mais j’ai pas pu résister a évoquer la Neogeo quand même car effectivement cette particularité renforce encore plus le problème évoqué dans l’article quand on veut remplacer la ROM par un support passif et un buffer RAM, mais ca marche aussi sans cela.<br /> Je saoule tellement les gens avec ca que c’est même devenu le sujet central de la vidéo “Master System vs NES” et aussi “Neogeo vs Playstation / Saturn / CDZ” de la chaine Retro Hardware Studio qui m’avait demandé des conseilles et effectivement je l’avais vraiment dirigé la dessus car c’est une particularité importante a comprendre qui est trop peu connu. Mais en général ceux qui me connaissent finissent par le savoir :D. <br /> https://youtu.be/csvfZEQOUAY<br /> https://youtu.be/2xnp2K2y2go<br /> <br /> Ca devrait te plaire, même si c'est avec ces mots et son interprétation, tu retrouvera tout ce dont tu parles ^^
S
Salut Upsilandre,<br /> <br /> Merci pour cet article dont je suis en pleine lecture.<br /> Je me suis arrêté pour te poser une question : tu parles de l'avantage des consoles 8 et 16 bits avec leurs cartouches de jeu (pas besoin de beaucoup de RAM en plus pour la console elle-même, ...).<br /> <br /> Mais tu parles des avantages d'une cartouche, non ? Pas spécifiquement sur les consoles 8 et 16 bits ?<br /> Par exemple, c'est pareil sur la N64 avec ses cartouches. L'important dans ton point est que ce soit de l'EEPROM, non ?<br /> <br /> Et donc même si ce ne sont pas des CD, ce n'est pas tout à fait pareil avec les cartes flash qui servent de support de jeu pour la Switch, la Vita, la 3DS, ...<br /> <br /> Ou est-ce que je me trompe ?<br /> <br /> Sur ce, je retourne à ma lecture :o<br /> <br /> A+<br /> Seb
Répondre
U
Salut!<br /> Bonne question. Comme tu as remarqué j'ai effectivement parlé des consoles 8bit et 16bit car ensuite les choses bascule doucement. A partir de la N64, et même si c'est encore de la ROM, les cartouches sont utilisé comme un support passif (comme des CD très rapide). Le CPU n'accède plus directement au contenu de la cartouche. La ROM n'a plus des performances adapté je pense et puis le contenu de la cartouche est systématiquement sous une forme compressé (car on manque de place) et passe par une phase de décompression en RAM. Et c'est seulement une fois bufferisé en RAM que tout ça peut être exploité comme pour un CD. C'est encore plus vrai pour les cartes flash qui ne sont plus du tout adapté a un accès direct par le CPU. Les dernières consoles a cartouche "active" sont les consoles portables comme la GBA, Wonderswan, NeoGeo Pocket (a partir de la DS c'est terminé). En console de salon y a la Jaguar qui est encore un peu entre les 2 je crois (mais a l'usage je pense que les cartouches sont déjà utilisé de façon passive).
D
Très bon article encore une fois. Dans ma jeunesse, j'ignorais tous détails sur la pc engine même si j'étais un fidèle lecteur de Micro News. Est ce que ce système de Hucard, certes, très joli n'est pas au final une erreur. C'est dommage quand on voit la version de shinobi complètement tronquée ! <br /> <br /> Par curiosité et comme cela fait plusieurs fois que j'entends parler de ce jeu (il est abordé dans le podcast MO5 sur la pc engine), je me suis lancé un longplay sur art of fighting. Ben , ça pique les yeux quand même... cet espèce de zoom/dézoom en changeant de résolution ... horrible !
Répondre
U
merci. C'est vrai que ce zoom est pas tres agréable mais l'idée est techniquement amusante et ils pouvaient pas vraiment faire mieux :) (a part effectivement ne pas faire de zoom). et puis c'est peut etre le jeu qui profite le plus de l'arcade card (y a aussi ce shmup bourré de rotation et de zoom sur les sprites).
S
Upsilandre, 1000 mercis pour ce dossier documenter et précis dont la gamme PCE avait besoin. Combien de fois ai-je cherché à expliquer sur divers forums en quoi le CD était en réalité un handicap.
Répondre
U
Oui je vois bien le coté arithmétique de la question. Heureusement quand meme que le Super CD est arrivée :)
S
La raison est purement arithmétique : le SCD est sorti moins de 3 ans après le CD, qui a donc eu une carrière assez courte. Mais il est vrai qu'on sent bien dans la ludothèque que plus de jeux d'action ont pu être développés sur SCD mais il n'en reste pas moins que des jeux tels que Spriggan, Shubibinman 3, L-Dis et Terraforming (qui est un jeu CD malgré le logo SCD) affichent de bien belles choses à l'écran.<br /> <br /> De manière plus globale, j'avais fait des statistiques sur le genre de jeux par support et sans surprise, la ludothèque HuCARD est en grande partie tournée vers l'arcade quand la ludothèque CD/SCD fait principalement la part belle aux
U
Merci ^^ C'est difficile de dire si c'est un handicape, en théorie oui, en pratique c'est compliqué car les HuCard était vraiment trop petite malheureusement et puis le CD-ROM a évolué au fil des versions. D'ailleurs j'ai tendance a penser que le catalogue de jeu CD est principalement sur SCD, pas tellement sur CD, c'est plutôt vrai ou pas?