[NES] Hack UI Megaman 2

[upsilandre]

J'ai longtemps repoussé la tache astronomique d'explorer les Megaman NES puis je m'y suis mis serieusement et je suis tombé in love de la serie que je trouve vraiment fun (alors que j'etais un peu sceptique auparavant) .
MM2 est le plus apprécié des Megaman et y a des raisons valables pour ca. Par contre il a au moins un defaut c'est son menuing. Dans les Megaman on fait beaucoup de menuing qui casse le rythme, celui de Megaman (menuing 1D sur 2 pages) est assez pénible. Du coup etant devenu fan du jeu je me suis dit pourquoi pas tenter de l’améliorer (sans savoir si c'etait a ma porté, il etait pas question d'y passer un temps fou).
L'idée c'etait ca (ici l'exemple ou tu es equipé de l'arme de Woodman et tu veux franchir un obstacle avec l'item 1)


Et effectivement ca marche. J'ai réussi a modifier l'UI pour avoir un menuing 2D ou l'on change de page simplement avec "gauche" ou "droite". En gros simplement utiliser tout le D-pad au lieu d'en utiliser que le moitié, c'est du bon sens. Et finalement ca n'a pas ete si compliqué (ouf) ce qui rend la chose encore plus étonnante. Pourquoi les devs n'ont pas fait comme ca? Parce que ca améliore vraiment l'experience de jeu.

Grace au code/data logger j'ai rapidement identifié un bloc de 1565 octets dans la derniere bank de la ROM de la cartouche qui n'etait pas utilisé et il se trouve qu'avec le mapper MMC1 la dernier bank c'est la bank fixe donc c'est vraiment idéal comme situation. un bloc continu de 1565 octets libre dans la bank fixe que demander de mieux.
Apres avoir identifier 20-25 variables et repérer des bouts de code j'ai dérivé le code de gestion du menu vers ce bloc libre ou j'ai mis mon propre code. Je n'ai meme pas utilisé 10% de l'espace (142 octets) y a encore de la marge pour des amélioration. J'avais tester aussi une portion de RAM avec des breakpoint et a priori y avait pas mal de place libre aussi en RAM mais j'ai meme pas eu besoin d'utiliser d'autre variable que celle deja utilisé par le jeu.
Le plus chiant ca juste ete de gérer les "trou" dans le menu. Quand on change de page y a pas forcement deja un item/arme sur la meme ligne de l'autre page donc ca demande au code de sélectionner une autre ligne deja occupé parmis celle disponible sinon ca glitch. Et faut que cette selection soit assez intuitive (pas comme dans MM3 ou c'est raté).

Le lien vers la ROM hacké
https://drive.google.com/open?id=0B399kteofpYuTkhTd2U4UEt5UGs

et la version avec cheat (full item/weapon)
https://drive.google.com/open?id=0B399kteofpYuUE5fdWhocUk1YUU

Donc si y a des fans de Megaman 2 n'hésitez pas a beta-tester (surtout dans la seconde phase du jeu) vous verrez c'est vraiment agréable. Ca transcende ce jeu culte.
Idéalement je voudrais aussi enlever la ligne "Next" qui sert plus a rien (et du coup déplacer un peu les elements et changer l'aspect visuel) mais j'ai peur que ce soit beaucoup d'effort pour un apport tres limité car ca change pas énormément du point de vue fonctionnel (ca serait un poil mieux).

https://youtu.be/EGFtU9UcPZQ

[upsilandre]

J'ai amélioré un peu. Si on appuie sur select quand on est dans le menu ca selectionne directement le Buster et ferme le menu. Ca permet de facilement reprendre le Buster sans faire de menuing, ca simplifie encore un peu plus.
Les liens sont a jour.

[upsilandre]

J'ai fais une version avec cheat qui permet de démarrer directement full arme/item (du coup on peut faire les levels avec des armes/items qu'on ne peut pas avoir normalement et du coup dès que t'as finit le premier level t'es transporté directement a la seconde phase du jeu, la forteresse de willy) pour tester plus rapidement le menuing.
https://drive.google.com/open?id=0B399kteofpYuM2hlYW9HRXVtd00

