J'ai donc z'yeuté dans ta rom
Certains .bin sont bien des archives comme je le pensais et qui plus est dans ces archives certains sous-fichiers sont compressés
Voilà une petite explication de comment ça fonctionne (c'est pas trop dur)
Il s'agit du fichier "title_local.bin"

Donc pour commencer , on voit qu'il y a 0x8 octets dédié pour chaque entrée (sous-fichier) contenu(e) dans l'archive
Les valeurs sont stockées en little-endian :
- Les 4 premiers octets (en rouge) sont l'offset ou commence le sous fichier
- Les 4 suivants (en bleu) sont la taille , mais pas seulement , il y a un système utilisé qui indique si le fichier est oui ou non compressé
Décortiquons ça :
Si on prend la 1ère et la 2nde valeur encadrées en bleu donc on a
1- 0x00020000 > en litlle endian > 0x00000200 (ou 0x200)
2- 0xC0410080 > en little endian > 0x8000410C
Bien qu'à vue de pif ce ne soit pas forcément nécessaire de faire ça pour ces entrées on va les décortiquer tout de même en binaire pour expliquer comment fonctionne (enfin je pense) le système qui indique si il y a ou non compression sur un sous-fichier
1-
00000000 00000000 00000010 000000002-
10000000 00000000 01000001 00001100On a donc 32 bits pour nos 4 octets par entrée .
Sur ces 32 bits :
- le 1er bit le plus haut (en rouge) est dédié à la compression , si sa valeur est "1" la compression est active , si sa valeur est "0" il n'y a pas de compression (à l'oeil nu si le fichier n'est pas trop gros on verra donc 0x80 sur cette valeur mais mieux vaut faire néanmoins attention car si le fichier est assez grand en taille ça peut prêter à confusion)
- les 31 bits les plus bas (en jaune) sont la taille du fichier mais attention , la taille du fichier une fois celui-ci décompressé(soit 0x410C) puisque le fichier n'est pas gros on aurait pu le savoir depuis le début mais valait mieux expliquer tout de même en détail au cas z'ou tu tomberais sur un plus gros fichier
- Pour notre 1er fichier donc on peu en déduire qu'il se situe à l'offset 0x30 , qu'il pèse 0x200 octets et qu'il n'est pas compressé
- Pour notre 2nd fichier , celui-ci est situé à l'offset 0x230, il pèse 0x41C0 octets (mais attention lorsqu'il est décompressé) et il est compressé (pour connaitre sa taille exacte en compressé , c'est simple il suffit de prendre l'adresse du fichier suivant et de soustraire à l'adresse du pointeur en question) l'entrée suivant commence là ou fini celui-ci en somme .
Pour ce qui est du tout dernier pointeur de la liste (en vert) il marque à la fois la taille complète du fichier complet et bien entendu l'offset ou fini le dernier sous fichier
Pour en revenir à la 1ère entrée , l'adresse 0x30 indique que le début du 1er sous-fichier ce qui implique donc qu'il s'agit également de la taille du header contenant l'index (encadré en orange)
Dans l'encadré rose , on a donc le 1er fichier (sur 0x200 octets puisque non compressé) ; note : il s'agit de la palette de couleur pour info
Et pour ce qui est de la valeur entouré en violet , c'est en fait le 1er octet du second fichier , celui qui m'a permis de reconnaitre le format de compression (classique utilisé sur NDS) , c'est du lzss type 11
Il te suffit juste d'utiliser le codec LZSS NDS codé par Loki que tu trouveras ici pour pouvoir décompresser/recompresser ce type de fichier :
viewtopic.php?f=4&t=35C'est pas trop compliqué tout ça tu devrais t'en sortir si tu es débrouillard , les indications données précédemment sont toujours valables au passage , et avec tilemolester tu devrais pouvoir gérer le format d'image mais bon t'attends pas à avoir des images toujours dans l'ordre , c'est un peu du puzzle tout de même
Sinon pour la font , j'ai pu la visualiser et elle ne devrait pas être trop complexe à éditer , faut voir après si tu peux facilement y ajouter des entrées (ça c'est pas sûr) , je te laisse essayer un peu tout ça pis si tu as besoin d'un coup de main n'hésite pas a repasser dans le coin

Bon courage
