Re: Besoin d'aide pour un "redone" de Ghost'n Goblins sur Nes.

[upsilandre]

J'ai bien creusé, j'ai maintenant une bonne vision du sprite engine de MM3. Le coeur des data du sprite engine est composé principalement de 3 tables de data + 3 tables de pointeurs (les tables de pointeurs sont composés de 2 tables de 256 octets, l'une contient les octets de poid faible et l'autre les octets de poid fort) qui sont dans 2 bank PGR distinct de 8ko (elles sont placer l'une apres l'autre dans le fichier ROM) et qui sont utilisé simultanement (le bankswitching va juste inverser leur emplacement dans le mapping CPU par rapport a leur emplacement réel dans la ROM).

Si on prend par exemple le sprite 0 qui est megaman au repos.
Son ID est donc 0 et permet a partir de la premiere table de pointeur de charger le pointeur vers la premier table de data qui contient la sequence d'animation de ce sprite. Y a un octet pour dire combien de frames dans la sequence, un octet pour indiquer la durée de chaque frame et ensuite un octet par frame qui indique l'ID de chaque frame.
l'ID de chaque frame permet de récuperer dans la seconde table de pointeur le pointeur vers la seconde table de data qui contient toutes les frames. Chaque frame est composé d'un octet qui indique le nombre de tiles utilisés dans cette frame, d'un deuxieme octet qui donne l'ID des coordonnées associer a cette frame et ensuite une serie de double octet pour chaque tile qui indique l'ID de la tile et sa palette.
Le second octet des data de la frame permet donc d'aller cherche (cette fois dans la second bank) dans la 3eme table de pointeur le pointeur vers la 3eme table de data qui contient les coordonnés X,Y de chaque tile de la frame sous la forme simplement d'une liste de double octet qui indique la valeur Y et X de chaque tile.
L'interet de cette enchevêtrement c'est que la liste de coordonnée X,Y des tiles est dissocié des frames qui contiennent l'ID des tiles. Je reprend l'exemple du sprite 0 de Megaman au repos. C'est un sprite qui contient 11 frames , 10 fois la meme frame de megaman au repos + une 11eme frame de megaman au repos mais les yeux fermé. du coup la frame de megaman les yeux ouvert et celle de Megaman les yeux fermé ont une liste de tiles differentes mais pointe vers la meme liste de coordonnée utilsié pour ces tiles donc ca économise une liste de coordonnée X,Y car certaines frames partagent donc la meme liste de coordonnée.

J'ai mantenant bien repéré ou sont placé toutes ces tables.
Ensuite pour la ROM odyssey quand il a fait la conversion MMC5 il en a aussi profité pour etendre la ROM qui passe d'une configuration de 256Ko de PGR-ROM + 128Ko de CHR-ROM a 512Ko de PGR-ROM + 512Ko de CHR-ROM (logique puisque l'interet du MMC5 c'est d'avoir un tileset directement indexable de 256Ko juste pour le background + donc 256Ko pour les sprites) . Du coup effectivement  les tiles des sprites ne sont plus au meme endroit, au lieu d'avoir 64Ko entre $40000-4FFFF y a 256Ko entre C0000-FFFFF (+ les 10 octets de header)

Mais le plus compliqué c'est pas tant les patterns que les data des sprites de la PGR-ROM. De ce coté Odyssey utilise les meme bank PGR que MM3 donc c'est plutot cool. Il a par contre modifier le nombre de "sprite" possible qui passe de 128 a 256 du coup ca a décaler l'adresse des tables de pointeur car la table d'ID des sprites est plus longue.
L'autre truc qui a changé et qui est plutot bisarre c'est que dans sa table de pointeur de la table de coordonnée il a retrancher 2 a l'adresse réel de chaque pointeur, je sais pas pourquoi mais du coup ca fout le bordel.
J'ai remarqué aussi une autre difference dans la gestion du sprite de megaman, au lieu de mapper dans le PPU 2 bank de tiles fixe comme sur MM3, dans Odyssey la premier bank de sprite va switcher selon l'action de megaman donc tu peux pas avoir en meme temps le sprite de megaman qui court et celui ou il saute ni celui ou il monte une echelle qui est encore dans une autre bank, c'est une methode assez classique mais qui n'etait pas utilisé dans MM3 donc c'est un peux chiant pour le CSA tool car tu peux pas avoir tout les sprites de megaman en meme temps.


Par contre le truc vraiment chouette c'est que CSA te propose de pouvoir créer des modules de configuration selon chaque ROM (le fichier qu'il te demande de charger apres chaque ROM).
Du coup j'ai pu modifier la liste de bank CHR qu'il charge pour mettre les bonnes. J'ai pu aussi modifier l'adresse des tables de pointeurs pour mettres les bonnes et heureusement ils avaient meme prevu de pouvoir modifier l'offset de la table de coordonnée ce qui m'a permis de corriger les 2 octets qui etaient retrancher a chaque pointeur.


