Voilà, le moteur de Super Tilt Bro. est capable de supporter plusieurs personnages. C'est une bonne tranche de boulot abattu, mais je crains qu'il n'y ait rien à montrer. Pas de ROM contenant des centaines de personnages et autant d'heures de jeu. C'est pour l'instant "juste" une possibilité offerte par le moteur. Et c'est bien de ça dont on va parler : quelles sont les difficultés d'implémentation et comment Super Tilt Bro. s'en sort.
Bon, d'accord il y a bien un second personnage "jouable", Squareman le perso qui ne fait rien.
Mais pourquoi permettre plusieurs personnages ?
Réponse courte : parce que c'est trop coooool !
À vrai dire, permettre au joueur de choisir entre plusieurs personnages a été envisagé dés le début de Super Tilt Bro. Cependant, c'était un rêve inaccessible. Outre la masse de travail considérable, il faut tenir compte de la taille limitée de la ROM. Sinbad occupe 6 Kilo-octets, avec le reste du jeu, Super Tilt Bro. v1 ne dispose plus d'assez d'espace libre pour un second comme lui. Autre problème, la mémoire vidéo. La mémoire vidéo est aussi une ROM, qui contient 256 tiles, Sinbad en utilise 94. On ne pourrait pas y faire tenir les graphismes pour plus de deux personnages sans une grosse passe d'optimisation.
Mais les temps changent ! Super Tilt Bro. v2 est sur une plus grosse cartouche. 512 Kilo-octets au lieu de 32, ça donne des ailes. Quant à la mémoire vidéo, elle on ne peut pas l'agrandir de façon magique. Ce qu'on peut faire c'est mettre de la RAM à la place de la ROM vidéo. Grâce à ça, on peut n'y mettre que les tiles des personnages réellement utilisés. Et puis enfin, si Super Tilt Bro. v1 était l'occasion de voir ce qui pouvait être fait avec une NES, la v2 est l'occasion de repousser les limites !
Et puis bon... Plein de persos, c'est trop cool !
Et donc, comment fait-on fonctionner un jeu qui propose plein de persos ?
Le premier point à poser problème est le stockage des personnages. En effet, le CPU de la NES accède à une ROM de 32 Kilo-octets. Si on veut une ROM plus grosse, il faut tricher. L'astuce est d'embarquer une ROM plus grosse dans la cartouche. Le CPU ne pourra voir qu'une partie de cette ROM. À tout moment, on peut changer la partie visible de la ROM, ainsi on a accès à tout l'espace de stockage.
C'est l'idée du bank-switching. Concrètement, on sépare l'espace de la cartouche en blocs de 16 Kilo-octets (les banques). On peut donc faire tenir deux banques dans les 32 Kilo-octets visibles par le CPU. Une des banques est toujours visible par le CPU, on l'appelle la banque fixe. L'autre banque visible par le CPU peut être changée à tout moment.
La cartouche de Super Tilt Bro v2 est énorme !
La stratégie de Super Tilt Bro. pour le stockage des personnages dans différentes banques est simple. Toutes les données propres à un personnage doivent se trouver dans la même banque. Dans la banque fixe on stocke une table indiquant dans quelle banque se trouve chaque personnage. Ainsi quand on a besoin des données d'un personnage, on saura toujours les retrouver.
L'index stocké dans la banque fixe permet de savoir dans quelle banque sont les infos sur un personnage.
Le problème de la mémoire vidéo est traité différemment. Non seulement on ne pourrait pas y faire tenir assez de sprites pour tous les personnages, mais le système de banques poserait d'autres problèmes. Tous les personnages présents à l'écran doivent être visible en même temps dans la mémoire vidéo, le PPU en a besoin pour les afficher, or un système de banque ne permet pas un contrôle assez fin pour choisir deux personnages à afficher. La solution sera d'utiliser de la RAM vidéo. Au lancement de la partie on écrit les tiles des deux personnages sélectionnés au début de la RAM vidéo, et voilà !
Et ce n'est pas fini !
Bon, on a un moteur capable de gérer plein de personnages. La prochaine étape logique est de créer plein de personnages super stylés ? Eh bien non. Actuellement, créer un personnage signifie écrire beaucoup d'assembleur (pour coder ses attaques) et de binaire (pour ses graphismes et animations). C'est long, fastidieux et empêche de se concentrer sur le personnage lui-même. Il va donc falloir rendre ce processus plus simple.
La prochaine étape sera donc de créer des outils. D'abord un format de données pour stocker toutes les infos sur un personnage dans un fichier, qui sera automatiquement "compilé" en assembleur. Ensuite, ce qui serait super sympa serait un éditeur de personnage dans lequel on peut simplement dessiner les attaques du personnage qu'on veut créer pour générer une ROM jouable.
Enfin, une fois bien outillé, faire un second personnage sera envisageable. Non seulement ça sera plus simple qu'en assembleur/binaire, mais ça servira aussi d'épreuve du feu pour l'éditeur.
Bref, le but est de présenter un nouveau personnage pour la RGC-2019. Le timing semble bon, reste à voir si ça sera plus rapide ou plus lent que prévu