[fanoplusplus64K]

Beau boulot ! je regrette de pas encore avoir de cartouche programmable pour tester en vrai

[Stef]

C'est génial, bravo ! Dis donc pour quelqu'un qui ne se revendique pas codeur tu fais du hacking pas forcément facile !
Je te conseille chaudement de poster ton hack (au bon format) sur romhacking si ce n'est pas déjà fait =)

[upsilandre]

Beau boulot ! je regrette de pas encore avoir de cartouche programmable pour tester en vrai

C'est vrai que si quelqu'un veut tester sur une vrai console ca peut etre intéressant (meme si j'ai pas trop de doute, y a pas de code sensible)

[upsilandre]

C'est génial, bravo ! Dis donc pour quelqu'un qui ne se revendique pas codeur tu fais du hacking pas forcément facile !

3 jours tous les X années on peut pas se revendiquer codeur. J'evite parce que ca prend trop de temps mais cette fois l'occasion etait trop belle. C'est du hack de code, j'avais pas encore fait, c'est plus fun et compliqué (plus que de faire du hacking de data) mais en meme temps sur ce cas c'etait pas trop compliqué non plus ( et ca c'est mieux passé que je pensais) donc pas trop long et en plus c'est vraiment utile et sur un jeu culte. Je me suis refais un run complet et c'est tellement mieux comme ca (rien que les phases ou tu farme en difficile pour recharger une arme/item, ou simplement quand tu veux jeter un oeil sur ce qu'il te reste comme ressource). Pouvoir améliorer un jeu historique (sans le pervertir) avec si peu d'effort l'equation est super rentable.
Et puis j'adore les outils de Fceux et ce genre de hack demande de tous les utiliser. C'est assez amusant (j'aimerais bien faire un jour une video pour montrer ces outils).

Je te conseille chaudement de poster ton hack (au bon format) sur romhacking si ce n'est pas déjà fait =)

Bonne idée, j'y avais pas pensé. Mais je vais attendre de voir si je peux pas modifier d'autre truc.

[Tryphon]

Ah félicitations pour ton boulot !

Et oui le hack de code, c'est pas facile, depuis le temps que je me tue à le dire :)

[Stef]

3  jours tous les X années on peut pas se revendiquer codeur. J'evite parce que ca prend trop de temps mais cette fois l'occasion etait trop belle. C'est du hack de code, j'avais pas encore fait, c'est plus fun et compliqué (plus que de faire du hacking de data) mais en meme temps sur ce cas c'etait pas trop compliqué non plus ( et ca c'est mieux passé que je pensais) donc pas trop long et en plus c'est vraiment utile et sur un jeu culte. Je me suis refais un run complet et c'est tellement mieux comme ca (rien que les phases ou tu farme en difficile pour recharger une arme/item, ou simplement quand tu veux jeter un oeil sur ce qu'il te reste comme ressource). Pouvoir améliorer un jeu historique (sans le pervertir) avec si peu d'effort l'equation est super rentable.
Et puis j'adore les outils de Fceux et ce genre de hack demande de tous les utiliser. C'est assez amusant (j'aimerais bien faire un jour une video pour montrer ces outils).

Le hacking n'est pas trop mon truc non plus, mais c'est vrai que si tu peux améliorer le jeu sans le pervertir ou le mettre à ton propre gout (hack couleur / graphisme / musique) je trouve ça interessant. Il existe pas mal de hack qui se contentent juste de corriger des bugs du jeu d'origine, améliorer les performance (loading par exemple) ou vraiment améliorer le jeu sur un point particulier sans toucher au gameplay (exactement comme tu l'as fait ici) :)
Dans le même genre j'avais fait un hack de Street Fighter 2 (et SSF2) sur MD qui permettait d'améliorer sensiblement le rendu des voix digitalisées (à mon sens c'est le plus gros défaut de cette version).

[upsilandre]

J'ai pu encore améliorer un peu et arrivé a mes fins en court-circuitant completement la ligne "NEXT" dans la logique du menu pour qu'on puisse vraiment tourner en boucle dans le menu sans passer par cette ligne maintenant inutile (et sans que ca bug quand on switch sur une page ou y a aucune arme/item et donc meme plus cette ligne NEXT, c'etait le probleme )

Et encore une fois je me suis surpris a faire ca en modifiant tres peu d'octet finalement. C'est vraiment fun le hacking de jeu NES c'est comme un jeu d'enquete et dans ce jeu ce qui me plait c'est pas seulement que ca marche mais de le faire si possible en finesse en laissant le moins de trace.

Je pense que c'est la version final
- Mettre en place le menuing 2D (avec bruitage): check
- Gerer correctement les "trou" dans le menu: check
- Exclure la ligne "NEXT" du menuing: check
- Ajouter une commande avec "select" pour sortir directement du menu en sélectionnant le Buster: check

Et j'ai modifié seulement 174 octets de la ROM d'origine, je suis contant de moi.

Pour la version sans cheat
https://drive.google.com/open?id=0B399kteofpYuTkhTd2U4UEt5UGs

Et la version avec cheat
https://drive.google.com/open?id=0B399kteofpYuUE5fdWhocUk1YUU

[upsilandre]

Dans le même genre j'avais fait un hack de Street Fighter 2 (et SSF2) sur MD qui permettait d'améliorer sensiblement le rendu des voix digitalisées (à mon sens c'est le plus gros défaut de cette version).

A oui c'est intéressant comme hack, t'avais identifier un probleme particulier? (ou t'as upgrader les samples?)

[Tryphon]

Le hacking, j'y suis venu par hasard (à la base je cherchais juste à récupérer des ressources pour un port perso), et parfois ça me gave un peu. Mais y'a de très bons côtés aussi (l'idée, c'est que de toutes façons tu n'as pas le temps de comprendre tout le code, donc ça ressemble vraiment à trouver son chemin dans une ville tentaculaire).

Je m'y investis surtout pour des fantrads : un traducteur a traduit un script, il faut le réinsérer dans la ROM (ça c'est en général facile), mais y'a plein de petits détails à régler pour que ce soit bien.

Par exemple, le plus classique, c'est que les polices japonaises sont toujours à chasse fixe, alors qu'une jolie police latine est proportionnelle, et ça se voit quand un jeu utilise une police proportionnelle (genre les Climax sur MD). C'est exactement ce que je suis en train de faire sur Lord Monarch (après avoir revu la routine de césure des phrases, changé l'encodage, modifié des graphismes, reprogrammé les menus,...)

Mais plein d'autres trucs nécessitent de plonger le nez dans le code et le modifier de façon quasiment invisible (genre : changer l'encodage du texte, voire carrément changer l'algo de compression) Truc tout bête, le layout des menus doit souvent être complètement changé, parce que le japonais en un caractère en dit plus que l'anglais en 5 et le français en 10 !

Au final c'est assez ingrat, parce que c'est super long, le résultat à l'écran doit être le plus discret possible, et les utilisateurs finaux ont tendance à penser que le traducteur bosse beaucoup plus que le hackeur. Puis c'est frustrant parce que toute modification a des conséquences parfois très éloignées.

Mais le fait de travailler en petite équipe, avec des gens compétents dans des domaines différents, où on échange souvent sur comment modifier tel aspect inadaptable tel quel, c'est assez motivant ; en tous cas mes trois expériences : Phantasy Star Generations (PS2), Psy-O-Blade (MD) et Lord Monarch (MD) sont très positives.

Mais je languis de finir et de me remettre à Shinobi ! :)

PS : le hack de Stef sur SF2 / SSF2 est assez bluffant, j'espère un jour être capable de ça !

[upsilandre]

La fantrad je m'y etais un peu intéressé parce que y a du boulot pour de la fantrad FR (plus simple mais c'est moins intéressant) mais c'est vrai que c'est beaucoup de boulot, beaucoup beaucoup plus que ce que les gens imaginent (en tout cas pour de vieille machines surtout en partant du jap) c'est sur que c'est assez ingrat, c'est a l'opposé du hack graphique genre changer quelques tiles, le resultat est rapidement spectaculaire pour peu d'effort (a part pour le graphiste si c'est un skin original).

[Stef]

Dans le même genre j'avais fait un hack de Street Fighter 2 (et SSF2) sur MD qui permettait d'améliorer sensiblement le rendu des voix digitalisées (à mon sens c'est le plus gros défaut de cette version).

A oui c'est intéressant comme hack, t'avais identifier un probleme particulier? (ou t'as upgrader les samples?)

J'ai pas touché aux samples, même s'ils ne sont pas excellents (7.5 Khz) le problème venait surtout du driver audio.
En gros dans SF2 le 68000 gère la musique et le Z80 ne gère que le PCM (voix digits ou percussion).
Alors ok ils ont quand même fait l'effort de faire un petit mix software histoire d'avoir 2 canaux PCM alors que la version arcade d'origine utilise 1 seul voix PCM (donc une voix coupe une autre là où elle se mélange sur MD ou SNES, facile a tester un faisant un hadoken avec les 2 persos). Par contre ils ont fait ça de la manière la plus simpliste qui soit:
LOOP
 - lire un sample en ROM pour le PCM1
 - lire un sample en ROM pour le PCM2
 - mixer ensemble les 2 samples
 - envoie du resultat dans le DAC
 - interpréter les commandes provenant du 68000
END

Alors c'est super simple, le driver doit faire une centaine d'octet (très facile à désassembler du coup, je l'ai quelque part ^^) et ils ont quand même mis réussi à foutre un bug dedans (1 sample PCM2 de louper tout les 255 samples) mais ça se remarque pas vraiment.
Mais bon du coup, cette implémentation simpliste est hyper inefficace sur MD, car pour chaque sample lu tu dois reconfigurer la banque ROM (qui se fait via un port série soit un minimum de 100 cycles pour le configurer), ça fait déjà 200 cycles de consommé rien que pour setter les banques pour chaque sample PCM généré !! Du coup avec tout ça la boucle doit faire dans les 475 cycles ce qui donne environ du 7.5 Khz (3.58 Mhz / 475)... bon pour des raisons d'espace ROM je pense que raisonnablement ils ne seraient pas été bien au dessus de toute façon mais là quand bien même l'implémentation t'empêche d'aller au dessus... Mon premier driver Z80 2 PCM que j'ai écrit y'a 10 ans maintenant je pense permettait déjà de faire du 14 Khz donc on peut dire que leur code est quand même particulièrement inefficace :p

Mais le plus gros problème à mon sens c'est surtout la gestion de la contention du BUS avec le DMA, et oui quand y'a un transfert DMA le BUS du 68000 (celui donc par lequel le Z80 accède aux données en ROM) est 100% pris par le VDP (bus master) du coup si le Z80 tente d'y accéder il est bloqué jusqu'à la fin du DMA, c'est la raison pour laquelle les voix grésillent tant dans SF2 :-/ En plus le jeu fait trop de DMA (duplication de certains envois, incompréhensibles) ce qui n'arrange rien...
Enfin vraiment vu comment ça impacte le jeu (ce jeu a lui seul a ruiné la réputation de la MD sur ses capacités à reproduire des vox digitalisées ) ils auraient décidément du s'y prendre autrement, surtout qu'il y avait plusieurs possibilités... Je veux bien reconnaitre que la gestion du PCM sur MD est un peu tricky (car déjà forcément software) mais bon tu as un Z80 à 3.58 Mhz et 8 Ko de RAM juste pour ça (soit toute la capacité CPU et mémoire de la SMS).

Pour ma part j'ai choisi de totalement réécrire le driver Z80... en prenant garde de bufferiser les samples dans la mémoire du Z80 (les 8 ko sont plus que suffisant pour ça) et ainsi ne pas accéder au BUS pendant les accés DMA (qui commencent au VBlank, facile à timer car tu as l'interruption verticale sur le Z80 aussi)... et le problème était réglé :) L'écriture du driver m'a pris une journée, le plus chiant étant de m'adapter à leur structure (commande 68000 et status) et aussi de trouver en ROM les points d'entrée (chargement driver / relocation car mon driver est plus gros...). Enfin bref, pour le coup c'est quand même dommage.

Tu as des vidéos pour te montrer avant (première moitié vidéo) / après (second moitié) :
A noter qu'il y a aussi le color hack de Pyron appliqué en même temps d'où quelques changements cosmétiques aussi.

SF2:


SSF2:


On remarque que les voix de SSF2 ont l'air bien plus propres que SF2, c'est simplement que Capcom les a pré-filtré à fond :p L’échantillonnage reste exactement le même que dans SF2 (soit 7.5 Khz).

[upsilandre]

La difference est enorme! Et c'est vraiment plus intéressant que si ca avait ete une upgrade des samples eux meme. L'idée c'est de montrer ce qu'aurait pu etre le jeu a l'epoque. Et ca permet en bonus d'eduquer sur un element technique ( que la qualité du son c'est pas juste la qualité des samples )
Je pense que quand tu commences a regarder le code des jeux tu voit beaucoup de chose bizarre. Faut pas oublier que les gars avait des deadlines sérré + travaille en equipe (qui impose des compromis). Quand j'entend que MM2 pourtant culte a ete développé soit disant en 4 mois (mais avec une partie des rebus du dev de MM1).

[Tryphon]

C'est quand même vraiment bluffant...

[Invité]

Je pense que quand tu commences a regarder le code des jeux tu voit beaucoup de chose bizarre. Faut pas oublier que les gars avait des deadlines sérré + travaille en equipe (qui impose des compromis). Quand j'entend que MM2 pourtant culte a ete développé soit disant en 4 mois (mais avec une partie des rebus du dev de MM1).

C'est clair, j'ai été surpris de voir que des jeux PCE techniquement classes (visuellement et quand tu joues) sont codés des fois avec les pieds, je prends l'exemple de SF2 CE sur PCE, les driver PCM bouffe 15% de CPU pour une voix et 20% pour 2,c'est un exemple parmi d'autres, mais bon les deadlines devaient souvent être trop réduites, et les codeurs réutilisaient du vieux code pour certaines parties, et du moment que ça faisait le boulot, ils cherchaient pas plus loin .
Le mien avec décompression+bancking je suis à 8/9% pour 2 voix .

[Stef]

Je dirais que le problème des performances est pas gênant tant que ça n'impacte pas le jeu final. SF2 n'est pas un jeu gourmand en terme de CPU du coup même si le code n'est pas optimisé ça passe sans trop de soucis. Le truc bizarre de la version PCE c'est qu'a priori ils ont permis 2 voix PCM et pourtant dans les faits tu as l'impression d'en avoir qu'une (les voix s'entrecoupent).
Aussi sur MD vraiment le rendu des voix de base est exécrable, c'est pas comme si c'était un petit détail qu'on remarque a peine. À mon sens ils auraient quand même pu faire un effort sur ce point précis.

[Invité]

N'oublies pas que sur PCE, les transferts en VRAM se font au CPU, donc ça a finalement un impact(plus de CPU consommé = moins de transferts,surtout que c'est 6 fois plus lent qu'avec un DMA) .
Mais sinon c'est vrai que tant que ça impactait pas, les devs cherchaient pas plus loin  .

Aussi sur MD vraiment le rendu des voix de base est exécrable, c'est pas comme si c'était un petit détail qu'on remarque a peine. À mon sens ils auraient quand même pu faire un effort sur ce point précis.

Oui ça c'est un comble, surtout pour un jeu codé par sega .

Le truc bizarre de la version PCE c'est qu'a priori ils ont permis 2 voix PCM et pourtant dans les faits tu as l'impression d'en avoir qu'une (les voix s'entrecoupent).

Je pense qu'il doit y avoir un bug de priorité dans le driver, car la musique utilise aussi 1 voix pcm, et je suppose que le driver doit quelques fois zapper celle d'un des 2 persos .

[Tryphon]

SF2 était codé par CAPCOM je crois. Sega avait commencé un port, mais CAPCOM a voulu le faire eux-mêmes, ce qui doit expliquer que les sprites soient exactement les mêmes que ceux de la version SNES, le jeu est d'ailleurs en basse réso (256).

D'ailleurs Stef, tu penses qu'il aurait pu passer en 320x224 ? Ça aurait fait plus de tiles à charger pour chaque frame, mais comme il semble que niveau CPU il soit pas trop mortel...

[Invité]

SF2 était codé par CAPCOM je crois. Sega avait commencé un port, mais CAPCOM a voulu le faire eux-mêmes, ce qui doit expliquer que les sprites soient exactement les mêmes que ceux de la version SNES, le jeu est d'ailleurs en basse réso (256).

Ah oui c'est vrai, c'est capcom qui a fait le portage,mais bon c'est quad même un manque de sérieux, c'est pas comme si capcom ne connaissait pas se type d'archi 68K + Z80 pour le son. ..

Après pour la réso, je pense que la taille de la cartouche a jouée, il me semble que rien n'est compressé dedans, et peut être que de récupérer les gfx snes facilitait le temps de dev .

[MeteK]

Bombe !

[upsilandre]

Pour tester OBS (j'ai encore jamais enregistrer mon PC) j'ai fais une petite video (60fps) d'illustration

https://youtu.be/EGFtU9UcPZQ

[Stef]

Sympa la vidéo, et ça permet de bien se rendre compte à quel point c'est *beaucoup* plus pratique ainsi ! Bien joué :)

Pour répondre aux précédentes questions sur SF2: effectivement c'est Capcom qui s'est occupé du port... Sega avait développé sa propre version avant mais en partant des assets de chez Capcom (qui provenaient donc de la version SNES). Du coup la version de Sega est également en H32 (256 de largeur) et graphiquement est assez proche de la version finale de Capcom (même tout de même avec certaines différences).
Si on avait porté SF2 arcade directement sur MD sans avoir cette version SNES avant il est quasi certain qu'il aurait été en H40 (320), il n'y a aucun intérêt à utiliser le H32 sur MD (qui limite les perfs du VDP) sauf justement dans le cadre d'un portage d'un jeu qui est déjà dans cette résolution. Effectivement après en terme d'espace ROM ca aurait pris un peu plus, mais sur MD ils auraient au moins pu compresser les backgrounds

[philip]

@upsilandre
C'est bien vue.

[upsilandre]

Truc curieux que j'aurais pu montrer dans la video c'est que l'affichage du menu de MM2 est entièrement en sprite contrairement aux MM suivant, c'est pas tres orthodoxe. Du coup ca bouffe tout les sprites donc effectivement y avait aucune chance d'afficher les armes/items supplementaire sur la meme page, l'affichage du menu etait calibré pour MM1 (mais ca justifie pas de gérer ca de cette facon)

[Invité]

l'affichage du menu etait calibré pour MM1 (mais ca justifie pas de gérer ca de cette facon)

Si, la simplicité 

[upsilandre]

D'ailleurs on peut se poser la question pourquoi Megaman (et les boss) a toujours eu 28 PV? Pareille pour toutes les ressources, armes, items. Pourquoi ce chiffre en particulier?
C'est probablement lié a cette affichage du menu en sprite. Dans le menu toutes les ressources sont representé par des barres horizontal (au lieu de vertical dans le HUD). Ne pouvant afficher que 8 sprites par ligne dont un qui sert a identifier par une lettre ce qui est mesuré, Chaque sprite ne pouvant representer que 4 PV ca a donné ce chiffre de 7x4 = 28 PV/munitions.

[fanoplusplus64K]

C'est ce que j'aime dans le hacking de vieux jeux, tu fais de l'archéologie informatique, des fois tu découvres des choses en triffouillant le jeu