Par contre CSA ne fait que charger 4Ko de tile que tu lui indique dans la configuration du module donc meme avec un classique MM3 quand tu fais defiler la liste de sprite seul ceux qui utilisent ces 4Ko de bank CHR que tu a selectionner s'afficheront correctement donc quelque soit la ROM CSA necessite quand meme de trouver soit meme les bank CHR des sprites qui nous intéresse et dans Odyssey meme le sprite de megaman est maintenant répartie dans des bank qui ne peuvent pas etre utilisé simultanement donc je t'ai fais deja 3 fichiers qui chacun permettent d'acceder a differents sprites de Megaman ainsi que certain ennemis, ca en fait deja quelque uns pour tester.

https://drive.google.com/open?id=0B399kteofpYuZTlpNVl1bzhrUGc
https://drive.google.com/open?id=0B399kteofpYuYnQ1SlR5V05neEU
https://drive.google.com/open?id=0B399kteofpYuSzVBUFRPVk5JOVk
(cliquer sur l'icone en haut pour telecharger)

Ca c'est donc les fichiers de configuration a ranger dans le dossier "support" de CSA.
A partir de la a priori tu peux modifier maintenant les sprites de Odyssey avec CSA, j'ai essayé vite fait ca a l'aire de marcher. Tu utilises bien la ROM Odyssey de mars 2010?
Par contre j'ai toujours pas compris comment tu composais ton sprite de Arthur car CSA permet de modifier certaine chose mais pas d'autre. On peut modifier les sprites (pattern, coordonnée...) mais sans pouvoir changer le nombre de tiles ou de frames (sur Megaman4 on peut changer le nombre de frame mais c'est le seul), faut rester dans le format du sprite d'origine. Donc j'ai pas trop compris comment t'avais remplacer le sprite de megaman par le sprite Arthur en 3 layers sans pouvoir modifier notamment le nombre de tile du sprite?

EDIT: je vois que sur ta demo t'as laisser tomber le 3eme layer de Arthur?

[Alucardark]

Ca c'est donc les fichiers de configuration a ranger dans le dossier support de CSA.
A partir de la a priori tu peux modifier maintenant les sprites de Odyssey avec CSA, j'ai essayé vite fait ca a l'aire de marcher. Tu utilises bien la ROM Odyssey de mars 2010?
Par contre j'ai toujours pas compris comment tu composais ton sprite de Arthur car CSA permet de modifier certaine chose mais pas d'autre. On peut modifier les sprites (pattern, coordonnée...) mais sans pouvoir changer le nombre de tiles ou de frames (sur Megaman4 on peut changer le nombre de frame mais c'est le seul), faut rester dans le format du sprite d'origine. Donc j'ai pas trop compris comment t'avais remplacer le sprite de megaman par le sprite Arthur en 3 layers sans pouvoir modifier notamment le nombre de tile du sprite?

EDIT: je vois que sur ta demo t'as laisser tomber le 3eme layer de Arthur?

Alors déjà un grand merci d'avoir pris le temps de modifier le CSA Editor (et tu as fait ça super rapidement, franchement merci  ). Sinon effectivement, j'utilise la rom d'Odyssey de 2010 car le custom MegaFLE X ne marche bien qu'avec cette version (et non avec la demo 4). Pour le sprite d'Arthur, j'ai modifié ça directement via le hex editor de FCEUX (et j'ai galérer jusqu'à comprendre comment fonctionnait le data logger), j'ai donc changé le nombre de tuiles disponibles pour le sprite (passant de 8 à 13) et franchement ça m'a bien aidé. J'ai dû laisser tomber le 3e layer momentanément le temps de voir ce que ça va donner avec tous les ennemis à l'écran (ça clignote déjà un peu quand je tire sur les pierres tombales, je vais donc essayer de recomposer les sprites avec le moins de layers possible). 
Par contre, je ne sais pas comment est géré la barre d'énergie car je n'arrive pas à composer le hud de Ghost'n Goblins en utilisant les tuiles de la barre d'énergie.

[upsilandre]

C'est vrai que si CSA le permet pas on peut quand meme modifier manuellement le nombre de tile par sprite en tapant dans la table des frames, par contre ca fait bugger le sprite suivant (ou precedent) qui sera perdu a moins de modifier aussi les tables de pointeurs pour decaler de proche en proche jusqu'a trouver un sprite a sacrifier. Un peu chiant mais ca peut etre fait proprement.

Le HUD (barre de vie) a priori ne fait pas partie de la liste de sprite, il est géré sans doute de facon independante et complètement differente. Il sera certainement possible de le modifier en aparance et le deplacer sauf que dans GG y a pas de barre de vie donc y a pas d'equivalent en terme de fonction donc ce que tu veux c'est pas juste changer l'apparence mais changer la fonction ce qui va etre bien plus compliqué.
Meme si par miracle on change le fonctionnement du HUD Il sera de toute facon pas possible de reproduire tout le hud du jeu original avec des sprites meme partiellement ca va etre compliqué. En plus y a pas d'information capital dans le hud de GG, ca me parait pas une priorité meme si c'est vrai que ca joue sur l'identité du jeu, faudra y reflechir plus longuement.

Alors déjà un grand merci d'avoir pris le temps de modifier le CSA Editor (et tu as fait ça super rapidement, franchement merci  ).

Ca m'a bouffer toute la journée quand meme depuis le matin
Mais je regrette pas car j'ai apprit des truc, ca me donne une idée plus précise de ce a quoi peut ressembler un sprite engine sur NES et c'est justement un des truc qui me manquait. Je l'ai fais parce que j'y trouve aussi mon compte.

[Alucardark]

J'avais essayé à l'époque d'intégrer le sprite d'Arthur sur Megaman 4 (via le CSA Editor justement), et hormis 2/3 petits bugs en fonction du sens où se trouvait Arthur, ça rendait plutôt bien. En tout cas j'utiliserai le CSA Editor pour assembler mes sprites (ça ira beaucoup plus vite grâce à toi :) ).

Pour le hud si tu regardes les tuiles que j'ai mis, je pense que c'est faisable car y a beaucoup de sprites en double. Mais bon comme tu as dit, je vais me concentrer sur l'essentiel pour le moment (et c'est déjà un sacré chantier ).
J'aurais une question (et pas des moindres) concernant la pierre tombale, comme t'as dû le remarquer j'ai utilisé un metool pour le faire. Je voulais donc savoir comment modifier son comportement pour qu'il reste statique et inoffensif, mais aussi l'utiliser comme plate forme?

Ca m'a bouffer toute la journée quand meme depuis le matin  
Mais je regrette pas car j'ai apprit des truc, ca me donne une idée plus précise de ce a quoi peut ressembler un sprite engine sur NES et c'est justement un des truc qui me manquait. Je l'ai fais parce que j'y trouve aussi mon compte. 

Oui je comprends car crois-moi que je ne le fais pas que pour le kiff de voir une version proche de l'arcade de Ghost'n Goblins, je le fais aussi pour ma compréhension du MMC5, voire comment il fonctionne. 

[Alucardark]

Petite update.

J'ai réussi à trouver un sprite qui fait office de pierre tombale (à savoir, inoffensif et sur lequel on puisse se poser).



Bon par contre la 2e pierre tombale est toujours un ennemi (un metool dans mon cas) et je n'ai toujours pas réussi à savoir comment, ni où modifier son comportement.

[upsilandre]

Y a surement des bidouilles possibles mais ca sera vraiment du bricolage au cas par cas et y aura toujours un truc qui colle pas, puis ensuite faudra trouver un moyen de simuler les comportement, les interactions, les armes, le boss, le hud... on arrive selon moi dans une zone de perversion du rom hacking, quand faut recoder un jeu pour le transformer en un autre ca devient de la folie car ca peut etre plus ou moins aussi complexe que de le faire "from scratch" mais sans le coté gratifiant (et tres important) d'avoir fait ton truc a toi. Decrypter ce que quelqu'un d'autre a fait pour pouvoir le modifier c'est tres tres fastidieux. Et puis si t'arrive a transformer un jeu en un autre alors c'est que t'as les competences pour faire un jeu de zero.

En tout cas pour ma part et pour te repondre c'est pas quelque chose sur lequel j'aurais envie de passer du temps. Le rom hacking c'est amusant quand c'est des petits truc (y a 3 semaines j'ai fais Dragon Quest 1 en entier puis je me suis amusé a le hacké un petit peu, mettre 60 000 pieces d'or dans le premier coffre ou l'on débute, mettre une clé magique non consommable qui ouvre toutes les portes dans le second coffre, tracé un sentier par dessus la mer pour relier le premier chateau ou l'on débute et le chateau final qui se font face... Ca c'est marrant) mais quand ca nécessite de remodeler vraiment le code ca me tente plus malgres que en décryptant le code de professionnel en général t'apprend forcement des truc donc c'est intéressant mais y a quand meme plus efficace en temps pour apprendre.

Si j'avais du temps pour ca je le consacrerais plutot a démarrer un truc de zero pour le plaisir. Normalement j'avais prevu de porter le premier level de Alex kidd, j'avais deja préparer le terrain mais c'etait y a un an puis j'ai fais d'autre truc au final donc j'ai toujours pas vraiment commencé a coder sur NES j'en suis resté a l'Atari 2600 (qui a quand meme le meme CPU) mais si je dois faire un truc ca sera ca, ca me permettra de m'entrainer et qui sait, une fois que j'aurais un peu d'experience pourquoi pas faire une ebauche de GG MMC5 from scratch a 2. J'aime toujours bien l'idée car je suis fan de cette série et dans un contexte idéal ou je gagne au loto et ou je peux arreter de travailler alors c'est certainement ce que je ferais, dans le monde réel c'est deja beaucoup plus hypothétique comme scénario parce que c'est des centaines d'heures.

[Alucardark]

Y a surement des bidouilles possibles mais ca sera vraiment du bricolage au cas par cas et y aura toujours un truc qui colle pas, puis ensuite faudra trouver un moyen de simuler les comportement, les interactions, les armes, le boss, le hud... on arrive selon moi dans une zone de perversion du rom hacking, quand faut recoder un jeu pour le transformer en un autre ca devient de la folie car ca peut etre plus ou moins aussi complexe que de le faire "from scratch" mais sans le coté gratifiant (et tres important) d'avoir fait ton truc a toi. Decrypter ce que quelqu'un d'autre a fait pour pouvoir le modifier c'est tres tres fastidieux. Et puis si t'arrive a transformer un jeu en un autre alors c'est que t'as les competences pour faire un jeu de zero.

En tout cas pour ma part et pour te repondre c'est pas quelque chose sur lequel j'aurais envie de passer du temps. Le rom hacking c'est amusant quand c'est des petits truc (y a 3 semaines j'ai fais Dragon Quest 1 en entier puis je me suis amusé a le hacké un petit peu, mettre 60 000 pieces d'or dans le premier coffre ou l'on débute, mettre une clé magique non consommable qui ouvre toutes les portes dans le second coffre, tracé un sentier par dessus la mer pour relier le premier chateau ou l'on débute et le chateau final qui se font face... Ca c'est marrant) mais quand ca nécessite de remodeler vraiment le code ca me tente plus malgres que en décryptant le code de professionnel en général t'apprend forcement des truc donc c'est intéressant mais y a quand meme plus efficace en temps pour apprendre.

Si j'avais du temps pour ca je le consacrerais plutot a démarrer un truc de zero pour le plaisir. Normalement j'avais prevu de porter le premier level de Alex kidd, j'avais deja préparer le terrain mais c'etait y a un an puis j'ai fais d'autre truc au final donc j'ai toujours pas vraiment commencé a coder sur NES j'en suis resté a l'Atari 2600 (qui a quand meme le meme CPU) mais si je dois faire un truc ca sera ca, ca me permettra de m'entrainer et qui sait, une fois que j'aurais un peu d'experience pourquoi pas faire une ebauche de GG MMC5 from scratch a 2. J'aime toujours bien l'idée car je suis fan de cette série et dans un contexte idéal ou je gagne au loto et ou je peux arreter de travailler alors c'est certainement ce que je ferais, dans le monde réel c'est deja beaucoup plus hypothétique comme scénario parce que c'est des centaines d'heures.  

J'avoue que ces derniers jours je me suis bien cassé les dents à essayer de faire ne serait-ce que le sprite d'Arthur au complet (là où j'avais réussi à le faire presque entièrement sur Megaman 4). Comme tu l'as dit, on passe son temps à décrypter le code au lieu d'avancer comme ça devrait être le cas si on repartait de zéro! Du coup, je pense juste à continuer les niveaux pour voir comment ça peut s'intégrer sur NES puis les poster ici pour le jour où toi, ou n'importe qui d'autre, aura suffisamment d'expérience (mais surtout l'envie) de faire un Ghost'n Goblins à zéro. En tout cas merci d'avoir pris le temps de regarder ça.

[upsilandre]

Sinon pour revenir a GG j'aimerais aussi voir une nouvelle version sur NES. Le GG NES me laisse une impression mitigé.
A la fois c'etait l'une des rare conversion réussit de l'epoque et un jeu qui arrive sur Famicom en 1986 , l'année charnière qui sonne le second départ de la Famicom apres des premières années un peu laborieuse qualitativement.
1986 arrive le Famicom Disk, l'explosion des ROMs et des mappers, et tout ca permet enfin de débloquer les créatif et le potentiel de la machine. Finit ces années a devoir composé des jeux avec 8Ko de pattern graphique non compressé comme budget total. On peut enfin profiter de la rupture du scrolling apporter par la Famicom et faire voyager le joueur.
GG arrive dans ce contexte et participe au lancement de cette nouvelle phase des jeux consoles et a donc marqué son epoque.

Mais d'un autre coté quand tu le décortique un petit peu y a l'aire d'y avoir plein de faiblesse technique, d'approximation. Je pense que le jeu a ete fait assez vite et avec les moyens et l'experience de l'epoque.
C'etait la toute première cartouche 1Mbit au tout debut du boom de la capacité des ROMs et du coup j'ai l'impression que c'etait pas prévu. Je suis convaincu que le jeu a ete concu au depart sur une base 512Kbit car dans la cartouche c'est plein de vide et surtout plein de redondance de pattern de sprite. Les sprites sont en 7,8 voir 9 exemplaire alors meme que c'est la premiere cartouche aussi a utiliser le mapper UNROM qui utilise de la CHR-RAM qui a pour interet justement de pouvoir construire sur mesure ton tileset et eviter toute redondance dans les bank graphiques (puisqu'il n'y en a pas).
Et puis on voit bien que c'est des pools complet de sprite (avec tous les ennemis) qui ne sont pas utilisé, par exemple on retrouve 5 fois le meme pool complet de sprite qui contient chaque fois le meme sprite de zombie qui n'est pas celui utilisé dans le jeu.
Ensuite y a certain pool qui sont probablement des variantes constitué pour simplifier les chargement mais c'est sans doute des choix apres coup pour remplir la place supplémentaire qu'on leur a donnée au dernier moment et pas une volonté premiere. Je pense qu'une equipe expérimenté te fait rentrer le meme jeu dans 64Ko au lieu de 128Ko (parce exemple Rare etaient tres bon sur NES).

Ensuite y a aussi quand meme un probleme d'animation. Le jeu tourne a 20fps alors que la norme c'est 60fps sur NES, 30fps c'est deja rare mais 20fps ca doit se compter sur les doigt de la main. Et en plus c'est pas du 20fps propre, c'est du 20fps avec judder (un coup 4 frames, un coup 2 frames, c'est degeu) et en plus les sprites et le scrolling sont désynchronisé ce qui donne un effet de flottement aux items (qui du coup se déplace pas en meme temps que le background)

Un truc aussi qui m’agaçe dans cette version c'est que dès la premiere seconde de jeu y a trahison avec ces zombies rouge au cheveux bleu alors qu'ils sont censé etre bleu au cheveu rouge. Alors on pourrait se dire que sur NES on choisie pas vraiment ses couleurs car t'as que 4 palettes pour les sprites (dont 2 utilisé pour Arthur, 2 pour les zombies...) et donc faut partager les palettes entre plein de sprites...
Mais au final j'ai quand meme reussit a faire un hack qui rectifie cette faute de gout (meme si c'etait quand meme un peu galère). C'etait donc tout a fait possible alors pourquoi ne pas l'avoir fait?


Du coup j'ai du regarder un peu comment etait géré les sprites et ca m'a paru aussi comme un sacré bordel mal optimisé comparé au sprite engine de Megaman. Et puis y a par exemple cette superposition de sprite sur les zombies que je ne comprend pas du tout. Ils ont 2 abdomens superposés l'un sur l'autre! ca fait des zombie qui font 3 sprites de large en plein milieu et c'est la fete au clignotement! C'etait a priori completement évitable. Y a en tout cas de la marge pour l'ameliorer je pense.

[upsilandre]

Alucardark:

Oui faut garder les assets, ils serviront forcement un jour car ils sont chouettes. Et puis continuer comme tu a fais en les intégrant a une demo ou l'on peut se balader dedans juste avec un Arthur complet, c'est deja classe et ca peut motiver des gens, c'est une facon de mette une pierre a l'edifice, c'est deja un projet accomplie en soi.

[Alucardark]

upsilandre :

Oui c'est ce qui m'a fait me lancer sur un "Redone" du jeu ("Remake" n'étant pas approprié étant donné que je veux me rapprocher de l'arcade et non faire une relecture du jeu), autant d'un point de vue graphique pour l'époque ça allait (faut pas oublier qu'ils a été converti sur NES en 9/10 mois) mais il était vraiment discutable au niveau de la physique comme tu l'as dit plus haut (bordel 20 fps au mieux avec des désynchronisations, effectivement je comprends mieux pourquoi le sprite avait l'air de flotter). C'est pour ça que j'ai pris un Rockman comme base pour le GNG, 60 fps, physique très bien foutue et gameplay assez proche d'un GNG. Du coup je me suis dit qu'il y avait moyen de modifier le code pour que ça se rapproche du gameplay de l'arcade, mais au final je me rend compte qu'il faudrait plusieurs hackeurs expérimentés pour effectuer toutes les modifications.

[Alucardark]

Oui faut garder les assets, ils serviront forcement un jour car ils sont chouettes. Et puis continuer comme tu a fais en les intégrant a une demo ou l'on peut se balader dedans juste avec un Arthur complet, c'est deja classe et ca peut motiver des gens, c'est une facon de mette une pierre a l'edifice, c'est deja un projet accomplie en soi.

Oui ça pourra toujours servir, et qui sait peut-être, motiver d'autres programmeurs à y jeter un œil. Pour la balade d'Arthur, ce n'est malheureusement pas pour tout de suite car je rencontre des difficultés à intégrer toutes les animations, je ne sais pas comment ils ont foutu leur bordel dans Megaman 3, mais c'est vraiment différent d'un Megaman 4 où j'ai pu mettre la quasi totalité des animations (il me manquait que le saut sur place à intégrer).

[upsilandre]

Megaman 3 c'est une configuration de cartouche a base de CHR-ROM alors que Megaman 4 c'est a base de CHR-RAM donc c'est 2 approches differentes (ca a toujours ete un peu un dileme de choisir entre ces 2 possibilités offerte par la NES, y avait pas ce genre de choix sur les autres consoles), ca doit surement se ressentir quelque part car c'est assez different.

[Alucardark]

Megaman 3 c'est une configuration de cartouche a base de CHR-ROM alors que Megaman 4 c'est a base de CHR-RAM donc c'est 2 approches differentes (ca a toujours ete un peu un dileme de choisir entre ces 2 possibilités offerte par la NES, y avait pas ce genre de choix sur les autres consoles), ca doit surement se ressentir quelque part car c'est assez different.

En tout cas la possibilité du 4 de passer par la CHR-RAM facilite beaucoup les choses concernant les sprites, dommage qu'il n'y ait pas eu de MegaFLE X utilisant le MMC5 pour Megaman 4.
Je vais passer du coq à l'âne, mais saurais-tu comment on lit et modifie la ram avec Fceux (non parce que quand je vois par exemple un "$20" pour chercher une info vue sur une documentation, ben ça m'arrangerai bien de savoir comment faire une modif)?

[upsilandre]

tu ouvres l'Hex Editor et tu selectionnes "nes memory" ensuite suffit de modifier un octet (la RAM s'arrete a $7FF donc ne va pas plus loin c'est de la ROM et on t'autorisera pas la modification par ce menu)

[Alucardark]

tu ouvres l'Hex Editor et tu selectionnes "nes memory" ensuite suffit de modifier un octet (la RAM s'arrete a $7FF donc ne va pas plus loin c'est de la ROM et on t'autorisera pas la modification par ce menu)

Oui voilà, c'est ce signe de "$" que je n'arrive jamais à saisir (même quand je cherche). 
En tout cas merci pour ta réponse.

[upsilandre]

tu ouvres l'Hex Editor et tu selectionnes "nes memory" ensuite suffit de modifier un octet (la RAM s'arrete a $7FF donc ne va pas plus loin c'est de la ROM et on t'autorisera pas la modification par ce menu)

