extraction de texte dans overlay Megaman Zero Collection NDS

[Lyan53]

5. padding ok
modifier taille du header->ajuster suivant le padding ajouté ou non ?

Selon le cas tu devras soit ajouter ou retirer 1, 2 ou 3 octets de padding, ou alors ne pas y toucher si la mise en forme est correcte dès le départ

C'est tres simple, ton header de base fait 0x8 octets, tu dois placer ce dernier en suivant la règle des 32 bits expliquée plus haut
Tu auras donc au final une fois la mise en forme retapée, 0, 1, 2 ou 3 octets 0xFF de padding juste avant des 8 octets du header
La taille du header prend en compte ces octets de padding => donc de 0x08 octets (pour 0 octet de padding) à 0x0B (pour 3 octets de padding)

Suffit juste de voir combien fait ton header mis en forme avec le padding (donc en gros les 0xFF + les 8 octets du header)

modifier taille des données compressées->la taille change ou je garde les infos créées par la compression ?

Là encore à voir selon le cas, suivant si tu auras ajouté ou retiré des octets de padding, il faut adapter cette taille en consequence puisqu'elle inclus le header

Mais pour faire simple, regarde la taille que ton fichier general fait une fois celui-ci mis en forme, et retire à cette taille, les 0x3F qui ne sont pas compressés

6. pour connaitre la taille totale décompressée, c'est bien l'original -> sans le header ?
et avec les 0x3F du début a ajouter ?

Sans le header, c'est la copie ^^

Au depart tu as ton fichier d'origine non modifié qui est compressé, une fois decompressé avec crystaltile, tu obtiens le fichier original decompressé

C'est sur cet original decompressé que tu vas faire tes modifs pour la traduction (ce qui va sans doute changer la taille de ce dernier (elle sera sans doute plus grande)

Tu as donc maintenant que tu as traduit ton fichier, le fichier modifié "d'origine" non compressé (dans lequel tu as les 0x3F octets)

C'est sur ce fichier là qu'il faut voir pour la taille (avant de retirer les 0x3F) puisque cette nouvelle taille devra à la fois etre reportée dans le y9.bin, mais il faut aussi l'utiliser pour calculer le différentiel des données compressées/décompressées par la suite

Lorsque tu vas calculer la taille du différentiel entre les données compressées et les données non compressées que tu auras besoin d'ajuster dans le header de compression, il faudra donc dans un 1er temps soustraire à la taille générale de ce fichier les 0x3F "qui ne sont pas pris en compte" dans le header de compression

Ensuite soustrait la taille de tes données compressées (une fois remise en forme bien entendu) pour obtenir la difference de taille entre les données compressées et les données décompressées

C'est cette valeur qu'il faudra ajuster dans le header de compression

Au final avec le chemin inverse, ça donne : donnees compressées + differentiel + 0x3F = taille du fichier traduit decompressé

8. oula, je teste et te redis ca :s

Là rien de plus simple, une fois le differentiel données compressées/décompressées obtenu, faut juste le modifier (enfin plus precisement l'ajuster) dans ton header de compression

[jerome674]

bonsoir !

bon après un bon moment de test, le jeu bugg toujours.

Voici ce que j'ai fait :
lien des fichiers

1. décompression de l'overlay original avec CrystalTile
fichier : 1. overlay_0129_original.bin

2. modification par le francais avec les bons pointeurs
fichier : 2. overlay_0129_fr_non_compress.bin

3. découpage de la partie a compresser (suppression des 0x3F premiers octets)
fichier : 3. overlay_0129_fr_a_compress_sans_3F.bin

4. fichier compressé avec DSDecmp
fichier : 4. overlay_0129_fr_compress_sans_3F_premiers_octets.bin

5. fichier compressé + 3F premiers octets
fichier : 5. overlay_0129_fr_compress_avec_3F_premiers_octets

dans ce 5ème fichier j'ai modifié le padding, suppression de FF FF FF
ce qui donne :
29 36 00 31 2d 32 40 5e 5e 5e ff 00 f8 22 00 08
b8 2d 00 00

On est donc bien sur 0x.4 octets
Je l'ai aligné sur le fichier général, aurait-il mieux value que je laisse par défaut juste sur la partie compressée ?

ensuite modification du fichier Y9.bin :
81 00 00 00 00 a1 15 02 ef 50 00 00 00 00 00 00
b8 ba 15 02 bc ba 15 02 81 00 00 00 34 23 00 01

50 EF = 3F + 22F8 + 2DB8
23 34 = fin du fichier semi compressé

Est-ce que ca semble correct ou ai-je loupé un truc ?

merci d'avance

[Lyan53]

Pour commencer, ton fichier FR non compressé n'est pas conforme, il doit respecter la regle des 32 bits, donc il faut lui ajouter du padding (1 octet dans ce cas-ci)

Il fait : 0x50EF
L'offset supérieur se terminant par 0x.0, 0x.4, 0x.8 ou 0x.C est 0x50F0 (donc ajout d'un octet 0 à la fin du fichier)

ensuite modification du fichier Y9.bin :
81 00 00 00 00 a1 15 02 ef 50 00 00 00 00 00 00
b8 ba 15 02 bc ba 15 02 81 00 00 00 34 23 00 01

Pour le fichier y9.bin, lui aussi respecte la règle des 32 bits, tu ne peux pas noter une valeur qui ne la respecte pas dedans mais en théorie si tu as bien paddé tes fichiers (compressés ou non) comme il faut, alors tu tomberas juste

dans ce 5ème fichier j'ai modifié le padding, suppression de FF FF FF
ce qui donne :
29 36 00 31 2d 32 40 5e 5e 5e ff 00 f8 22 00 08
b8 2d 00 00

