L'essentiel
Un combat de Street Fighter II' Champion Edition tourne sur un Amiga 1200 de série (68020 à 14 MHz, 2 Mo de mémoire, aucune extension), identique à la borne d'arcade au pixel près : 384 × 224 pixels, 182 couleurs. En 1992, c'était le jeu que l'Amiga ne savait pas faire. Aujourd'hui, il tourne à 16,5 images par seconde, et pratiquement à la vitesse de la borne (99,6 %) quand on montre une image arcade sur quatre. Avec une carte accélératrice 68030 de 1994, il atteint 20 images par seconde. Ce n'est pas de la nostalgie, c'est un cas d'école : l'IA ne remplace pas la machine, elle permet enfin d'en exploiter chaque cycle.
Pourquoi l'IA change la donne
Optimiser un Amiga, c'était autrefois le travail de quelques experts de la démo, pendant des mois. Ce qui a changé, c'est le coût d'une idée : l'essayer, la mesurer et la vérifier prend maintenant quelques minutes.
- Lire la borne. Les données du jeu sont extraites de la ROM arcade avec l'émulateur MAME, image par image, au lieu d'être redessinées à la main.
- Écrire l'assembleur. Le moteur est en assembleur 68020, environ 1 200 lignes, sans compilateur. Chaque idée est écrite, mesurée, gardée ou jetée.
- Tout vérifier. Chaque version est rejouée dans un émulateur de processeur 68020 et les 639 images sont comparées à l'arcade. Une seule erreur de pixel et la version est refusée.
- Croiser les avis. Plusieurs IA relisent le même code. L'une a proposé de piloter la conversion par la liste des zones à redessiner, une autre a fouillé GitHub et retrouvé les techniques de Mikael Kalms et du jeu Gloom, vieilles de trente ans.
L'humain garde la main : il fixe la règle (pas un pixel de différence), juge à l'œil et tranche entre fluidité et fidélité.
Le défi : une borne contre un ordinateur familial
La borne CPS-1 de Capcom n'est pas beaucoup plus rapide qu'un Amiga 1200. Sa force est ailleurs : des puces dédiées dessinent le décor et les personnages à chaque image, sans que le processeur s'en occupe.
| Borne CPS-1 (1992) | Amiga 1200 de série (1992) | |
|---|---|---|
| Processeur | 68000 à 10 MHz | 68EC020 à 14 MHz |
| Écran | 384 × 224, 59,6 images/s | 384 × 224 en PAL, 50 images/s |
| Couleurs dans ce combat | 182 | 256 au maximum, en 8 plans de bits |
| Décor | 3 couches dessinées par le matériel, défilement ligne par ligne | à recalculer au processeur, pixel par pixel |
| Personnages | sprites matériels, en nombre | 8 sprites matériels étroits, inutilisables ici |
| Mémoire | mémoire graphique dédiée | 2 Mo partagés par tout le monde |
Ce qu'on a tenté avant
Les versions et démos Amiga que nous avons retrouvées ont toutes redessiné ou simplifié le jeu.
- U.S. Gold, 1995, Super Street Fighter II. Deux versions, dont une pour l'A1200, avec de meilleures couleurs et musique et bruitages ensemble. Graphismes et décors refaits (RQ87).
- Dennis Ramberg et Titan, 2021. Un moteur graphique pour montrer ce qu'une conversion arcade « aurait pu être » sur A1200, présenté en vidéo (Indie Retro News).
- NeesoGames, 2022. Une démo jouable pour Amiga OCS/ECS avec les graphismes de la version Super Nintendo, 256 pixels de large, en mode EHB. Nous l'avons fait tourner : plus fluide, mais nettement moins fidèle (itch.io).
Notre approche est différente : ne rien redessiner, et prouver que chaque image affichée est celle de la borne.
La méthode : extraire, pas redessiner
On part de la ROM de Street Fighter II' Champion Edition (révision World 920513) et du combat du mode démonstration : Ken contre Guile, 1 917 images arcade.
- MAME enregistre la borne. À chaque image, on relit la mémoire graphique et les registres vidéo, sans rien modifier.
- Un moteur de rendu indépendant recalcule chaque image et retrouve celle de MAME.
- Le programme Amiga est vérifié dans un émulateur 68020, avec un Blitter émulé qui ne termine ses copies qu'au dernier moment possible : la moindre erreur de synchronisation se verrait. Chaque image est comparée à l'arcade, pixel par pixel.
- WinUAE en mode cycle-exact fait tourner le programme sur un A1200 de série et mesure la vitesse.
C'est un rejeu : positions et animations viennent de la borne. Il n'y a encore ni commandes ni intelligence artificielle de combat. Cette exigence de fidélité interdit les raccourcis habituels, et rend chaque image par seconde beaucoup plus dure à gagner.
Premier mur : une seule mémoire pour tout
Sur un A1200 sans extension, un accès à la mémoire coûte environ 10 cycles du processeur. Et tout passe par cette mémoire Chip : le programme, les données, l'image en calcul, les écrans, le Blitter et l'affichage lui-même. Le cache du 68020 ne fait que 256 octets, pour les instructions seulement. La vitesse ne dépend donc pas du nombre de calculs, mais du nombre d'accès mémoire : toute l'optimisation consiste à les éviter.
Deuxième mur : des pixels aux plans de bits
La borne range un pixel par octet. L'Amiga découpe l'image en 8 plans de bits : chaque pixel est éparpillé à 8 endroits de la mémoire. Il faut dessiner en pixels, puis tout convertir, ce que les programmeurs de démos appellent le C2P (« chunky to planar »). Notre conversion travaille par blocs de 16 pixels en une seule passe qui tient dans le cache : 4 lectures, 10 opérations de fusion et 8 écritures par bloc, avec les écritures intercalées entre les calculs comme le faisait Mikael Kalms.
Troisième mur : le sol en perspective
Le sol du niveau de Guile défile à une vitesse différente sur chaque ligne. La borne le fait gratuitement. Sur Amiga, le défilement matériel ligne par ligne ne laisse que 8 pixels de marge à 384 pixels de large : nous l'avons testé, puis abandonné. Le Blitter recopie donc l'image précédente ligne par ligne, avec le bon décalage, et le processeur ne redessine que les blocs qui diffèrent encore.
Ce qui a payé
Tous les gains viennent de la même idée : moins d'accès à la mémoire Chip. Les zones à redessiner sont calculées d'avance en comparant les images de la borne. Le plus gros gain est venu d'un coût invisible : le Blitter recopiait tout l'écran à chaque image et occupait le bus pendant que le processeur travaillait. Avec trois écrans, celui qu'on redessine contient déjà l'image d'il y a trois coups : pour chaque ligne, le choix est calculé d'avance entre la garder et la recopier.
Plusieurs idées séduisantes ont été mesurées puis abandonnées : garder un fond sans personnages (plus lent), sauter le décor caché derrière les personnages (trop de mémoire), lancer les copies d'une image pendant sa propre conversion (plus lent : la conversion devait attendre les copies).
Quatrième mur : le Blitter et le processeur se disputent le bus
Une mesure a tout éclairé. Sans les copies du Blitter (image fausse, chronométrage seul), le processeur termine son travail en 786 lignes d'écran par image. Avec elles, il lui en faut 990. Le Blitter recopie 146 lignes d'écran par image et occupe le bus pendant environ 310 lignes : chaque fois qu'il prend la mémoire, le 68020 attend. Lui donner la priorité absolue est pire (1 081 lignes), car le processeur reste alors bloqué.
La parade : faire travailler le Blitter quand le processeur calcule au lieu de lire et d'écrire. La conversion en plans de bits est la phase la plus calculatoire. On y lance donc les copies de l'image suivante, par tranches de 32 lignes, chacune seulement quand la conversion a terminé ses lignes sources. Le gain est réel mais limité : le bus est saturé, et chaque cycle rendu à la composition est en partie repris à la conversion. Préparer hors ligne la file de copies et accélérer la copie des tuiles animées du décor a fait gagner 24 lignes de plus. Résultat : 947 lignes par image, soit 16,5 images par seconde, et une image arcade sur quatre à 99,6 % de la vitesse de la borne.
Le vérificateur a été durci pour que cette accélération ne coûte aucun pixel. Dans l'émulateur 68020, une copie du Blitter ne se termine que quand le programme la consulte, et toute écriture dans sa source ou sa destination avant la fin arrête le test. Retirer volontairement la barrière de lignes déclenche l'arrêt immédiat.
Ce qui n'a pas marché, mesures à l'appui : découper les copies pour sauter les zones redessinées (953 lignes : plus de copies à préparer que de mémoire économisée) ; passer à 7 plans de bits (le combat dépasse 128 couleurs, jusqu'à 97 sur une seule ligne) ; recalibrer le choix entre garder et recopier une ligne (aucun effet). Une piste reste ouverte : 45 % des pixels de décor recomposés à chaque image finissent cachés sous les combattants.
Où on en est
Sur un A1200 de série, le combat tourne à 16,5 images par seconde en montrant une image arcade sur trois, soit 83 % de la vitesse réelle. Montrer moins d'images arcade, chacune toujours exacte, rattrape le temps réel : une sur quatre suffit presque (99,6 %).
| Machine et réglage | Images/s | Vitesse du combat |
|---|---|---|
| A1200 de série, 1 image sur 3 | 16,5 | 83 % |
| A1200 de série, 1 image sur 4 | 14,8 | 99,6 % |
| A1200 de série, 1 image sur 5 | 12 | 100 % |
| A1200 + carte 68030 à 50 MHz et mémoire Fast, 1 image sur 3 | 19,9 | 100 % |
Les lignes « 1 sur 5 » et « 68030 » ont été mesurées sur une version précédente du moteur (15,5 images/s en 1 sur 3) ; la vidéo a été filmée avec la version à 15,8 images/s. Toutes les images affichées sont vérifiées identiques à l'arcade dans l'émulateur 68020.
La dernière ligne répond à une vieille question : avec une carte accélératrice de 1994, l'A1200 aurait fait tourner Street Fighter II arcade à pleine vitesse. Il ne lui manquait pas la puissance, il manquait la méthode. Cet article est mis à jour à chaque nouvelle mesure.
À vous : une idée pour gagner des images ?
Vous avez programmé l'Amiga, écrit des démos, des routines C2P, des moteurs AGA ? Le défi est ouvert : gagner des images par seconde sur un A1200 de série sans changer un seul pixel. Les contraintes : 68020 à 14 MHz, 2 Mo de mémoire Chip sans mémoire Fast, 384 × 224 en 8 plans de bits, 182 couleurs. Chaque idée publiée sera mesurée, et nous répondrons ici avec le résultat.
Idées reçues
Aucune idée publiée pour l'instant. Soyez le premier.
Questions fréquentes
Le jeu est-il jouable sur l'Amiga 1200 ?
Pas encore. C'est un rejeu : les positions et les animations viennent de la borne, enregistrées dans l'émulateur MAME. L'affichage est terminé et vérifié image par image ; les commandes, les collisions et l'intelligence artificielle restent à faire.
Peut-on télécharger cette version Amiga ?
Non. Les graphismes et les données du jeu appartiennent à Capcom : nous montrons la technique et les mesures, nous ne distribuons ni la ROM ni l'exécutable qui en contient les données.
Pourquoi l'Amiga 1200 n'atteint-il pas 20 images par seconde ?
Parce que, sans mémoire Fast, le processeur, le Blitter et l'affichage se partagent la même mémoire Chip, et chaque accès coûte une dizaine de cycles. Avec une carte 68030 à 50 MHz et de la mémoire Fast, le même programme atteint 20 images par seconde et la vitesse réelle de la borne.
Qu'a apporté l'IA dans ce projet ?
Le coût d'une idée : chaque optimisation est écrite en assembleur 68020, rejouée sur les 639 images et chronométrée dans un émulateur cycle-exact en quelques minutes. Plusieurs IA ont relu le code et retrouvé des techniques de démo vieilles de trente ans ; la règle (pas un pixel de différence) et le jugement restent humains.
Sources : pilote CPS-1 de MAME et son rendu vidéo · WinUAE · conversion chunky vers planar, Mikael Kalms · RQ87, versions Amiga de Super Street Fighter II · NeesoGames. Mesures : OutilsIA, 24 et 25 octobre 2026, WinUAE 6.0.3 cycle-exact, ROM libre AROS. Street Fighter II est une marque de Capcom ; Amiga est une marque de ses détenteurs actuels. OutilsIA n'est affilié à aucune de ces sociétés.