Oui voilà, c'est ce signe de "$" que je n'arrive jamais à saisir (même quand je cherche). 
En tout cas merci pour ta réponse.

"$" ca veut juste dire que le nombre qui suis est en hexadecimale et pas en base 10. $7FF ca veut dire qu'il faut pas dépasser l'adresse 2047 mais dans hex editor de toute facon les adresses sont indiqué en hexa (et les valeurs aussi) donc c'est les valeurs hexa qui nous intéresse.
L'un des interet d'une valeur en hexa c'est que ca se decoupe facilement en binaire. par exemple un octet (donc 8bit) de valeur $A9 ca se découpe en 2. "A" nous indique les 4 bits de poid fort (les 4 premiers de l'octet) et "9" les 4 bit de poid faible. Du coup meme de tete tu peux faire la conversion en binaire (par exemple si tu veux modifier une pattern) alors que si on te donne la valeur decimale equivalente (169) pour la convertir en binaire de tete c'est compliqué.

[upsilandre]

J'ai peut etre pas compris ce que tu demandais. Je suis partie du principe que tu connaissais deja bien l'Hex Editor car il me semblait t'avoir vu le manipuler.
Modifier $20 en RAM ca veut dire modifier l'octet a cette adresse ou j'ai mis mon curseur

L'autre facon d'ecrire $20 en Hexa c'est 0x20 , c'est ce que tu vois ecrit en haut de la fenetre qui indique l'adresse du curseur.

