Okay,
Bon après avoir z'yeuté, je pense avoir une idée d'ou vient ton probleme
la plupart des overlays que tu cites et qui plantent ne sont que partiellement compressés
Je pense que ton souci vient de là tout simplement, il faudrait que tu tentes de les recompresser mais partiellement comme ils le sont à la base
j'avais moi même fait des tests sur ce type d'overlay et ils sopnt très susceptibles, j'avais réussi à les faire fonctionner qu'en les recompressant partiellement comme ils le sont à l'origine
je pense donc que c'est la piste à suivre
Prenons deux overlay en exemple, 1 completement compressé (le 134) et un qui ne l'est que partiellement (le 129)
....................................................................................................................................
Tout d'abord le "134" qui est un fichier overlay compressé conventionnel (on dira ^^) :
On trouve le header de compression à la fin de l'overlay donc qd ce dernier l'est, il est important de noter que ce header ne contient que des données sur la compression et rien d'autre, toutes les données qui concernent le fichier sont stockées dans le y9.bin
En orange : c'est du padding pur la mise en forme du fichier (il peut y avoir 0 à 3 octets)
En rouge : c'est la taille des données compressées dans l'overlay (vu qu'il l'est entièrement, dans ce cas "conventionnel", c'est la taille de l'overlay compressé également)
En vert : c'est la taille du header de compression (bien entendu padding inclus)
En bleu : c'est la différence en octet qu'il y a entre les données compressées de l'overlay, et les mêmes données decompressées
pour determiner si l'overlay est entierement compressé ou non, suffit de regarder sa taille compressée, soit 0x26F0 dans ce cas-ci, et la taille complete du fichier (que l'on peut determiner grâce à l'offset encadré en rose sur le screen) qui est lui même de 0x26F0
on a donc un overlay entierement compressé
On peut même faire le calcul de la taille de l'overlay décompressé en additionnant la taille des données compressées (encadré rouge) + la différence entre les données compressées et décompressées (encadré bleu) soit : 0x26F0 + 0x2610 = 0x4D00
Une fois notre overlay 134 décompressé il fait bien cette taille
On le voit également dans le y9.bin :
En rouge : Taille de l'overlay decompressé
En bleu : taille de l'overlay compressé
En rose et en vert : nombre de l'entrée dans le y9.bin ainsi que le numéro de l'overlay (ces valeurs correspondent toujours donc à savoir laquelle des 2 est quoi exactement ^^)
En orange : l'octet de compression
** Voici la correspondance pour cet octet :
- Code: Tout sélectionner
0x00 : Non compressé, non signé
0x01 : Compressé, non signé
0x02 : Non compressé, signé
0x03 : Compressé et signé.
....................................................................................................................................
Et maintenant l'overlay "129" qui lui n'est que partiellement compressé
dans le header donc, même légende que tout à l'heure
pas de orange : pas de padding dans ce cas-ci
rouge : taille des données compressées dans l'overlay (à noter que pour cette valeur, le header de compression est inclus)
vert : taille du header de compression (+ 0 de padding dans ce cas)
bleu : difference de taille entre les données compressées et les mêmes données non compressées
Maintenant regardons la taille complete de ce fichier (via l'offset encadré en rose), on voit que ce dernier fait 0x2300 octets
regardons maintenant la taille des données compressées (en rouge), nous avons : 0x22C1 octets seulement
Dans ce cas-là, ça signifie tout simplement que notre overlay n'est que partiellement compressé
Il y a donc une partie du fichier qui ne l'est pas
Calculons le nombre d'octets en question : 0x2300 - 0x22C1 = 0x3F
Les 0x3F premiers octets de cet overlay sont donc "non compressés", il ne faut donc pas y toucher
Encadré en rouge : octets non compressés (0x3F voir offset en rose)
Surligné en bleu : les données compressées
Entouré en bleu (bas droite) : taille des données surlignées en bleu (donc celles compressées puisque c'est surligné jusqu'à la fin du fichier dans ce cas-ci)
On peut donc determiner la taille de l'overlay 129 decompressé :
"
Tailles des données compressées (encadrées en rouge dans le header) => 0x22C1" + "
taille de la diff entre les données compressées et non compressées (encadrées en bleu dans le header) => 0x2D80" + "
taille des octets non compressés au debut du fichier => 0x3F" = "
taille du fichier decompressé => 0x5080"
Verifions ça dans le y9.bin :
Meme legende que plus haut :
En rouge : Taille de l'overlay decompressé
En bleu : taille de l'overlay compressé
En rose et en vert : nombre de l'entrée dans le y9.bin ainsi que le numéro de l'overlay (ces valeurs correspondent toujours donc à savoir laquelle des 2 est quoi exactement ^^)
En orange : l'octet de compression
Les données correspondent bien
....................................................................................................................................
Maintenant que tu as une explication du principe, il va donc falloir mettre tout ça en pratique sur tes fichiers lorsque tu viendras à les recompresser
Tout d'abord, verifie si ton fichier est compressé partiellement ou non qd tu trifouilles tes overlays
Dans l'absolu bien que pour certains on peut aisement by-passer la compression, un travail bien propre voudrait qu'on recompresse les fichiers modifiés de préférence (en tout cas moi je le fais sur mes projets
)
dans le cas ou ton fichier est partiellement compressé donc, lors de l'extraction ce n'est aps un probleme, en revanche, en recompression il faut bien prendre soin de retirer la partie qui ne doit pas etre compressé du fichier avant de le recompresser
Par la suite il faudra donc coller la partie compressée après la partie qui doit resté en clair, puis adapter juste deux choses dans le header de compression, c'est tres important.
Il s'agit du padding de mise en forme.
Comme les données checkées sur NDS suivent la regle des 32 bits (4 octets) il faut que le header de compression qui fait 8 octets en tout soit placé sur un offset se terminant par 0x.0, 0x.4, 0x.8 ou 0x.C
C'est pour cette raison qu'on utilise les 0xFF de padding avant ce dernier (de 0 à 3)
Comme ton fichier compressé est ajouté apres des données non compressées, topn header ne sera peut etre aps correctement en place, et donc faudra t'assurer qu'il est bien mis en forme en ajoutant ou retirant du padding si necessaire, en ajustant la taille des données compressées (puisque le header y est inclu ainsui que le padding) et egalement la taille du header
Derniere chose, ton fichier overlays 132 est en theorie que partiellement compressé, c'est étonnant qu'il fonctionne en l'etat donc, le mieux serait de le recompresser partiellement comme il l'est à la base pour eviter tout probleme
Teste ça et dis nous si ça corrige ton souci (mais je pense serieusement que c'est bien de là que vient ton plantage)
je vais continuer a compresser avec dsdcmp pour voir...