Graphismes dans Megaman Zero Collection NDS

[Lyan53]

->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 ?

Sauf que comme dit plus haut, suivant le mode, les données ne sont pas nécessairement classées pareil dans le fichier des graphs

Dans ton exemple, c'est sans doute ça (j'ai pas vérif) mais faut faire gaffe tout de même

Voilà deux exemples d'une même image mais dans deux modes différents (img en 4bpp)

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

La tilemap peut etre eventuellement recyclée d'un autre fichier, ça arrive souvent, à voir laquelle est la bonne maintenant (celle qui est utilisée)

Puis si elle est similaire, elle traite certainement le même graphisme, faut éventuellement reconstruire l'image pour voir ce qu'il en est mais pour la modif tu as plusieurs options

Soit reprendre la méthode qu'ils ont utilisé et qui consiste à reconstruire l'image en tile par tile (donc recréer une image et une tilemap en utilisant le même principe), soit tu peux faire ton image d'un seul bloc (elle occupera sans doute plus de place) et créer une tilemap adaptée en conséquence

Dans tous les cas il te faudra utiliser les propriétés de ta tilemap si tu veux pouvoir la retoucher

ca reste illisible malgré tout.

Pour que ce soit lisible, faut reconstruire l'image en la mappant (un peu comme pour l'exemple que je t'ai montré dans mon post précédent), c'est un jeu de patience si tu dois le faire manuellement mais ça reste réalisable, sinon faut programmer des outils adaptés aux formats


Et sinon pour c qui est de Baha, il est en vacances, il passe vite fait de temps à autres, mais bon il ne sera pas pleinement dispo avant fin août (peut etre même + vu que son pc est en rade en prime)

[BahaBulle]

Je n'ai pas de code sous la main et je ne vois pas en quoi ça va t'aider.
Si tu connais quelqu'un qui peut te code un outil pour reconstruire les images, il devrait pouvoir se débrouiller à partir du moment où il comprend comment ça fonctionne.

Tu as des tiles et une map qui tee donne l'ordre d'affichage des tiles, c'est pas compliqué.