L'interet de l'hexadecimal dans l'adressage c'est que les chip manipule des valeurs binaire et l'adressage aussi du coup les mémoires on des capacités qui sont des comptes rond... en binaire (2048 octets, 4096 octets ect...)
Et il se trouve qu'un compte rond en binaire est aussi un compte rond en Hexadecimale. Par exemple la valeur binaire 32bit 10000000000000000000000000000000 ca donne aussi un compte rond en hexa $80000000 alors qu'en décimal ca donne un truc qui n'a rien a voir (2147483648), y a toujours une correlation plus direct entre binaire et hexadecimale que ce soit pour les valeurs ou l'adressage.

Prend l'exemple de la NES, la ROM de la cartouche dans l'adressage mémoire CPU debute a l'adresse binaire b1000000000000000 ou en hexa $8000, dans les 2 cas c'est facile a repérer c'est un chiffre rond alors qu'en décimal ca serait 32768 (et pas 32767 ou 32769).
Ou par exemple pour sauter d'une bank CHR-ROM 8ko a une autre tu sais qu'il faut simplement ajouter $2000 a l'adressage  (c'est mieux que de devoir additionner 8192 )

[Woody 90]

tout dépend de ton editeur héxadecimal,je sais que sur des programmes différent l'adresse est jamais la meme .

