Dans les premiers temps du jeu vidéo console la norme était le 60fps que ce soit sur VCS ou NES. La façon dont le hardware de l'époque construit l’image implique que le 60fps s’imposait comme choix de bon sens. Ca n'empêchait pas certain jeu de viser plutot le 30fps pour libérer des ressources CPU mais c’etait une minorité. Et d’autres de viser encore moins comme le culte Ghosts’n Goblins NES et ses 20fps car (mal) sous traité a Micronics ou un Ikari Warriors a 15fps maltraité par les même Micronics mais se sont la des accidents de programmation (Different du cas de Elite en 3D qui justifie techniquement son faible framerate)
Et puis y a les jeux qui visent le 60fps mais qui les tiennent approximativement. La série Megaman en fait partie avec un résultat variable selon l'épisode notamment avec le cas Megaman 3, le pire des 6, et qui interroge. Je me suis alors amusé a écrire des script Lua pour l'émulateur Mesen qui permet de visualiser le framerate et les ressources CPU pendant qu’on joue a Megaman 2 (le plus stable de la série) et Megaman 3 (le pire). Et ainsi de mieux comparer les différences.
Mon script affiche le framerate en temps réel ainsi que les ressources CPU. A la fois sous forme de chiffre mais aussi de graph. Il calcule aussi la moyenne de framerate et de ressource CPU sur toute la session. Et y a 3 modes de visualisation switchable directement avec le bouton SELECT du controleur (Par chance Megaman ne l’utilise pas) avec notamment un mode “discret” qui se contente d’afficher les fps dans un coin. L’avantage de ce genre de script c’est que j’utilise différents marqueurs internes au code du jeu ce qui permet d’avoir un monitoring très précis et fiable, indépendant du framerate réel de l’émulateur ou de l’affichage, et qu’on peut contextualiser (Ici le monitoring ne s’active que pendant les phases in-game pour pas avoir un monitoring des phases d’ecrans intermédiaires, écrans titres, menus... qui ne sont pas pertinentes et fausseraient même la moyenne)
Je vous invite a l’essayer sur Megaman 2 et vous verrez que le jeu est plutot stable, on le prend rarement en défaut. Ca participe certainement aussi a la tres bonne réputation de cette épisode (en plus d'être un épisode vraiment full screen, y a pas de bande noir a gauche, et sans glitch de scrolling sur les bords, contrairement aux épisodes suivants). Je rappel aussi que j’ai fais un patch pour améliorer le menuing :). Pour l’anecdote le passage sous l’eau chez Bubbleman simule l’inertie de l’eau en dropant volontairement des frames (1 sur 5 soit un framerate de 48fps) pour ralentir le jeu. Une astuce surprenante. J’ai fais le choix dans le script de ne pas compter ces drops volontaires et de compter uniquement les drops involontaires subit par le jeu.
L'inertie de l'eau simulé par une chute de framerate volontaire
Alors qu’en essayant le script sur Megaman 3 (je vous conseille de tester sur le level Topman par exemple) Vous allez voir des drops assez fréquents parfois pour un rien et c’est peu de le dire car on trouve même des situations incongru ou tout est statique, ecran fixe sans scrolling, pas d’ennemis, on ne bouge pas, on ne fait rien (meme le tileset est statique), y a juste des items au sol et ca suffit a surcharger complètement le CPU et a faire tomber le framerate a 30fps.
En haut le graphique FPS en rouge qui varie entre 30 et 60 fps
Chaque fois qu’on ramasse un item on allège sensiblement la scène et augmente le framerate. On voit mieux le comportement interne en regardant le graph des ressources CPU qui nous donne la charge CPU pour chaque frame. Chaque fois qu’une frame dépasse la barre des 100% de ressource CPU ca signifie qu’elle nécessite plus du temps d’une frame pour etre prête et c’est donc la qu’on a un drop, la frame précédente sera donc affiché 2 fois pour compenser ce retard. On voit bien ici le gain de ressource a chaque item ramassé.
Ici le graph de ressource CPU qui doit rester en dessous de 100%
C’est tres intriguant, ca donnerait envie de regarder de plus pret le code pour comprendre qu’est ce qui prend autant de ressource. C’est comme si chaque objet aussi insignifiant soit t’il (ici des items statiques et de taille tres réduite) prenait autant de ressource qu’un ennemi. Ca trahis peut etre la volonté de Capcom a l’epoque de vouloir un moteur de plus en plus universel et recyclable sur plusieurs projets ce qui les aurait poussé a peut etre ajouté toujours plus de flexibilité dans leur moteur en rajoutant des couches qui ont finit par etre trop couteuse. Y a vraisemblablement eu des corrections pour les épisodes suivants.
En tout cas sur cette épisode ont est typiquement dans la situation ou les drops deviennent parfois vraiment gênant pour le gameplay puisque a cette époque la un drop signifie aussi un ralentissement du jeu (plus tard sur les générations suivantes on dissociera framerate et vitesse). La fréquence des drop est trop fréquente et aurait justifié de caper le framerate a 30fps pour avoir une vitesse de jeu stable. Le jeu aurait sans doute été plus agréable et le 30fps ca passe encore tres bien mais ca aurait fait tache au milieu de la série et puis ca aurait modifié l’input lag caractéristique de la série qui se veut réglé au plus court que ce soit pour le saut ou le shoot.
C’est dommage car Megaman 3 est vraiment un tres bon Megaman. C’est notamment le seul a proposer la glissade mais sans le charge-shot et autant je suis mitigé par l’apport du charge-shot, autant la glissade c’est vraiment un apport majeur. C’est complètement cohérent avec la philosophie de Megaman. Megaman est jeu qui volontairement n’autorise pas le joueur a se baisser pour esquiver les tires afin de forcer le joueur a être toujours dynamique et beaucoup sauter. La glissade vient alors ajouter une esquive alternative mais toujours sans rompre la dynamique. On peut cette fois passer sous un ennemi pendant qu’il saute (ou dans un passage étroit) mais c’est toujours dans le mouvement. Ca permet aussi de faire un mouvement latéral rapide pour esquiver une attaque vertical. Et tout ca est en plus tres bien exploité dans cette épisode au travers des patterns ennemis, des boss et du level design. Niveau gameplay c’est pour moi la meilleur combinaison de la série, la glissade mais sans le charge-shoot (qui lui a l’inverse a tendance a cassé un peu la dynamique).
Mais y a quand même une solution si on veut jouer a Megaman 3 dans des conditions parfaite. L’émulation permet l’overclocking. Sur Mesen vous avez 3 façons d’overclocker dans le menu Options > Emulation > Overclocking. Il ne faut pas overclocker le CPU seul car on perd la synchronisation avec le GPU, ca ne peut rien donner de bon. Il faut overclocker les 2 et dans Mesen ca se fait en ajoutant virtuellement des scanlines. Sur Mesen on peut choisir d’ajouter des scanlines avant le Vblank (avant le NMI) ou pendant le Vblank (apres le NMI) selon le goulot étranglement. En théorie faut toujours choisir plutot d’en ajouter avant le Vblank si on veut améliorer le framerate sans glitcher le jeu mais dans le cas de Megaman vous pouvez les ajouter pendant le Vblank ca ne cause pas de problème ici et permet de résoudre n’importe quelle type de drop.
Avec cela a vous la joie du 60fps infaillible!
Pour Megaman 3 ajoutez 200 scanlines (ce qui donne un overclocking de + 76%) comme indiqué sur le screenshot pour etre certain d’avoir aucun drop et ainsi avoir du 60fps parfaitement stable. Pour Megaman 2 100 scanlines suffiront. Voila une comparaison avant et apres overclocking sur une autre scène problématique du jeu sans raison.
Sans overclockingAvec overclocking
Pour lancer un script dans Mesen il faut d’abord lancer le debugger et c’est dans le debugger que vous avez accès a cette outil de script (vous pouvez ensuite refermer le debugger, c’est même préférable). Mais y a aussi la possibilité de cocher une case dans les préférences de Mesen qui permet d’activer le mode “développeur” qui fait apparaître un nouvel onglet dans Mesen qui vous donne alors un acces direct a tous les outils débug sans passer par le debugger, c’est ce que je vous conseille.
Et le lien vers Mesen: https://www.mesen.ca/ . Si vous faite de l'émulation NES vous pouvez avoir d’autres émulateurs pour divers raison mais il vous faut aussi celui ci sous le coude, c’est un incontournable :).
avec une telle différence de temps CPU par item dans MegaMan 3, on devrait déjà voir des choses intéressantes rien qu'avec un script qui calcule une "heat map" des adresses pour le Program Counter, non ?
Mesen est deja capable de donner des mesures sur les accès en lecture et écriture de chaque adresse (mais je sais pas si c'est a ca que tu penses?). Sinon y a un second article sur cette histoire de Megaman qui donne quelques réponses ^^
. Pour l’anecdote le passage sous l’eau chez Bubbleman simule l’inertie de l’eau en dropant volontairement des frames (1 sur 5 soit un framerate de 48fps) pour ralentir le jeu. Une astuce surprenante. J’ai fais le choix dans le script de ne pas compter ces drops volontaires et de compter uniquement les drops involontaires subit par le jeu.
/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)