Graphismes dans Megaman Zero Collection NDS

[jerome674]

Bonjour à tous,

Je suis depuis plusieurs mois sur le jeu de Megaman Zero Collection où la partie texte est quasiment fini d'être intégrée.

Quelques parties graphiques seraient à modifier, je les visualise difficilement avec Tile Molester et je demande donc un petit coup de pouce pour les visualiser puis pouvoir les modifier.


Edit : voici ce que j'avais vu avec Bahabulle

fichier : 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..

lien vers fichiers : http://www.mediafire.com/?xeuknwf7r9tyap3

Cordialement.

[Lyan53]

Donc okay,

Tu as des archives bin qui contiennent des sous fichiers

dans l'exemple de fichier que tu cites, le premier sous fichier est en clair (graphismes) et les deux autres compressés en lz type 10 ce qui n'est pas insurmontable (le 2 etant la tilemap, le 3 la palette de couleurs)

Après dans ton jeu, on n'est pas dans des types de fichiers dits "standards" pour la NDS (soit des NCLR NCER NCGR NSCR etc...) mais les formats eux le sont

dans tes fichiers de graphismes on retrouve bien les données 4bpp linear reverse ou 8bpp linear d'un NCGR, dans les tilemap on retrouve bien le même type de data brutes qu'un NSCR, et les datas brutes des palettes sont bien en BGR555 comme dans les NCLR

La seule chose qui différencie tes fichiers des standards, c'est les header des fichiers tout bêtement

Tu peux donc moyennant patience (et pour les graphismes il en faut toujours) éditer ce que tu as besoin

Exemple avec ton fichier (bien que tu n'auras pas besoin d'editer celui-ci)


les especes de décalages qu'il peut y avoir sont dus aux tiles recyclées (reutilisées plusieurs fois dans les tilemaps) mais bon ça c'est très classique

Pour les tilemaps, dans un 1er temps tu n'as pas necessairement besoin d'y toucher, mais en revanche pour ouvrir le fichier sous tilemolester il te faudra la partie graphique, puis la données brutes de palette (sans le header donc)

En gros dans tilemolester tu ouvres ton fichier graphique (bon codec, ajustement de la largeur ou de la position, et eventuellement du mode dimensional), puis ensuite tu montes ta palette pour avoir les bonnes couleurs

Voilà des informations sur le type de palette que tu as dans tes fichiers (les deux premieres parties de ce post) : viewtopic.php?p=1517#p1517 (à noter que dans ton cas tu as un header dans tes fichiers à prendre en consideration)

[jerome674]

ok je vois pour ajouter la palette cette aprem

tu es toujours aussi rapide pour afficher une image correcte, démoralisant !!

par contre il s'agit de BGR555 ou BGR55 comme tu as mis dans le post ?

[Lyan53]

C'est une faute de frappe (que j'ai corrigé) , c'est bien 555 d'ailleurs en lisant le lien tu comprendras pourquoi normalement

[jerome674]

j'arrive quasiment à ton résultat, j'ai appliqué une palette de 200octets comme il s'agit d'une image en 8BP linear, j'ai supprimé le header (après avoir décompressé la palette du 3ème fichier)

Par contre j'arrive avec une des couleurs non correcte sur l'image, des points vert apparaissent, ma palette à un problème ou alors que fais je mal ?



fichiers :
http://www.mediafire.com/?bugnkm89obs1tn2

1. qu'est ce qui débloque dans ce que j'ai ? j'ai décompressé le fichier avec l'outils de Loki, je précise comme j'ai déjà eu des problèmes lié aux overlay...
2. le header de la palette sert a quoi ?
3. comment fonctionne une map, comment l'interprete t-on au niveau des coordonnées ?
3.1 des développeurs se servent de la map avec l'image et palette pour avoir des images clean, quel type de "code" peut etre fait, je ne trouve jamais d'exemple là dessus sur internet et personne ne parle jamais de cette partie... je sais que toi Lyan53 tu n'es pas développeur mais je reste ouvert à toute aide en vue de m'aiguiller sur le fonctionnement.
3.2 étrange de compresser map et palette mais pas l'image qui doit etre plus lourde :s ; non ?
4. Si c'est des format standard, en renommant les extensions de fichiers et enlevant les header, puis-je charger avec un quelconque outil mes images?
5. c'est tout !! (pour l'instant)