[upsilandre]

tout dépend de ton editeur héxadecimal,je sais que sur des programmes différent l'adresse est jamais la meme .

mais la on parle du meme, celui intégré a Fceux.

[Woody 90]

celui intégré pas top je trouve , m'enfin si tu as l'habitude de bidouiller avec...

[upsilandre]

Si tu passe par un Hex editeur externe alors tu n'as plus acces a toute les fonctions que propose celui de Fceux comme justement pouvoir modifier la RAM en temps réel ou meme freezer un octet, les interactions avec le debuger ou le data/code logger, les codes couleurs qui t'indique les changements en temps réel, si c'est du code ou du data ect...

Ou alors tu veux dire remplacer vraiment l'hexediteur interne de Fceux par un autre qui intercepterait alors les memes fonctions? Fceux est assez flexible mais je ne crois pas que ce soit possible de faire ca.

[Alucardark]

J'ai peut etre pas compris ce que tu demandais. Je suis partie du principe que tu connaissais deja bien l'Hex Editor car il me semblait t'avoir vu le manipuler.
Modifier $20 en RAM ca veut dire modifier l'octet a cette adresse ou j'ai mis mon curseur

Oula, on va dire que je le connais mieux c'est sûr, mais je suis loin de bien le connaitre. J'ai effectivement manipulé l'hex editor grace à la doc fournie par Kuja Killer sur le MegaFLEX modifié, il donnait les adresses en "ROM header". C'est pour cela que je voulais connaitre les valeurs commençants en "$" car sur tous les sites ou toutes les autres docs, les adresses sont donnés en "RAM Offsets" (et j'ai vraiment du mal avec ça). Ça montre bien que je ne suis pas du tout programmeur étant donné que je n'ai même pas un début de base en programmation.
En tout cas merci beaucoup pour ces explications, ça va m'aider un peu plus (même si je vais me concentrer sur autre-chose ces prochains jours, les mises à jours risquent d'arriver au compte goutte mais je continuerai à convertir les assets).