Ici tu te trompes, même en admettant qu'avant la compression tu avais paddé ton fichier, tu n'as pas recalculé comme il faut les valeurs de taille (le différentiel entre le fichier compressé et le non compressé, ainsi que la taille de la partie compressé du fichier)

Tu dois prendre "le nouveau padding en compte", mais en revanche il ne faut pas prendre en compte les 0x3F non compressés au début du fichier lorsque tu recalcules (tu ne l'as pas fait mais bon je le rappelle tout de même)

Là sur ton fichier 5 tu as laissé les valeurs d'origine mais comme tu as retouché le padding, ces valeurs ont été modifiées puisqu'il est inclus dans les données du header de compression, sa taille si elle change est donc à prendre en consideration sur le différentiel et la taille des données compressées

En ce qui concerne la taille du header de compression, ça va tu l'as noté correctement


Essaye avec le fichier en pièce jointe

Dedans j'ai :

- Repris ton fichier FR que j'ai paddé correctement (+1 octet 0x00 pour tomber sur une norme 32 bits)

- Supprimé les 0x3F premiers octets et compressé le fichier avec desdcmp

- Récupéré les 0x3F premiers octets (d'origine) dans un nouveau fichier

- Collé le fichier compressé avec desdcmp apres les 0x3F du nouveau fichier

- Paddé correctement le fichier pour le mettre à la norme 32 bits

- Adapté la taille du header de compression en tablant avec mon nouveau padding

- Adapté la taille des données compressées (qui contiennent le padding ainsi que le header de compression donc en gros ça revient à prendre la taille totale du fichier actuel auquel tu soustrais les 0x3F non compressés)

- Adapté le différentiel compression/decompression (le cacul se fait par : "taille du fichier FR d'origine" - "les 0x3F" - "taille des données compressées une fois le padding adapté" = "différentiel de compression")




Le fichier est prêt normalement, il reste juste à adapter le y9.bin avec les nouvelles tailles du fichier FR non compressé, et du fichier FR partiellement compressé



Et normalement reste plus qu'à tester (en admettant que je ne me sois pas planté car je fatigue là ^^)

[jerome674]

ca marche du tonnerrrrrrrre !!!

j'ai testé ton overlay modifié et tu as en effet trouvé ce qui merdait sur le jeu.

je vais maintenant lire le contenu complet de ton post afin de savoir ce que j'ai merdé...
( j'avoue ne pas avoir été patient pour lire mais tester d'abord )

MERCI encore Lyan

EDIT : je suis parvenu a refaire ton fichier mais j'avoue avoir cherché un moment pour ou ajouter un 00...
Pour confirmation :
si j'ajoute 1 octet FF au padding sur le fichier compressé, j'ajoute 1 pour la taille du fichier compressé soit :
22f8->22f9
et je soustrais 1 sur la différence entre les données compressées et les memes données décompressées soit :
2db9->2db8

[Lyan53]

Ah oui le padding était à ajouter à la fin, c'est vrai que je ne l'ai pas précisé -_-"

Sinon c'est cool si ça fonctionne

Pour confirmation :
si j'ajoute 1 octet FF au padding sur le fichier compressé, j'ajoute 1 pour la taille du fichier compressé soit :
22f8->22f9
et je soustrais 1 sur la différence entre les données compressées et les memes données décompressées soit :
2db9->2db8

Oui je sais bien
C'est d'ailleurs logique, mais mon calcul est surtout là pour t'expliquer plus en détail comment ça fonctionne pour cette valeur avec laquelle tu semblais avoir du mal

[jerome674]

j'ai regardé par curiosité, j'ai 35 overlay dont je dois retravailler de cette meme maniere...

15 sont compressés normalement

certains dont j'ai des doutes a 1/2 octets pret, que penses-tu de l'overlay_0146 par exemple ? compressé totalement ou pas ?

Je suis étonné de ne pas avoir eu plus de bugs finalement car plusieurs overlay n'ont pas bien été refait au final.

bon je me lance sur la correction de ces qques overlay en prenant ton modèle, je vais voir ce que ça me donne...

[Lyan53]

Le 146, je dirais partiellement compressé d'après le header (même si 3 octets ne sont pas compressé dedans, il ne faut pas qu'ils le soient donc même chose que pour le 129 )


Sinon pour les bugs, parfois ça passe parfois non, le mieux pour ne pas en avoir est de remettre toujours les choses au propre, car certains bugs peuvent survenir plus tard en modifiant autre chose n'ayant pas forcément rapport pis on se demande pourquoi ça merde parce que tout semble correct à ce niveau là

Bref y'a une structure, le mieux est de toujours la prendre en compte et de la restaurer pour éviter au max les soucis

[jerome674]

Bon et bien j'ai fini, j'ai chargé 6 sauvegarde que j'avais et pas un seul bugg, donc plutot bon signe, une partie du jeu va etre tester, je continue le reste et atttendant mais au moins tu m'as donné le bon truc pour refaire ces overlays Lyan53 !!

merci

[Lyan53]

De rien

[jerome674]

0 bug, tout est parfait, reste plus qu'à finir de checker qques phrases et réinserrer le tout.

quelques jours de boulot encore.

la seconde partie qu'il me restera à voir, celle que je déteste, la partie graphisme...

je posterai tout a l'heure ce que j'ai constaté, voir si c'est correct ou si je suis à coté...de la plaque.

Edit : voici ce que j'avais vu avec Bahabulle

chr_card01_zclct.bin
03000000 : nombre de fichiers
14000000 : adresse du fichier 1
28630080 : adresse du fichier 2 (le 80 indique qu'il est compressé)
10670080 : adresse du fichier 3 (le 80 indique qu'il est compressé)
68690000 : fin du fichier
14000000 : début des données
00630000 : taille des données

après comment avancer et extraire des images correcte afin de les modifier..