Il ne fait aucun doute qu’à l’époque, une telle cartouche aurait coûté très cher à produire en série pour la distribution de jeux, mais Amstrad aurait peut-être pu en concevoir une en guise de démo spectaculaire à présenter lors de salons professionnels et d’événements promotionnels. Cela aurait probablement stimulé les ventes et suscité un plus grand intérêt pour les cartouches ROM.
Juste pour comparer avec la saga Street Fighter 2 sur 16 bits qui à chaque fois repoussait les standards:
1992: Street Fighter 2 SNES 16mb => 2mo
1993: Street Fighter 2 turbo SNES 20mb => 2,5mo
1993: Street Fighter 2’ Megadrive 24mb => 3mo
1994: Super Street Fighter 2 SNES 32mb => 4mo
1994: Super Street Fighter 2 Megadrive 40mb => 5mo
1998: Street Fighter 2 Master System (Tectoy) 8mb => 1mo
Sur Master System, après l’arrivée de la Megedrive on a vu sortir pas mal de jeux 4mb qui ont grandement amélioré la qualité des jeux: Mickey 2, Donald 2 etc… La taille de la cartouche n’est pas seulement un argument marketing.
J’ai une autre question sur Vespertino: comme le jeu ne sort que sur cartouche avec du hardware dédié, est-il envisageable d’avoir un “Vespertino Multiplayer” avec un connecteur sur la cartouche permettant de relier plusieurs CPC ensemble ? Comme pour Vroom, Lotus 2 etc… Sur 16bits ?
Une carte mère de CPC 464 à l’intérieur d’une véritable borne d’arcade en 1986… imaginez un peu ça !
Vespertino ressemble à s’y méprendre à un jeu d’arcade Out Run en Mode 0. Imaginez entrer dans une salle d’arcade et découvrir une borne alimentée par une carte mère de CPC 464, à une époque où tant de gens jouaient à des jeux comme Sorcery et Cauldron II. Et tout cela avant même la sortie d’Out Run plus tard en 1986.
Pourquoi diable ferais-tu une chose pareille ? Les jeux d’arcade basés sur le Z80 étaient déjà archaïques en 1986. La seule chose pour laquelle le Z80 servait encore à quelque chose, c’était en tant que coprocesseur audio sur les cartes System 16. Ironiquement, comme c’était le cas pour Outrun.
Je ne me suis peut-être pas bien fait comprendre. Je sais bien que 4 Mo de ROM et 512 Ko de RAM représentent une quantité gigantesque de mémoire supplémentaire. C’est d’ailleurs en partie ce qui rend Vespertino si remarquable, et peut-être sujet à controverse. Cela aurait été bien trop cher pour l’utilisateur lambda en 1986, mais tout à fait envisageable pour une borne d’arcade dédiée.
Vespertino ne triche pas en utilisant cette cartouche. Il exploite un matériel qui aurait très bien pu être intégré dans une borne d’arcade. Et c’est précisément là où je voulais en venir : au vu du résultat absolument stupéfiant, offrant une expérience digne d’un jeu d’arcade comme Outrun, j’estime que cette cartouche est totalement justifiée.
Je peux au moins rester très impressionné par le rendu fluide de la route complète à 25 Hz, qui tourne sur un simple Z80 et CRTC, donc cette partie-là n’est pas améliorée. La ROM/RAM supplémentaire sert peut-être à obtenir des animations fluides et d’autres choses du genre. Ça me fait aussi me demander ce qu’on pourrait réaliser sur GX4000 avec la ROM supplémentaire (même 512 ko, c’est énorme pour moi) et sur Sam Coupé avec 512 ko de RAM.
512 ko de ROM et 64 ko de RAM dans une GX4000, c’est une quantité de mémoire respectable pour un système 8 bits. Presque personne ne l’a pleinement exploitée jusqu’à présent, ce qui en revient à mon point de départ : plus de mémoire ouvre des perspectives, mais ne produit rien d’impressionnant en soi sans une charge de travail considérable pour remplir cet espace avec du contenu de qualité.
Mis à part la mémoire, je pense que Rhino a prouvé ce qu’il avançait : l’architecture du CPC n’est pas trop lente si on l’utilise intelligemment. Ou du moins, elle peut donner l’illusion de ne pas l’être.
Je pense que tout le monde peut voir que le tiers supérieur de l’écran est en grande partie statique, que le tiers du milieu utilise un défilement matériel consommant très peu de CPU, et que le tiers inférieur concentre toute l’action.
Quand le projet a été teasé pour la première fois, je me suis demandé s’il mettait à jour la route à l’aide de deltas et s’il utilisait des changements de palette pour ajouter les bandes. Mais tourner à 25 Hz rendrait cela moins efficace, car les effets de raster doivent de toute façon être calculés à chaque image. Et sans PRI, ce serait un vrai calvaire de maintenir la synchronisation sans gaspiller énormément de cycles CPU.
De plus, comme les sprites ne sont pas masqués, je vois bien que ce n’est pas le cas ; je suppose donc que cette portion entière de l’écran est simplement redessinée très rapidement, sans doute en passant par la pile et en utilisant quelques autres astuces pour rendre le tracé aussi efficace que possible.
Eh bien, Amstrad en parlait au moins dans ses publicités.