[upsilandre]

Oui quand on te donne une adresse a modifier y a 3 cas:

- soit on te donne une adresse dans le fichier ROM (et qui donc va prendre en compte les 16 octet de header qui décale tout et aussi la répartition des bank) pour faire du rom hacking.

- soit on te donne une adresse dans l'espace d'adressage du CPU. A priori ca sera pour modifier la RAM et donc ca veut dire faire la modification pendant l'execution du jeu au moment qu'on t'indique et bien sure ca aura qu'un effet temporaire sur le jeu car tu ne modifie pas la ROM du jeu juste son execution. Une fois reset le jeu il redevient comme avant.

- soit on te donne une adresse dans l'espace d'adressage du GPU ce qui est encore moins probable. La aussi ca ne va pas modifier la ROM, juste l'execution du jeu de facon temporaire.


Dans Hex Editor de Fceux on te propose ces 3 modes dans "view".
L'adresse $20 (ou une autre) existe dans ces 3 modes mais correspond a des choses completements differentes donc faut effectivement bien comprendre ce qu'on te propose.
Mais en général tu sera toujours dans le premier cas si c'est pour du rom hacking. Le reste c'est plus pour les programmeurs.

[Alucardark]

Oui quand on te donne une adresse a modifier y a 3 cas:

- soit on te donne une adresse dans le fichier ROM (et qui donc va prendre en compte les 16 octet de header qui décale tout et aussi la répartition des bank) pour faire du rom hacking.