Tu lis ta map dans l'ordre, 2 octets par 2 octets.
Tu découpe ces 2 octets pour récupérer les différentes infos (numéro de tile, flip...)
Avec le numéro de tile, tu vas chercher le bon tile :
0 (numéro) x 64 (taille d'un tile) = 0 (adresse du tile)
Après, faut voir si y'a des flip à faire, mais voilà, pas compliqué.

[jerome674]

Voilà deux exemples d'une même image mais dans deux modes différents (img en 4bpp)

comment ça 2 modes différents ?
en effet la tilemap n'est pas "croissante".

le bout d'algorythme de Baha est pas mal, j'essaie de plancher dessus (sur le procédé) puis reviendrait après avoir un peu cogité sur la chose..

Les fichiers warning_z3.bin-2.bin et warning_z4.bin-2.bin ont une tilemap qui m'étonne, elles sont assez plus grosse, 0x800 octets contre 600 pour la première image qu'on a vu dans le 1er post.
Beaucoup de 0 se trouvent en fin du fichier, seraient-ils a ne pas prendre en compte ?

[BahaBulle]

le bout d'algorythme de Baha est pas mal, j'essaie de plancher dessus (sur le procédé) puis reviendrait après avoir un peu cogité sur la chose..

Y'a pas à grand chose à cogiter dans ce que j'ai écrit, c'est très simple.

Et maintenant que j'y pense, tu dois avoir une fonction qui fait tout ça dans les sources du megaman que je t'avais fait. Elle doit être dans le fichier graphismes.lua et avoir background dans le nom où un truc comme ça.

[jerome674]

Bonjour Baha,

en fait tu ne m'as pas donné toutes les sources que tu avais tant que ce n'était pas complétement fonctionnel, et comme ça n'a jamais été fini avec les images, je n'ai jamais eu les derniers fichiers du code.

voici ce que j'ai :

archive_main.lua
Baha-Functions.lua
Baha-Table.lua
NDS-MegamanStarforce3-Data.lua
NDS-MegamanStarforce3-Functions.lua
NDS-MegamanStarforce3-Language.lua

Pas de graphismes.lua ...
Je suis toujours partant pour finir l'autre projet aussi :p !!

Envoi moi par mail si tu le peux les sources qui me manquent...

merci d'avance.

[jerome674]

c'est bon je parviens a extraire les images en 8bpp après avoir fait coder quelques lignes à un dév.
question annexe, une fois une image bien formée, pour gérer une palette avec l'image sans passer par Tile molester, quel lien se fait entre l'image générée avec tile+map et la palette ?
Les 4 premiers bits de la tilemap correspondent au numéro de la map, ok pour ça mais plus précisément, qu'est ce qui fait qu'on aura un blanc d'un bleu au niveau de l'image par rapport à la palette ?
Les bmp en 256 couleurs intègrent une palette aussi, c'est des "palettes bmp" standard au bmp ou on peut intégrer une "palette de la rom" ?

Les fichiers warning_z3.bin-2.bin et warning_z4.bin-2.bin ont une tilemap qui m'étonne, elles sont assez plus grosse, 0x800 octets contre 600 pour la première image qu'on a vu dans le 1er post.
Beaucoup de 0 se trouvent en fin du fichier, seraient-ils a ne pas prendre en compte ?

Idée sur cette question ?

merci

[Lyan53]

comment ça 2 modes différents ?

là c'est du mode 1 dimensional et 2 dimensional, mais il peut y avoir pleins d'autres bricoles comme les codecs (planar, linear), les images interlacées, etc... bref pour ça faut etudier un peu les formats d'images avancés qu'on utilise couramment sur le net, doit bien y avoir des informations là-dessus pour les codeurs (genre les divers modes de png, de bmp, etc...)

Les fichiers warning_z3.bin-2.bin et warning_z4.bin-2.bin ont une tilemap qui m'étonne, elles sont assez plus grosse, 0x800 octets contre 600 pour la première image qu'on a vu dans le 1er post.
Beaucoup de 0 se trouvent en fin du fichier, seraient-ils a ne pas prendre en compte ?

Idée sur cette question ?

merci

Les images débordent parfois de l'écran tout simplement

qu'est ce qui fait qu'on aura un blanc d'un bleu au niveau de l'image par rapport à la palette ?

l'ordre des couleurs dans la palette rapport aux valeurs obtenues sur ton nombre de bits par pixel

Les bmp en 256 couleurs intègrent une palette aussi, c'est des "palettes bmp" standard au bmp ou on peut intégrer une "palette de la rom" ?

pour ça je laisse Baha repondre, il doit savoir, moi pas, j'ai jamais creusé plus que ça dans les bmp, je sais juste qu'on peut sur certains formats, les ouvrir avec tilemolester et monter leur palette de couleur, mais l'image est inversée il me semble, et je ne sais plus sous quel format est la palette (j'ai fait ça y'a un bail)

[jerome674]

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

Après différents tests, il semblerait que les mirroirs ne soient pas dans le même ordre, voici ce que j'obtiens après différents tests :

PPPPXYTTTTTTTTTT
X = mirror horizontal
Y = mirroir vertical

Mon image est parfaitement décodée avec un mirroir vertical au 6ème bit.
Test fait sur plusieurs images...

Bahabulle, peux-tu me confirmer ceci (l'inversion des 2 mirroirs) ?

[Lyan53]

Oui c'est possible en effet, je me rappelle jamais l'ordre exact, mais suffit simplement de vérifier sur le tas

[jerome674]

quel type de compression peut être a l'origine de de lignes verticales lors du décodage d'une image ?

une petite piste ?
la 1ere image que l'on a vu avec le robot en stase est ainsi en fait une fois la tile et la tilemap mise.