[BahaBulle]

C'est 512 octets (ou 0x200) je pense pour ta palette.

3. Ben c'est pas compliqué. Tu prends tes tiles dans l'ordre de 0 à n. Dans ta map tu vas avoir des 0, 1, 2... Qui font référence à tes numéros de tiles.

3.1. Ben un code qui lit la map et va rechercher le bon tile suivant les valeurs contenues dans la map.

3.2. Les map doivent se compresser très bien car ce sont des va leurs qui se répètent souvent.

[Lyan53]

1. qu'est ce qui débloque dans ce que j'ai ? j'ai décompressé le fichier avec l'outil de Loki, je précise comme j'ai déjà eu des problèmes lié aux overlay...

Tu n'es pas calé sur le bon offset tout simplement, ton header ne fait pas 0x1B octets mais 0x1C octets, tu as donc un petit décalage sur ton résultat final rapport aux bonnes couleurs

2. le header de la palette sert a quoi ?

Comme tout header il stocke des informations (du genre ID, taille, offset, nombre de palettes, etc...) au romhackeur d'en percer les mystères en observant/analysant le fichier, après les header sont changeants selon les types de fichier, mais les datas brutes sont assez souvent dans le même format suivant ce que supporte le support d'origine

Sur NDS on a quasi systématiquement des palettes en BGR555, alors que sur PSP ce sera plus souvent de RGBA8888

3. comment fonctionne une map, comment l'interprete t-on au niveau des coordonnées ?

La tilemap découpe ton image à l'ecran en tiles

En gros imagine que ton graphisme fasse tout l'écran de la NDS (enfin juste un des deux, celui du haut ou du bas peu importe) dont la résolution est 256x192 pixels

Si tu divises cet écran en tiles de 8x8 pixels tu vas donc obtenir 32 tiles sur la largeur et 24 sur la hauteur, soit 768 tiles en tout