- soit on te donne une adresse dans l'espace d'adressage du CPU. A priori ca sera pour modifier la RAM et donc ca veut dire faire la modification pendant l'execution du jeu au moment qu'on t'indique et bien sure ca aura qu'un effet temporaire sur le jeu car tu ne modifie pas la ROM du jeu juste son execution. Une fois reset le jeu il redevient comme avant.

- soit on te donne une adresse dans l'espace d'adressage du GPU ce qui est encore moins probable. La aussi ca ne va pas modifier la ROM, juste l'execution du jeu de facon temporaire.


Dans Hex Editor de Fceux on te propose ces 3 modes dans "view".
L'adresse $20 (ou une autre) existe dans ces 3 modes mais correspond a des choses completements differentes donc faut effectivement bien comprendre ce qu'on te propose.
Mais en général tu sera toujours dans le premier cas si c'est pour du rom hacking. Le reste c'est plus pour les programmeurs.

Dans mon cas c'est effectivement le cas numéro 1 qui m'est accessible étant donné que je ne programme pas. En tout cas je commence à mieux saisir pourquoi sur les sites de rom hacking, ils donnent les adresses en CPU ou GPU, la plupart son programmeurs et de plus ils utilisent un désassembleur. Ça leur permet donc de faire (presque) ce qu'ils veulent un peu comme ici :
https://www.youtube.com/watch?v=M6EH-BIHcSM

ou encore là :
https://www.youtube.com/watch?v=EJXwbXB31S8

[upsilandre]

En tout cas moi je m'y suis mis pour de bon cette fois. J'ai deja réussit aujourd'hui a afficher et scroller un background (mono screen) et je suis deja contant car ca a marché quasi du premier coup, pas de galère  .

