Hardcore Retrogaming

upsilandre a écrit:

Kaiser_Gun a écrit:

Je commence un peu à m'intéresser au hack nes.
Si j'ai bien compris le concept si je veux hacker les boutons leur fonctionnalité c'est:
1- Faut que je trouve la case mémoire qui change et les valeurs de chaque bouton
2- Que je trouve des cases mémoires pas utilisés pour y mettre les fonctions détournées

C'est bien ça le bidule ?

oui a peu pret.
Pour le hack faut utiliser Mesen maintenant.

Moi ce que je fais d'abord c'est que j'ouvre le memory viewer et je jette un oeil sur la ram (les 500 premiers octets ca suffit en général) pour trouver ou est stocké en RAM l'etat du controleur. En général y a un octet qui stock l’état du controleur (ca tiens dans un seul octet), et un autre a coté qui stock seulement les changement d’état du controleur pendant une frame (ca permet de savoir si tu viens tout juste d'appuyer, mais il est plus difficile a voir car il est toujours a zero et ne change que pendant une frame au moment ou t'appuie mais il est jamais loin de l'autre). Ces 2 octets sont exploité pour des fonctions différente. Par contre les valeurs pour chaque bouton sont quasiment toujours les meme, c'est lié a la façon dont les input son récupéré sur le port (en série, bit par bit, et donc toujours stocker dans le meme ordre dans l'octet), c'est très simple , chaque bit correspond a un bouton (y a que 8 boutons sur NES) et donc en général c'est $01 = Droite, $02 = Gauche, $04 = Bas, $08 = Haut, $10 = Select, $20 = Start, $40 = B, $80 = A (et les additions de ces valeurs si tu combines plusieurs bouton).

Une fois que j'ai trouvé au moins le premier octet je met un breakpoint dessus ce qui permet ensuite dans le debugger de retrouver les routine qui utilise cette octet (le debugger va stopper l’exécution dès qu'il y aura un acces a cette octet).
A partir de la effectivement va falloir comprendre les routines en question pour pouvoir les modifier. Parfois ce dont tu as besoin de changer est limité et prend pas plus de code (voir en prend moins) du coup tu peux modifier directement le code en question (et si y a des trou tu remplis avec des NOP). En général t'as besoin de plus de place du coup tu insères juste un JSR pour envoyer vers une autre sub-routine (la tienne) et donc vers un espace de la ROM qui n'est pas exploité (de préférence dans la meme bank). En général en fin de bank si c'est plein de $00 ou de $FF c'est bon signe. Tu peux faire au pif mais pour etre certain suffit de jouer un max au jeux pour remplir le data/code logger du debugger qui lui enregistre tout ce qui est utilisé par le jeu et donc la tu peux savoir si ces octets sont vraiment libre et non utilisé.

C'est quand meme pas simple l'aire de rien. Mais si ca t'intéresse un jour on peut se faire un truc a 2 par micro et vidéo sur un cas particulier qui t'intéresse et on regarde pas a pas en live ce qu'on peut faire et comment.

Ouai j'ai fait le tour de quelques jeux notamment Megaman 2 comme je sais que tu as dérivé après le bouton Select, j'ai essayé de comparer avec l'original. Je ne suis pas allé plus loin pour l'instant.
Mais en gros là je comprends bien quand les entrées inputs pour le LastFrame et le Hold. J'imagine qu'en jouant avec les deux tu peux savoir quand est ce que le bouton a été relâché. Ca devrait se trouver sur au moins 1943 vu que tu peux faire un tir chargé.

Après j'apprends l'assembleur et le 6502 en parallèle donc je rame un peu mais d'ici une semaine ou deux ça devrait aller mieux.
Et c'est vrai que Messen est pas mal du tout.

Oui le 6502 tu fait vite le tour du jeu d'instruction

upsilandre a écrit:

Oui le 6502 tu fait vite le tour du jeu d'instruction

J'ai trouvé un site http://skilldrick.github.io/easy6502/

Je pense que ça couvre le nécessaire pour le 6502 je pense. En tout cas c'est ludique.

Je pense avoir fait un premier tour des instructions du 6502. Y'en a pas beaucoup et au final t'as le même type selon le registre ou l'accumulateur.

Après il y a les instructions Bitwise pas vraiment tout compris.

Code:

ROL
ROR
AND
ORA
EOR
BIT

Puis t'as le Carry et les flags qui ressemblent à NV-BDIZC.
Alors les instructions affectent les flags. Le plus souvent N Z V C.
Le I et le D je ne sais pas du tout. Ce n'est peut être pas important.
Le -, parfois c'est même pas indiqué dans la doc.
Pour le B t'as que le BRK, et donc voilà.

Du coup je ne sais pas trop comment le carry s'utilise; j'ai du mal à imaginer comment placer les instructions BCC et BCS.

Heureusement qu'avec les outils d'aujourd'hui ce n'est pas toute la machine qui plante mais juste l'émulateur.

Kaiser_Gun a écrit:

Je pense avoir fait un premier tour des instructions du 6502. Y'en a pas beaucoup et au final t'as le même type selon le registre ou l'accumulateur.

Après il y a les instructions Bitwise pas vraiment tout compris.

Code:

ROL
ROR
AND
ORA
EOR
BIT

Les bitwise ont une importance assez capital en assembleur, tu les verra partout (et tu peux ajouter LSR et ASL encore plus incontournable)
Y a que le BIT que tu peux laisser de coter pour l'instant. Les autres sont tous important.
- LSR(Right) et ASL(Left) c'est pour décaler les bit de ton octet vers la gauche ou vers la droite, ca sert pour plein de truc et notamment pour faire des division ou multiplication par 2,4,8...
- ROL et ROR c'est pareil que LSR et ASL, ca décale les bit vers la gauche ou vers la droite sauf que ca fonctionne comme une boucle, comme si le dernier bit de l'octet était connecté au premier (en vrai ca fait une boucle en passant par la carry donc comme si ton octet bouclait sur 9 bit) et c'est pratique pour transférer quelques bit d'un octet a un autre (en les faisant passé par la carry).
- AND (ET logique) ca permet de filtrer les bit d'un octet en laissant passer seulement les bit de ton choix et en mettant les autre a zero.
- ORA (OU logique) c'est pour combiner les bit de 2 octets si t'as besoin de mélanger 2 octets.
- EOR (OU exclusif) ca permet d'inverse les bit de ton choix dans un octet

La je te dis en gros l'usage le plus courant (mais je dirais que c'est 80% de l'usage de ces instructions). Evidemment c'est pas en te balancant une phrase comme ca que tu va comprendre mais ca te donne une piste.

Citation :

Puis t'as le Carry et les flags qui ressemblent à NV-BDIZC.
Alors les instructions affectent les flags. Le plus souvent N Z V C.

oui toi ce qui va t’intéresser dans les flag c'est juste ceux la pour l'instant, je dirais meme que tu peux enlever le V qu'on utilise rarement. Par contre le N, Z et C ca c'est indispensable de comprendre car leur usage est omniprésent. Ca sert essentiellement de condition pour les branchement (les flags s'utilisent principalement par l’intermédiaire des instruction de branchement BMI (branchement si minus/negatif), BPL (branchement si plus/positif), BEQ (branchement si égale/zero), BNE (branchement si non egale/non zero), BCS (branchement si carry set) et BCC (branchement si carry clear), c'est les 6 a vraiment connaitre qu'on utilise tout le temps ) Ca permet de faire un branchement vers un bout de code selon le résultat de la dernière opération que le CPU a exécuté. Si ca a donné un octet nulle ou un octet négatif ou une retenu... C'est un peu le coeur du code assembleur 6502.

Citation :

Le I et le D je ne sais pas du tout. Ce n'est peut être pas important.

D ca ne concerne pas la NES, c'est pour le format BCD (binaire codé decimal) qui est un mode spécial pour les calcules arithmétique mais qui n'existe pas dans le CPU NES (en vrai il est présent ce mode mais ils ont juste coupé une piste pour le rendre inopérant juste pour pas payer les royalties lié a cette fonction)
Le I c'est juste le flag qui indique si t'as autorisé les interruptions CPU ou pas. Si ce flag est a 0 alors ca veut dire que le CPU peut se faire interrompre par un appel externe sur son entrée IRQ. Si il est a 1 ca bloque les interruptions IRQ et empeche le CPu d'etre interrompu (mais il peut l'etre par un signal NMI puisque c'est ce qui défini le NMI, il ne peut pas etre bloqué, et dans la NES le NMI c'est le PPU qui le controle). Mais pour l'instant c'est pas important.

Citation :

Le -, parfois c'est même pas indiqué dans la doc.

C'est un flag inutilisé

Citation :

Pour le B t'as que le BRK, et donc voilà.

Oui ca c'est comme le I pour l'instant tu t'en fou.

Citation :

Du coup je ne sais pas trop comment le carry s'utilise; j'ai du mal à imaginer comment placer les instructions BCC et BCS.

Par exemple si t'additionne 150 et 200, le résultat ca sera 94 (puisque ca peut pas dépasser 255) + le flag carry qui sert de retenu (la carry te dit en gros que t'as 256 en retenu en plus de ton 94). Du coup si t'as besoin de savoir si ton calcule a dépasser 255 alors tu place un BCS ou BCC derrière le calcule. Et surtout ca permet aussi de faire facilement un calcule 16bit car la carry va s'ajouter automatiquement a ta prochaine addition. Il suffit que t'as prochaine addition consiste simplement a ajouter zero (ADC #$00) au second octet de ton nombre 16bit (celui de "poid fort" comme on dit) pour que la carry se transfére donc directement a l'octet de poid fort de ton nombre 16bit (et le premier bit de ce second octet vaut 256 puisque c'est en réalité le 9eme de ton nombre 16bit) sans meme avoir besoin de tester la carry et de savoir si y en a une ou pas. Et du coup il est assez simple de faire des calcules 16bit.


Mais tout ca est compliqué a résumé en une phrase. C'est trop de questions a la fois
Sachent aussi que dans Mesen quand t'es dans le debugger il suffit de poser la souris sur une instruction pour avoir tout les détails de l'instruction. Avec Mesen y a pas besoin d'avoir une doc 6502 sous les yeux pour se rappeler des particularités de chaque instruction. Moi meme j'ai souvent tendance a oublier des truc (par exemple que INC et DEC qui incrémente et décrémente, ne génère pas de carry quand tu dépasse 0 ou 255 contrairement a ADC et SBC. La au moins ca permet de te le rappeler)
Et Mesen le fait aussi sur tout les port de la NES (les port du PPU et de l'APU, c'est a dire les adresse $2000-2007 et $4010-$4017), ils t'indique a quoi servent chaque bit, la aussi pas besoin d'avoir une doc sous les yeux ou de les apprendre par coeur.

Merci pour les explications.

LSR:
Disons je prends 4 en binaire c'est 0100.
Ca décale vers la droite du coup ça fait 0100 >> 0010
En gros si je fais pareil avec 5 qui 0101. Ca me donne 0010 soit 2 aussi. Et j'ai le C en 1.

Éventuellement je peux checker le carry pour arrondir à l'entier supérieur.
Du coup les instructions BCC et BCS me parlent beaucoup plus.

ASR: même chose que le LSR mais vers la gauche.

ROL:
1000 1000 donnerait 0001 0000 et j'ai C en 1

ROR: bon la même chose que le ROR mais vers la droite.

AND: Ca permet de masquer les bits d'un octet.

Code:

LDA #$90  ;; 1001 0000
AND #$84  ;; 1000 0100
;; result    1000 0000
;; plus facile de voir le truc quand c'est aligné

ORA:

Code:

LDA #$90  ;; 1001 0000
ORA #$84  ;; 1000 0100
;; result    1001 0100

Plus parlant peut être

Code:

LDA #$0f  ;; 0000 1111
ORA #$f0  ;; 1111 0000
;; result    1111 1111

EOR: On dirait le comportement inverse du AND.

Code:

LDA #$90  ;; 1001 0000
EOR #$84  ;; 1000 0100
;; result    0001 0100

Dans le doggueur de Messen j'ai par exemple

Code:

LDA $0660 = $40

J'imagine que c'est parce que la valeur au $0660 est $40.

Pareil pour:

Code:

LDA $0660,X @ $0661 = $ff

J'imagine c'est parce que X = $01 et donc on se retrouve au $0661 ($0660 + X) dont la valeur est $ff.

Je répond en vidéo, c'est plus simple pour moi (pour parler du debugger Mesen)

https://youtu.be/-UPpuTxNDJY

Merci beaucoup pour ton temps
Du coup j'ai téléchargé la vidéo au cas où.

T'as bien fait de parler de Mesen et des outils qu'il propose parce que justement j'étais passé à côté du Tracer. Surtout quand ça commence à jump dans tous les sens.

Oui j'ai commencé par les bases parce qu'au final pour lire des parties du code c'est toujours bien de savoir si c'est une partie qui pourrait m'intéresser ou pas.
Puis je pense l'avantage d'être en 2020 c'est de pouvoir analyser le code d'un tas de jeu. C'est plus simple pour apprendre. Et puis bon quitte à regarder autant bidouiller.

Pour l'instant je me limite vraiment au 6502. J'ai vu qu'il y avait un émulateur pour Android où tu peux taper du code et l'exécuter. Ça permet de tester des idées ou de pratiquer.

J'aime bien parce que l'approche est simple. Et ça ressemble un peu à ma façon d'apprendre un langage ou framework. Déterminer les instructions ou fonctions essentielles et de les camper pendant un certain temps. Sauf que là il n'y en a pas des masses. Mais ça peut être tout aussi amusant de les étendre.

Paradoxalement cette simplicité me permet de mieux visualiser certains trucs que j'aimerai faire sur Unity .

Et inversement j'ai l'idée d'un jeu là que j'aimerais bien faire sur NES ou la 2600. Qui est très simple et ça me prendrait 30min chrono sur Unity mais je préfère le faire sur le 6502. Parce que je n'aurai pas eu l'idée si je ne voulais pas bidouiller en assembleur en fait.

//-----------------------------
Mon plan "de cours "serait donc:
1. Hacking: découvrir le code et l'assembleur. Préparer des fonctions tranquillement et s'approprier les idées de cycles histoire de dégager des solutions si jamais.
2. Portage d'un jeu existant: Typiquement le puzzle game que j'ai laissé sur le forum où tu switches la couleur des cases sur lesquels tu passes. Ça me semble être un bon exercice. Je vais peut-être le sortir comme ça d'ailleurs.
3. Un projet de shoot-em up horizontal. Là je crois que le gros du truc pour moi ça sera le pattern des ennemis.

C'est assez ambitieux. Moi j'aurais pas la motivation de faire un jeu complet (peut etre un jour)

D'ailleurs j'ai pas parlé de la version de Mesen que j'utilise. Faut savoir que Sour a eu un conflit avec un autre codeur y a 2 mois et pour l'instant tout est abandonné, Mesen et Mesen-S (SNES) donc les build auquel on a acces actuellement sont peut etre les tout dernier build de Mesen , heureusement il est deja très abouti, mais donc on peut en choisir un et se fixer dessus peut etre de façon définitive (ca tombe bien pour toi).
Y a la version 0.9.9 qui est la dernière version officiel mais apres celle la il a quand meme fait 62 build de plus sur son Ghitub avec des corrections.
https://ci.appveyor.com/project/Sour/mesen/history

Mais si tu veux vraiment le build le plus récent il faut pas prendre le 62, a partir du 45 y a un gros bug dans le debugger qui t'efface tout ton workspace a chaque fois que tu relance la ROM. J'ai bien galéré a trouver la dernière version avant ce bug et c'est le build 44 (0.9.9.44) et c'est celui que j'utilise
https://ci.appveyor.com/project/Sour/mesen/builds/32621591/artifacts

Et la doc de Mesen est bien foutu comme le reste donc faut en profiter (je l'ai archivé au cas ou le site disparaisse)
https://www.mesen.ca/docs/

upsilandre a écrit:

C'est assez ambitieux. Moi j'aurais pas la motivation de faire un jeu complet (peut etre un jour)

Pour le portage j'ai tous les docs, ça devrait aller.
Pour le shmup ça va, je ne vais pas aller plus loin qu'un 1943 mais en horizontal je pense.

Ce qui va être un peu lourd je pense c'est de faire les outils qui pourraient être nécessaire. Je ne me vois pas faire des niveaux "à la main".

upsilandre a écrit:

D'ailleurs j'ai pas parlé de la version de Mesen que j'utilise. Faut savoir que Sour a eu un conflit avec un autre codeur y a 2 mois et pour l'instant tout est abandonné, Mesen et Mesen-S (SNES) donc les build auquel on a acces actuellement sont peut etre les tout dernier build de Mesen , heureusement il est deja très abouti, mais donc on peut en choisir un et se fixer dessus peut etre de façon définitive (ca tombe bien pour toi).
Y a la version 0.9.9 qui est la dernière version officiel mais apres celle la il a quand meme fait 62 build de plus sur son Ghitub avec des corrections.
https://ci.appveyor.com/project/Sour/mesen/history

Mais si tu veux vraiment le build le plus récent il faut pas prendre le 62, a partir du 45 y a un gros bug dans le debugger qui t'efface tout ton workspace a chaque fois que tu relance la ROM. J'ai bien galéré a trouver la dernière version avant ce bug et c'est le build 44 (0.9.9.44) et c'est celui que j'utilise
https://ci.appveyor.com/project/Sour/mesen/builds/32621591/artifacts

Et la doc de Mesen est bien foutu comme le reste donc faut en profiter (je l'ai archivé au cas ou le site disparaisse)
https://www.mesen.ca/docs/

Tu fais bien de me le dire parce que je pensais que la feature manquait
Et comme je suis assez résilient je ne m'étais pas posé plus de question que ça.

C'est dommage mais bon ca devrait largement me suffir au point où j'en suis

Le hacking commence à rentrer tranquillement. En tout cas je suis plus à l'aise à la lecture du code pour dériver vers ailleurs et rebrancher là où ça devrait reprendre après la bidouille. Sauf quand il faut aller écrire dans des octets pas utilisés parce que je ne sais pas encore qu'est ce qui se trouve où exactement à part la RAM.

Je n’aimais pas trop l'ergonomie de Double Dragon 2 qui a un peu vieillie.

A la base, lorsque le personnage est tourné à droite le Punch est sur A et quand il est tourné à gauche le Punch est sur B. Ca ajoute du challenge certes mais ça peut être relou pour les plus jeunes.
J'ai donc hacké la rom pour une ergonomie plus moderne. Le Punch et Kick restent en permanence A et B. Bon j'ai pas testé tout le jeu dans les moindres recoins pour être sûr que ça ne bug pas à un moment donné donc je laisse le lien pour ceux qui veulent faire bêta testeur.

Link version 0.9: https://drive.google.com/file/d/1G5qFueAgQotbkzkOZzeA4DOHpNya87k2/view

EDIT:
Bon bah ça existe déjà en fait: https://www.romhacking.net/hacks/1825/
Bon tant pis, au moins j'aurai appris un truc et récupérer un code pour switcher les boutons

Kaiser_Gun a écrit:

Sauf quand il faut aller écrire dans des octets pas utilisés parce que je ne sais pas encore qu'est ce qui se trouve où exactement à part la RAM.

Je suis pas sure d'avoir compris ce qui t'intéroge.

Kaiser_Gun a écrit:

Je n’aimais pas trop l'ergonomie de Double Dragon 2 qui a un peu vieillie.

A la base, lorsque le personnage est tourné à droite le Punch est sur A et quand il est tourné à gauche le Punch est sur B. Ca ajoute du challenge certes mais ça peut être relou pour les plus jeunes.

C'est le gameplay d'origine du premier Kunio Kun / Renegade sur lequel s'appuie Double Dragon  

Citation :

J'ai donc hacké la rom pour une ergonomie plus moderne. Le Punch et Kick restent en permanence A et B. Bon j'ai pas testé tout le jeu dans les moindres recoins pour être sûr que ça ne bug pas à un moment donné donc je laisse le lien pour ceux qui veulent faire bêta testeur.

Link version 0.9: https://bit.ly/2QZwDis

EDIT:
Bon bah ça existe déjà en fait: https://www.romhacking.net/hacks/1825/
Bon tant pis, au moins j'aurai appris un truc et récupérer un code pour switcher les boutons

Voila ca y est tu l'a fait   .
Et effectivement sur Romhacking y a deja beaucoup de chose.
Par contre j'ai pas pu DL ta version. Ca m'ouvre plein de page de pub en me demandant de cliquer sur plein de truc pour ajouter des extension chrome ou autoriser des notifications (sur lesquels je cliquerais pas) mais pas de trace du fichier.
Les gars pour chaque compte google vous avez 15Go gratos pour stocker n'importe quelle type de fichier avec lien DL direct et tout ce gère dans une page web (facon Gmail).

Voilà j'ai changé le lien.

Je n'ai pas vraiment compris parce que quand je mets directement "https://bit.ly/2QZwDis" ça rajoute un truc automatiquement au début

Upsilandre a écrit:

Voila ca y est tu l'a fait win .

Merci à toi, sans ton aide je serai encore entrain de patauger.

J'ai pas mal regardé le début de la vidéo où tu hackes Shadow Ninja.
A partir du moment où j'ai compris que pour tester si le joueur a appuyé sur #$80 ou #$40 à l'aide d'un filtrage "AND #$C0" en 15min c'était plié.
Après le hack sur celui-là qui me paraîssait un peu dur, bah en fait c'était juste 3 instructions à virer.
Je ne connaissais pas Renegade avant que tu en parles mais oui du coup c'était bien intentionnel comme je l'imaginais. Je pensais néanmoins que c'était juste pour se différencier des beat'em up de l'époque. Je n'ai pas vraiment de culture sur console pour ce genre et cette époque.

Mesen est vraiment un très bel outil.
Surtout la feature "Find Occurence" qui te permet de voir rapidement toutes les lignes qui utilisent le label que tu as indiqué. Ça rend vraiment le debug/hacking bien plus agréable.

Je vais essayer de faire évoluer un peu le hack sur Double Dragon.
Le premier testeur qui a essayé m'avait demandé si c'était normal que le coup de pied partait en arrière. Les deux prochaines étapes que je vais essayer :

1/ Faire en sorte que le coup de pied soit fait devant le joueur.
J'ai déjà trouvé l'octet pour les AnimationState je ne sais pas s'il faut que je creuse de ce côté mais ça sera important pour le second point.
L'idéal ça serait juste d'inverser les branchements et espérer que les collisions suivent. Pour l'instant je n'ai aucune idée de comment c'est gérer les collisions dans le jeu.

2/ Combos
Si le point précédent fonctionne, je pense qu'on perdra un peu en profondeur de jeu. Du coup je vais voir si on ne peut pas implémenter des combos :
- Punch, Kick, Hypercut
- Punch, Punch, Kick, Hypercut

On reste dans le simple malgré tout.

La oui j'ai pu tester. Ca a l'aire de fonctionner  

Kaiser_Gun a écrit:

Après le hack sur celui-là qui me paraîssait un peu dur, bah en fait c'était juste 3 instructions à virer.

C'est la magie du hack. Parfois tu arrives a tes fin en changeant 1 ou 2 octets et parfois pour faire un truc tout simple tu te retrouve face a un sac de nœud improbable (ca m'est deja arrivé une fois d'etre incapable de comprendre la gestion des inputs d'un jeu a moins d'y passer plusieurs jours mais je me souviens plus lequel). Plus tu t'attaque a des jeux de seconde zone assez mal fichu, plus y a de chance que le code soit illisible.
On pourrait croire que les jeux très bien codé sont très optimisé et pourrait donc etre difficilement lisible mais en général c'est pas le cas, c'est ceux la qui sont le plus lisible et le plus simple a hacké.

Citation :

Je ne connaissais pas Renegade avant que tu en parles mais oui du coup c'était bien intentionnel comme je l'imaginais. Je pensais néanmoins que c'était juste pour se différencier des beat'em up de l'époque. Je n'ai pas vraiment de culture sur console pour ce genre et cette époque.

Kunio Kun c'est tout une série de jeux Technos assez culte au Japon, y a des gens qui collectionne cette série, ca va de la baston a divers jeux de sport  (on les reconnait surtout a ces personnages SD très carré) mais nous on a découvert Kunio Kun au travers de l'adaptation occidental "Renegade" qui a été assez culte sur les micro 8bit (notamment l'Amstrad CPC) et Renegade c'est le Kunio Kun qui a lancé le genre Beat Them All et qui a donné naissance a Double Dragon juste apres (meme si Renegade ca reste de la baston en arène et solo donc c'est pas encore du Double Dragon mais les mécaniques sont la)
Et dans le genre baston Kunio Kun sur NES y a River City qui est est vraiment excellent. C'est du double Dragon mais avec un petit coté open world et rpg et qui se passe dans le millieu des gangs d'étudiant (sur la version jap ca va etre des gang d'étudiant a la japonaise et dans River City ca sera a l’américaine, y a aussi pas mal de mécanique qui change entre les 2 il me semble). C'est assez culte. Je te conseille de tester ca quelques minutes.

Citation :

Mesen est vraiment un très bel outil.
Surtout la feature "Find Occurence" qui te permet de voir rapidement toutes les lignes qui utilisent le label que tu as indiqué. Ça rend vraiment le debug/hacking bien plus agréable.

C'est vrai que je l'utilise pas assez.

Citation :

1/ Faire en sorte que le coup de pied soit fait devant le joueur.
J'ai déjà trouvé l'octet pour les AnimationState je ne sais pas s'il faut que je creuse de ce côté mais ça sera important pour le second point.
L'idéal ça serait juste d'inverser les branchements et espérer que les collisions suivent. Pour l'instant je n'ai aucune idée de comment c'est gérer les collisions dans le jeu.

En général t'as un octet qui représenté effectivement l'etape de d'animation (pour pointer vers le bon sprite) et un autre qui représente l'etat du joueur (pour selectionner la logique et la physique associé a cette etat). Toi c'est plutot le second qu'il faudrait trouver. La distinction se fait en général sur la marche. Si quand tu marche l'octet n’arrête pas de changer de valeur ca veut dire que c'est celui qui concerne les animations plus que l'etat physique du joueur.

Mais effectivement c'est possible que tu puisse regler ton probleme juste en agissant sur la maj de cette état. Ca peut se regler assez rapidement (mais avec le hack on sait jamais a l'avance). Mais du coup va falloir aussi que tu regle le fait que le perso se retourne quand il enchaîne ses 2 coup de pied (mais ca devrait etre du meme ordre).
Le combo ca sera sans doute plus complexe donc ca me parait etre le bon ordre pour faire ces choses.

upsilandre a écrit:

La oui j'ai pu tester. Ca a l'aire de fonctionner  

Kaiser_Gun a écrit:

Après le hack sur celui-là qui me paraîssait un peu dur, bah en fait c'était juste 3 instructions à virer.

C'est la magie du hack. Parfois tu arrives a tes fin en changeant 1 ou 2 octets et parfois pour faire un truc tout simple tu te retrouve face a un sac de nœud improbable (ca m'est deja arrivé une fois d'etre incapable de comprendre la gestion des inputs d'un jeu a moins d'y passer plusieurs jours mais je me souviens plus lequel). Plus tu t'attaque a des jeux de seconde zone assez mal fichu, plus y a de chance que le code soit illisible.
On pourrait croire que les jeux très bien codé sont très optimisé et pourrait donc etre difficilement lisible mais en général c'est pas le cas, c'est ceux la qui sont le plus lisible et le plus simple a hacké.

Citation :

Je ne connaissais pas Renegade avant que tu en parles mais oui du coup c'était bien intentionnel comme je l'imaginais. Je pensais néanmoins que c'était juste pour se différencier des beat'em up de l'époque. Je n'ai pas vraiment de culture sur console pour ce genre et cette époque.

Kunio Kun c'est tout une série de jeux Technos assez culte au Japon, y a des gens qui collectionne cette série, ca va de la baston a divers jeux de sport  (on les reconnait surtout a ces personnages SD très carré) mais nous on a découvert Kunio Kun au travers de l'adaptation occidental "Renegade" qui a été assez culte sur les micro 8bit (notamment l'Amstrad CPC) et Renegade c'est le Kunio Kun qui a lancé le genre Beat Them All et qui a donné naissance a Double Dragon juste apres (meme si Renegade ca reste de la baston en arène et solo donc c'est pas encore du Double Dragon mais les mécaniques sont la)
Et dans le genre baston Kunio Kun sur NES y a River City qui est est vraiment excellent. C'est du double Dragon mais avec un petit coté open world et rpg et qui se passe dans le millieu des gangs d'étudiant (sur la version jap ca va etre des gang d'étudiant a la japonaise et dans River City ca sera a l’américaine, y a aussi pas mal de mécanique qui change entre les 2 il me semble). C'est assez culte. Je te conseille de tester ca quelques minutes.

Citation :

Mesen est vraiment un très bel outil.
Surtout la feature "Find Occurence" qui te permet de voir rapidement toutes les lignes qui utilisent le label que tu as indiqué. Ça rend vraiment le debug/hacking bien plus agréable.

C'est vrai que je l'utilise pas assez.

Citation :

1/ Faire en sorte que le coup de pied soit fait devant le joueur.
J'ai déjà trouvé l'octet pour les AnimationState je ne sais pas s'il faut que je creuse de ce côté mais ça sera important pour le second point.
L'idéal ça serait juste d'inverser les branchements et espérer que les collisions suivent. Pour l'instant je n'ai aucune idée de comment c'est gérer les collisions dans le jeu.

En général t'as un octet qui représenté effectivement l'etape de d'animation (pour pointer vers le bon sprite) et un autre qui représente l'etat du joueur (pour selectionner la logique et la physique associé a cette etat). Toi c'est plutot le second qu'il faudrait trouver. La distinction se fait en général sur la marche. Si quand tu marche l'octet n’arrête pas de changer de valeur ca veut dire que c'est celui qui concerne les animations plus que l'etat physique du joueur.

Mais effectivement c'est possible que tu puisse regler ton probleme juste en agissant sur la maj de cette état. Ca peut se regler assez rapidement (mais avec le hack on sait jamais a l'avance). Mais du coup va falloir aussi que tu regle le fait que le perso se retourne quand il enchaîne ses 2 coup de pied (mais ca devrait etre du meme ordre).
Le combo ca sera sans doute plus complexe donc ca me parait etre le bon ordre pour faire ces choses.

Ouai j'ai déjà trouvé le PlayerState (la valeur qui indique si le P1 marche, punch ou kick saute) et le SpriteState (le sprite actuellement à l'image).
J'ai eu du bol parce que c'était pas trop loin des inputs. Sinon ça ne m'aurait pas traversé l'esprit d'entreprendre ce hack là.

Sinon sur le débuggeur de Mesen parfois j'ai des lignes surlignés en vert. Bon je n'ai pas encore compris pourquoi d'ailleurs. J'ai essayé une fois de mettre un breakpoint dedans sans arriver à y tomber.

Et je suis d'accord que les meilleurs jeux sont le plus souvent les mieux codés. Je le vois encore aujourd'hui. C'est le plus facile à déboguer pour n'importe qui. Mais même celui qui le code s'y retrouve plus facilement.
Je me demande d'ailleurs dans quel mesure River City et Double Dragon pourrait partager du code en commun.

C'est vraiment rigolo ce que tu dis sur River City parce qu'on dirait une ébauche de Yakuza en fait. Et bien que je le connaissais de nom, je n’ai pas encore testé. Ce que je ne vais pas tarder à faire. Mais dans le même état d'esprit en lassant des jeux random sur NES, je suis tombé sur Formula One Built To Win. Qui lui fait vraiment ébauche de Gran Turismo.
Et je crois que c'est ce que j'aime bien au final de retrouver les formes les plus simples possibles que puissent avoir une idée. Si le socle de départ fonctionne bien (fun) tout ce que tu rajoutes ne peut être que du pur bonus. Je commence à penser d'ailleurs que c'est comme ça qu'on arrive tranquillement à l'âge d'or du jeu vidéo.

Après Mesen joue pas mal sur la motivation aussi. Avoir un outil de debug comme ça c'est priceless.

Je ne vais pas te cacher que ça commence doucement à me démanger d'afficher des trucs. L'émulateur easy6502 c'est rigolo pour tester des bouts de code mais c'est tout.
Je ne sais pas si faire un tour sur Atari 2600 peut être intéressant. Pour l'instant je veux juste afficher un texte ou un score qui s'incrémente à mesure que j'appuis sur A.
Mais vu que ça n'est pas censé être ultra compliqué est-ce qu'il ne vaut mieux pas partir sur la NES directement. T'en penses quoi toi qui est passé par les deux?

Kaiser_Gun a écrit:

Sinon sur le débuggeur de Mesen parfois j'ai des lignes surlignés en vert. Bon je n'ai pas encore compris pourquoi d'ailleurs. J'ai essayé une fois de mettre un breakpoint dedans sans arriver à y tomber.

En vert c'est quand Mesen arrive a déduire indirectement que c'est du code (par exemple parce qu'il y a un branchement qui pointe dessus) mais sans avoir jamais exécuté ce bout de code jusqu'a maintenant (en général parce qu ec'ets un branchement conditionnel dont la condition n'a jamais été remplit jusque la).
En jaune c'est ce que Mesen identifie comme des data et en rouge c'est quand Mesen ne sait pas ce que c'est. Que ce soit le jaune ou le rouge tu peux le forcer a désassembler (le transformer en code asm) dans les options
Ce qu'il faut comprendre c'est que Mesen a un systeme de code/data logger. C'est a dire que pour chaque octets qu'il lit sur la ROM pendant l'execution il associe un tag (data ou code ou d'autre subtilité, par exemple il peut tager que c'est du data de sample DMC et mettre ca en orange. C'est surtout dans le memory tool que t'as plus de nuance sur l'identification des octets, quand tu veux avoir les details sur la signification des couleurs suffit de cliqué sur l'outils pour personnaliser les couleurs et ca t'indiquera tout ca). Tout ca est stocké dans un fichier .cdl (code data logger) qui fait la meme taille que la ROM et donc plus tu joue au jeu plus Mesen a d'information. Mesen exécute continuellement cette tache par défaut dès que le debugger est ouvert. Mais tu peux aussi reset ce fichier .cdl et parfois ca peut etre utile de le remettre a zero.
Le CDL c'est un bon moyen d'identifier des endroit non utilisé mais sinon tu peux aussi placer un breakpoint sur toute une zone mémoire que tu soupçonnes d'etre inutilisé (un breakpoint peut couvrir bien plus qu'un octet, les condition sur les breakpoint c'est utile parfois aussi), et joué au jeu avec ce breakpoint, tant que ca break pas c'est bon.

Citation :

Je me demande d'ailleurs dans quel mesure River City et Double Dragon pourrait partager du code en commun.

J'ai jamais vraiment eu l'occasion de tomber sur des routine vraiment semblable meme si y en a forcement plein. Parfois je retrouve le meme type de moteur par exemple la facon de gerer l'affichage des metasprite chez Capcom mais je me souviens pas avoir vu du pure copier-coller mais j'ai pas eu beaucoup d'occasion de le constater si ce n'est en ce moment avec les routines PCM. C'est la première fois que je constate vraiment des copier-coller. Par exemple entre Bayou Billy et Blade of Steel chez Konami c'est le meme code PCM. Et entre Bade Dudes et Heavy Barrel chez Data East.

Citation :

C'est vraiment rigolo ce que tu dis sur River City parce qu'on dirait une ébauche de Yakuza en fait. Et bien que je le connaissais de nom, je n’ai pas encore testé. Ce que je ne vais pas tarder à faire. Mais dans le même état d'esprit en lassant des jeux random sur NES, je suis tombé sur Formula One Built To Win. Qui lui fait vraiment ébauche de Gran Turismo.

ah oui il est très bien celui la, c'est complètement GT.

Citation :

Je ne vais pas te cacher que ça commence doucement à me démanger d'afficher des trucs. L'émulateur easy6502 c'est rigolo pour tester des bouts de code mais c'est tout.
Je ne sais pas si faire un tour sur Atari 2600 peut être intéressant. Pour l'instant je veux juste afficher un texte ou un score qui s'incrémente à mesure que j'appuis sur A.
Mais vu que ça n'est pas censé être ultra compliqué est-ce qu'il ne vaut mieux pas partir sur la NES directement. T'en penses quoi toi qui est passé par les deux?

Je dirais meme que ca serait bien plus compliqué de le faire sur Atari 2600 que sur NES. Sur Atari 2600 afficher un score qui s'incrémente ca peut etre hard, et surtout très exotique, ca te servira pas directement d’expérience pour les autres machine alors que la NES c'est assez conventionnel et assez proche de ce que tu trouvera sur les autres machine (et si un jour tu veux faire de la SNES tu retrouvera pas mal de similitude).
L'Atari 2600 c'est très intéressant mais seulement si tu veux découvrir un truc complètement exotique assez déconnecté des consoles 8bit/16bit classique (si ce n'est que effectivement tu connais maintenant l'assembleur 6502 donc c'est accessible), c'est un paradigme complètement différent donc ca peut t'embrouiller.

Sur NES faut juste que t'apprenne a acceder a la VRAM (avec les port $2006 et $2007 du PPU) et du coup devoir comprendre les notions de Vblank, nmi. Une fois que t'es familiarisé avec ca t'as l'essentiel de ce qu'il faut pour l'affichage.

J'ai trouvé la fonction qui détermine le lancement de l'animation.

C'est entre $9DE5-$9DFC.

Code:

ChooseAnimationSide:
 LDY $19
 LDA AnimationFrame,Y
 AND #$7F
 STA AnimationFrame,Y
 LDA P1Side,Y
 AND #$80
 EOR #$80 ;Je dois dériver ici
 ORA AnimationFrame,Y
 STA AnimationFrame,Y
 RTS

Sauf que c'est pour toutes les animations. Du coup il faudrait que je dérive cette fonction vers une autres.
J'ai cru comprendre qu'on est dans la ROM à cet endroit. J'ai tenté un "JSR $86FD" mais je pense que ça marche pas parce qu'on est à un endroit inaccessible à ce moment là du programme.

Je voudrai juste savoir les raisons mais je ne sais pas trop où chercher. J'ai cru comprendre qu'on ne pouvait pas jumper n'importe où, mais je ne me rappelle plus vraiment pourquoi.

Ok j'ai compris que c'était un cas de bank switching. Et là ça commence à être intéressant.

EDIT: Pour l'instant j'ai dérivé le code vers un emplacement où j'ai des BRK sur plusieurs octets à la suite.
Je n'ai pas encore retourné le jeu pour savoir si on passe par là à un moment donné ou non
Ca me donnera une vraie raison de terminer le jeu. Je vais déjà écrire le code pour que ça fonctionne au début du jeu histoire d'avoir une idée du nombre d'octets que ça va me prendre la bidouille.


EDIT2: Ca a l'air de fonctionner. Sauf que maintenant certains ennemis se retournent dans l'autre sens quand ils font un certain coup. On va y réfléchir doucement.

EDIT3: Le problème précédent est réglé.
C'est cool parce que le combo punch, punch, kick, hypercut est là de base.
Reste à régler le dernier point qui est que quand je tape avec un kick, l'adversaire se retrouve projeté dans le sens inverse... enfin le sens original je veux dire.

A moins de toucher a de très vieux jeux t'aura toujours du bank switching.
Faut faire la distinction entre l'espace mémoire du CPU et la ROM, y a pas de lien direct entre les 2.
Dans l'espace memoire du CPU tu as la RAM ($0000-$07FF) et seulement une partie de la ROM qui se trouve en $8000-$FFFF (soit 32ko alors que ta cartouche a en général 128ko de PRG-ROM voir 256ko)

Avec un mapper MMC3 comme dans DD2 cette espace mémoire du CPU va etre divisé en 4 segment de 8ko ($8000-$9FFF et $A000-$BFFF et $C000-$DFFF et $E000-$FFFF) dans lesquelles peuvent s'insérer n'importe laquelle des 16 bank 8ko qui compose ta cartouche et ca peut switcher n'importe quand. Donc si tu veux modifier une routine vaut mieux rester dans le meme segment.
Ces segments et ces bank sont détaillé tout en bas du debugger (j'en ai parlé vite fait dans la vidéo)

Ca c'est un concept que tu trouvera sur a peu pret toutes les machines 8bit car les CPU 8bit ont un bus d'adressage limité a 16bit (et meme bridé a 13bit sur VCS) et c'est rarement suffisant.
Tu retrouvera ca aussi sur le PPU de la NES avec des bank qui peuvent etre de 1ko
Tout ca dépend du mapper dans la cartouche. Un très bon mapper NES c'est un mapper qui a une granularité 8ko sur la PRG-ROM et 1ko sur la CHR-ROM. Un mapper archaïque ca va etre plutôt une granularité 32ko sur la PRG-ROM et 8ko sur la CHR-ROM.

upsilandre a écrit:

A moins de touché a de très vieux jeux t'aura toujours du bank switching.
Faut faire la distinction entre l'espace mémoire du CPU et la ROM, y a pas de lien direct entre les 2.
Dans l'espace memoire du CPU tu as la RAM ($0000-$07FF) et seulement une partie de la ROM qui se trouve en $8000-$FFFF (soit 32ko alors que ta cartouche a en général 128ko de PRG-ROM voir 256ko)

Avec un mapper MMC3 comme dans DD2 cette espace mémoire du CPU va etre divisé en 4 segment de 8ko ($8000-$9FFF et $A000-$BFFF et $C000-$DFFF et $E000-$FFFF) dans lesquelles peuvent s'insérer n'importe laquelle des 16 bank 8ko qui compose ta cartouche et ca peut switcher n'importe quand. Donc si tu veux modifier une routine vaut mieux rester dans le meme segment.
Ces segments et ces bank sont détaillé tout en bas du debugger (j'en ai parlé vite fait dans la vidéo)

Ouai c'est ça, j'avais pas capté que j'étais sur une cartouche de 256ko avant de reloader le jeu.
Je n'ai pas trop voulu me prendre la tête du coup j'ai inséré le nouveau code dans le bank en cours.

Me reste à changer les valeurs du kick quand celui-ci provoque une projection. Je vais creuser du côté des collisions.

Bon bah voilà c'est fini : https://drive.google.com/file/d/1n7c7crVF9HkZ7lpqsPvw3v2Q4XGwCTrl/view?usp=sharing

Finalement je n'ai rien eu à faire pour les histoires de combo, ça s'est fait naturellement. Le jeu est tout de même bien codé je trouve.
J'ai aussi mi la version originale pour ceux qui souhaiteront comparer.

Kaiser_Gun a écrit:

Bon bah voilà c'est fini : https://drive.google.com/file/d/1n7c7crVF9HkZ7lpqsPvw3v2Q4XGwCTrl/view?usp=sharing

Finalement je n'ai rien eu à faire pour les histoires de combo, ça s'est fait naturellement. Le jeu est tout de même bien codé je trouve.
J'ai aussi mi la version originale pour ceux qui souhaiteront comparer.

Une ch'tite video

patataboy a écrit:

Kaiser_Gun a écrit:

Bon bah voilà c'est fini : https://drive.google.com/file/d/1n7c7crVF9HkZ7lpqsPvw3v2Q4XGwCTrl/view?usp=sharing

Finalement je n'ai rien eu à faire pour les histoires de combo, ça s'est fait naturellement. Le jeu est tout de même bien codé je trouve.
J'ai aussi mi la version originale pour ceux qui souhaiteront comparer.

Une ch'tite video

Du coup je me fais un peu chier. Je pensais en avoir jusqu'à dimanche prochain.

Je vais convertir le jeu en fichier installable sur 3DS. Juste pour ne plus avoir à allumer le PC.
Et ce week-end je vais juste empêcher le fait de pouvoir sélectionner le mode 2P et virer le texte s'y afférent. Ça fera un truc propre.