C'est exactement ce que fait une tilemap en gros, elle stocke dans un bloc de données représentant l'écran (le tout bien entendu sous forme de valeurs hexadécimales), des informations sur :
- quelle tile du fichier sera à telle position
- est-ce que l'image sera inversée horizontalement/verticalement (voir les 2) ou pas
- quelle palette sera utilisée pour cette tile (dans le cas ou il y'en aurait plusieurs)

3.1 des développeurs se servent de la map avec l'image et palette pour avoir des images clean, quel type de "code" peut etre fait, je ne trouve jamais d'exemple là dessus sur internet et personne ne parle jamais de cette partie... je sais que toi Lyan53 tu n'es pas développeur mais je reste ouvert à toute aide en vue de m'aiguiller sur le fonctionnement.

Ton fichier contenant les graphismes est lui même découpé en tiles



Dans ce dernier, chaque tile possède son propre numéro de tile (la premiere etant la tile 0x00, la suivante la tile 0x01, suivi de 0x02, etc...)


Ta palette de couleur, c'est pareil, dans le cas ou tu as plusieurs palettes de couleurs à la suite dans ton fichier, chacune possède son propre numéro de palette (0x00, 0x01, 0x02, etc...)

A partir de là, ta tilemap qui elle représente ton écran va attribuer à chaque tile de l'ecran, le numéro de tile du fichier qu'elle doit afficher, éventuellement un mode miroir horizontal ou vertical (flip x/y), et le numéro de la palette qui lui est attribué


Dans ta tilemap, chaque tile à l'écran sera stockée sur 2 octets (LE) qu'il faut décortiquer en binaire de la manière suivante :

PPPPYXTTTTTTTTTT
P = numéro de la palette
Y = mirroir vertical
X = mirror horizontal
T = numéro de la tile

Dans ta tilemap, toutes les tiles de l'ecran sont affichées à la suite dans le sens de lecture (donc de gauche à droite puis à la ligne et on recommence, etc...)

Pour comparer ça de maniere imagée, tu as donc une image sous forme de puzzle (ton ecran) et tu as un fichier dans lequel tu as les pieces du puzzle (les graphs), la tilemap met en place tes pieces de puzzle (selon leur n° de tile et palette) aux bons emplacements pour remettre de l'ordre dans tout ça

3.2 étrange de compresser map et palette mais pas l'image qui doit etre plus lourde :s ; non ?

Bah à vrai dire faudraiit poser la question aux devs
Dans FFG on avait des tonnes de fichiers compressés ou tordus à remettre en ordre comme ci ils voulaient conserver le max de place possible, alors qu'en parallèle on avait une chiée de fichiers jap en doublons qui ne servaient strictement à rien dans les versions US et EUR, va comprendre donc

4. Si c'est des format standard, en renommant les extensions de fichiers et enlevant les header, puis-je charger avec un quelconque outil mes images?

Ne pas confondre les formats standards du support avec des formats basiques de données

Les formats standards qu'on retrouve dans de nombreux jeux NDS possèdent leur propres header et donc à moins de reconstruire ces header, tu ne pourras pas faire passer tes fichiers pour les standards NDS

Les données qu'ils contiennent eux en revanche sont dans des formats basiques (qui sont eux mêmes utilisés dans les fichiers standards ainsi que dans de nombreux autres types)



Et sinon tu disais plus haut qu'il n'existe pas de doc à ce sujet, mais en fait si, il en existe, faut juste les trouver

Voilà un lien pour les standards NDS, certaines choses sont éventuellement discutables (parce qu'il peut y avoir quelques variantes) mais dans l'ensemble c'est un bon document qui m'a pas mal aidé à comprendre un peu tout ce boxon à une époque : http://www.romhacking.net/documents/%5B ... ormats.htm

En dehors des header, tu retrouves donc les infos sur les données basiques dans ce dernier

[jerome674]

bonjour,

je ne suis pas parvenu a avoir une image claire comme toi Lyan :s (j'ai toujours du vert)

1. quels sont les octets que tu enlèves de ta palette ?
il commence bien par :
00 e0 03 00 00 01 04 00 0c 02 04 03 00 22 0c 14

et fini par :
bd 77 bd 77 9f 7f bd 7b bf 7b ff 63 de 7f ff 7f


2. Voici une seconde image avec le mot juste WARNING de marqué dessus, mais idem impossible à lire, je joins la tile, tilemap et palette, un des fichiers est à 0 octets.
http://www.mediafire.com/?57m1m5qhy2czpll

parviens tu a afficher quelque chose ?

C'est 512 octets (ou 0x200) je pense pour ta palette.

3. Ben c'est pas compliqué. Tu prends tes tiles dans l'ordre de 0 à n. Dans ta map tu vas avoir des 0, 1, 2... Qui font référence à tes numéros de tiles.

3.1. Ben un code qui lit la map et va rechercher le bon tile suivant les valeurs contenues dans la map.

3. dans ce fichier la map commence ou et s'arrête ou ?
4. as tu un exemple de code permettant de lire la map et va chercher les bonnes tiles ?
5. combien d'octets sont nécessaires pour aller chercher les tiles ? 1, 2 , + ?

merci d'avance

[Lyan53]

je ne suis pas parvenu a avoir une image claire comme toi Lyan :s (j'ai toujours du vert)

1. quels sont les octets que tu enlèves de ta palette ?
il commence bien par :
00 e0 03 00 00 01 04 00 0c 02 04 03 00 22 0c 14

et fini par :
bd 77 bd 77 9f 7f bd 7b bf 7b ff 63 de 7f ff 7f

C'est parce que tu n'es toujours pas calé sur le bon offset, tu prends un octet de trop dans ta palette ce qui fausse tout

Voilà la palette brute (sans header) : http://www.sendspace.com/file/6quxh8





Sur le screenshot du fichier avec header, j'ai surligné le bloc de données brutes de la palette
La flèche représente la taille hex du bloc surligné soit 0x200 octets = 512 octets comme te l'a indiqué Baha, c'est la taille d'une palette pour une image en 8 bit par pixel = soit 8bpp = soit 256 couleurs (puisqu'on a 2 octets attribués pour chaque couleur)

Si tu ne sais pas ou commence la palette après le header, voit directement en remontant à partir de la fin du fichier jusqu'à avoir le nombre d'octets correspondant (dans le cas ici présent c'est 0x200 pour la taille de ta palette) puisque ce dernier ne semble pas avoir d'autres données après les données brutes

2. Voici une seconde image avec le mot juste WARNING de marqué dessus, mais idem impossible à lire, je joins la tile, tilemap et palette, un des fichiers est à 0 octets.
http://www.mediafire.com/?57m1m5qhy2czpll

parviens tu a afficher quelque chose ?

Voir quelque chose oui, mais pas forcément en clair, ce fichier doit être mappé quelque part ce qui pourrait donc lui donner tout son sens puisqu'il ne s'agit là que d'un amas de tiles en vrac a priori
Mais en revanche, de 1, il n'y a pas de compression, et de 2, la tilemap n'est pas dans cette archive (0 octet), elle se situe probablement ailleurs (par contre "où ?", la question reste entière)...

Rien ne laisse penser pour le moment que c'est forcément le mot "warning" qui y est ecrit, mais ça peut eventuellement etre le cas une fois ces tiles mappées comme il faut, faudrait griffonner tout ça et voir si tu sais ou se trouve ton "warning" dont tu parles à l'ecran, si ses tiles viennent bien de ce fichier
Si c'est bien le cas alors le fait de taper dedans (en gribouillant sur les tiles ou en les modifiant) se verra à l'ecran

3. dans ce fichier la map commence ou et s'arrête ou ?

Je vais plutôt reprendre l'autre fichier comme exemple, soit : http://www.sendspace.com/file/fdk88r



Petit rappel de ce que je disais dans mon post précédent :

La tilemap découpe ton image à l'ecran en tiles

En gros imagine que ton graphisme fasse tout l'écran de la NDS (enfin juste un des deux, celui du haut ou du bas peu importe) dont la résolution est 256x192 pixels

Si tu divises cet écran en tiles de 8x8 pixels tu vas donc obtenir 32 tiles sur la largeur et 24 sur la hauteur, soit 768 tiles en tout

32 tiles de large = 0x20 tiles de large
24 tiles de haut = 0x18 tiles de haut
(note que l'on retrouve ces valeurs dans le header du fichier)

768 tiles en tout = 0x300 tiles en tout

Sachant qu'on utilise dans notre tilemap 2 octets par tile, ça nous donne donc un bloc de données de
0x300 tiles * 2 octets = 0x600

0x600 sera donc la taille qu'occupera la tilemap pour mapper tout l'ecran

Là encore, en utilisant l'astuce de partir de la fin du fichier en remontant vers le debut, il suffit de surligner donc les 0x600 derniers octets pour localiser le debut des données brutes (donc sans le header) de ta tilemap et c'est ce que j'ai fait sur le screen ci-dessus

5. combien d'octets sont nécessaires pour aller chercher les tiles ? 1, 2 , + ?

Gné ??
Pourquoi veux-tu connaitre le nombre d'octets ?? oO
Une tile est "graphique", c'est à l'image qu'il faut se referer pour comprendre comment ça fonctionne dans un premier temps (pas besoin de te prendre la tete avec les octets)

Sinon après pour le nombre d'octets, tout dependra de la resolution... 8bpp ou 4bpp n'occuperont pas la même taille, et pour cause ils portent bien leurs noms de "bits par pixel", sachant que tes tiles font 8x8 pixels, à toi d'en déduire le reste
Mais méfie toi des modes d'affichages qui peuvent définir le classement des octets, et ces derniers, selon le cas ne se suivent pas toujours (mais bon de toute façon coté graphismes à moins que tu aies l'intention de programmer un truc auquel cas il faudra que tu etudies les divers formats d'images existant comme le BMP ou le PNG, tu n'auras pas besoin d'aller trifouiller dans les octets manuellement)

4. as tu un exemple de code permettant de lire la map et va chercher les bonnes tiles ?

Un exemple ?? quel exemple ?

Ta tilemap est elle même ton exemple
tu prends ta toute premiere valeur brute dedans, soit 0x0000, tu la decortiques en binaire selon le schéma que je t'ai donné plus haut soit :

PPPPYXTTTTTTTTTT
P = numéro de la palette
Y = mirroir vertical
X = mirror horizontal
T = numéro de la tile

Et tu obtiens les données de ta 1ere tile à l'écran

Ensuite tu fais la même chose avec les suivantes et au fur et à mesure ton image sera reconstituée

Note que je me suis planté juste pour ce screenshot

dans l'ancien je n'avais pas affiché la tile 0x00 du coup j'ai décalé tout de +1 rapport aux vraies valeurs, au temps pour moi

La tile 0x00 dans ce cas est la couleur de transparence ou la couleur de fond (selon le cas), la j'en deduis donc en regardant dans la tilemap que les 70 (0x8C / 2 = 0x46 =70) premiere tiles de ton images sont la couleur de fond

Si on pousse un peu plus loin on a donc deux lignes de 32 tiles chacune en couleur de fond en haut de l'ecran et l'image commence sur la 3eme ligne à la 7eme tile
puisque 32 + 32 = 64
et 70 - 64 = 6
donc 6 tiles couleur de fond sur la 3eme ligne suivi de la premiere tile d'image en position 7

Mais sinon c'est simple, observe les données de ta tilemap et decortique-les y'a que comme ça que tu percuteras, de préference essaye de faire un screenshot in-game de l'image pour comparer


EDIT :
J'ai finalement pris le temps de faire une image plus explicite sur le début de ta map


En esperant que tu finisses par percuter parce que pour le reste je suis à cours d'explication là si tu ne piges pas ce qui s'y passe ^^

[jerome674]

je reprends point par point ce sera plus simple

1. Pour la première partie c'est bon au niveau de palette, j'ai trouvé ce qu'il s'est passé, il me manquait un octet "40" dans le début que j'ai du supprimer par erreur, j'avais bien pris les 200 octets à la base mais avec un octet de moins sur le total, c'est pour ca que ma palette commençait par un 0.

->donc première image parfaite, no problem.


2. après chargement de la palette, la couleur orangée correspond bien au mot warning qui apparait à l'arrivée d'un boss.
j'ai trouvé les tilemap sur les fichiers "warning_z3.bin-2.bin" et "warning_z4.bin-2.bin"
http://www.mediafire.com/?8mps1ws28088588

Les fichiers sont identiques ou quasiment au niveau de la palette (en 0x0c une valeur est à 01 et 00 pour un autre)
Les map sont identiques sur les 2 fichiers "warning_z3.bin-2.bin" et "warning_z4.bin-2.bin"
Le jeu doit donc utiliser un seul des fichiers ou alors la tilemap contenu dans le fichier warning_z3.bin ou warning_z4.bin

ca reste illisible malgré tout.

3. 600 octets pour la tilemap, c'est ok, je posais la question car je ne sais quelle place prend exactement le header sur ce fichier, mais là oui en effet en partant de la fin aussi ca va mieux.

4. question plutôt pour Bahabulle en effet; as tu un exemple de code permettant de lire la map et va chercher les bonnes tiles ?
Par code, j'entends développement en un quelconque langage, je ne suis pas spécialement développeur mais expliquer ce que l'on veut à un développeur sans trop savoir comment ca tourne derrière ce n'est pas évident, d'où demande d'un peu de code LUA ou autre ...

5. ""combien d'octets sont nécessaires pour aller chercher les tiles ? 1, 2 , + ?""
Justement Lyan, ma question est dans le but de développer ou plus plausible faire développer afin de remanier les images plus aisément.

Par rapport à tes explications sur cette dernière image j'ai fait une map sur papier plus longue et je vois nettement qu'il s'agit d'une image centrée entourée de noir, ça doit être une image bonus à débloquer ou un truc comme ça mais je vois bien comment fonctionne la tilemap, ne t'inquiète pas

Donc par rapport à ma question initiale, une tilemap désigne une tile sur 2 octets.
Une tile fait 64 octets d'après mes tests (j'ai remplacé les 64 premiers octets par la même valeur sur l'image et j'obtiens bien une tile entièrement de la même couleur) -> c'est bien ça ?

Pour créer une image bmp, la tilemap va chercher les tiles ainsi :
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
....
00 00 00 00 00 00 00 00 00 00 00 00 01 00 02 00
03 00 04 00 05 00 06 00 07 00 07 00 08 00 09 00
0a 00 0b 00 0c 00 0d 00 0e 00 0f 00 10 00 11 00
12 00 13 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 14 00 15 00

->le 00 correspond à la première tile du fichier image ? donc les 64 premiers octets sans le header ou ce n'est pas ça ?
->le 01 à la 2ème tile ? donc de 65 au 128ème octets ?

Je sais que je ponds toujours des pavés, désolé hihi !!