Le plus long c'etait de bien préparer mon environnement de devs (je l'ai deja dit mais je suis pas programmeur, j'ai aucun automatisme ni habitude de ce coté, la mise en place est toujours laborieuse), surtout bien comprendre le fonctionnement et les subtilités du compilateur ASM (j'ai pas prit le meme que pour la VCS) pour maitriser la production du fichier ROM avec les bons octets au bon endroit, bien placer le Header iNES, la PGR-ROM, la CHR-ROM, les pointeurs IRQ... avoir une bonne procedure de reset de la machine et d'initialisation, bien mettre en place la routine nmi (interruption vblank) et avoir dès le depart un fichier source propre et organisé.
Une fois cette etape un peu chiante passé le reste est deja plus agréable car on commence vraiment les choses concrètes.

[Alucardark]

En tout cas moi je m'y suis mis pour de bon cette fois. J'ai deja réussit aujourd'hui a afficher et scroller un background (mono screen) et je suis deja contant car ca a marché quasi du premier coup, pas de galère  .

Le plus long c'etait de bien préparer mon environnement de devs (je l'ai deja dit mais je suis pas programmeur, j'ai aucun automatisme ni habitude de ce coté, la mise en place est toujours laborieuse), surtout bien comprendre le fonctionnement et les subtilités du compilateur ASM (j'ai pas prit le meme que pour la VCS) pour maitriser la production du fichier ROM avec les bons octets au bon endroit, bien placer le Header iNES, la PGR-ROM, la CHR-ROM, les pointeurs IRQ... avoir une bonne procedure de reset de la machine et d'initialisation, bien mettre en place la routine nmi (interruption vblank) et avoir dès le depart un fichier source propre et organisé.
Une fois cette etape un peu chiante passé le reste est deja plus agréable car on commence vraiment les choses concrètes.

Ah, et ça donne quoi en mouvement? Est-ce que t'as une petite démo? 

[upsilandre]

Y a strictement rien a voir, juste un ecran (composé vite fait avec le tileset de mario) qui scroll en boucle
https://drive.google.com/open?id=0B399kteofpYuT0tnd0lzZmFHcjQ
Ce qui compte c'est d'avoir mis le doigt dans l'engrenage mais je suis pas pressé.

[Alucardark]

Y a strictement rien a voir, juste un ecran (composé vite fait avec le tileset de mario) qui scroll en boucle
https://drive.google.com/open?id=0B399kteofpYuT0tnd0lzZmFHcjQ
Ce qui compte c'est d'avoir mis le doigt dans l'engrenage mais je suis pas pressé.

Ah ben c'est un début très prometteur! Vivement de voir tes évolutions dans le domaine (en tout cas pour quelqu'un qui n'est pas programmeur, tu maitrises plutôt bien).

[upsilandre]

J'ai commencé a toucher les sprites, j'ai donc ajouté l'affichage d'un sprite ou plutot d'un metasprite (8 sprites) en la personne d'Alex kidd bien sure. Je suis loin d'avoir un veritable sprite engine mais au moins ca s'affiche comme il faut.
Puis j'ai commencé a toucher les inputs aussi donc maintenant le scroll n'est plus automatique, faut le faire au pad.
toujours le meme lien
https://drive.google.com/open?id=0B399kteofpYuT0tnd0lzZmFHcjQ

[Alucardark]

Tu évolues vite quand même, la prochaine étape c'est le contrôle du sprite? En tout cas j'ai hâte de voir jusqu'où tu vas aller. ^^

[upsilandre]

Oui j'aimerais bien avoir au moins une demo de controle du sprite d'alex kidd dans un mini décore d'alex kidd (mono screen comme celui la). Quand j'aurais deja ca j'ouvrirais peut etre un topic.

Aujourd'hui j'ai surtout travaillé a faire un vrai moteur d'affichage de sprite. Du coup maintenant j'ai juste a remplir une liste de metasprite avec leurs coordonnées et le moteur affiche ce qu'il y a dans la liste (et donc tous les sprites qui composent les metasprites) jusqu'a tomber sur une ID nulle.
https://drive.google.com/open?id=0B399kteofpYuT0tnd0lzZmFHcjQ

Pour l'instant j'en ai pas vraiment besoin puisque j'ai qu'un seul metasprite a afficher, celui de Alex kidd, mais c'est quand meme mieux de partir sur une bonne base au niveau de l'affichage. (Reste quand meme a gérer le cas d'un dépassement de la capacité d'affichage de sprite a l'ecran mais c'est pas tres urgent.)
Malgres la contraintes des 5 couleurs de mon sprite d'alex kidd (j'y tenais car en 3 couleurs tu peux pas faire un alex kidd correct) j'ai réussit a bien optimisé mes sprites pour eviter les superpositions et aussi eviter un surcout de pattern (mais ca je l'avais deja fait y a longtemps mais je m'etais arreté la).