Combien de fois avez-vous eu besoin de modifier une image dont vous ne connaissez ni l'offset de l'image, ni celui de sa palette ? Dans cette situation, on se tourne dans un premier temps vers l'index de tiles et si on n'y trouve pas notre bonheur, on se tape alors les 1XXX images de UnLz-GBA en espérant le trouver.
Mais cette méthode est souvent longue et parfois sans résultat. Alors, comment faire pour retrouver l'image recherchée dans ce cas-là ? Et bien, ce tuto devrait vous apporter une solution dans la plupart des cas.
Je suis sûr qu'à première vue vous vous dites que ce tuto est bien trop long pour apporter une solution viable, mais c'est parce que j'ai pris soin de bien expliquer chaque chose. Une fois assimilé, retrouver une image et sa palette se fait en 3 minutes chrono.
Les nombres précédés d'un '#' sont en hexadécimal, sinon ils sont en décimal. Les bases de l'hexadécimal sont requises pour comprendre le tuto, mais rassurez-vous, savoir que #A = 10, #B = 11, etc. devrait suffire.
Vous avez tous déjà créé vos propres palettes car celles par défaut ne vous convenaient pas, pour ça vous avez par exemple utilisez l'outil d'édition de palette du logiciel Advance-Map. Mais pour la plupart d'entre vous la valeur hexadécimale correspondant aux différentes couleurs était incompréhensible (je suis même persuadé que certains ne savent pas de quelle valeur je parle). Celle qui se trouve dans le coin en bas à gauche :
Et bien il en est de même pour vos jeux Pokémon (et tous les jeux GBA), sauf qu'au lieu de coder les couleurs sur 24 bits, la console n'utilise que 16 bits (2 octets) pour limiter la place que prend une couleur (16 bits ça fait quand même 32 768 couleurs possibles). Comme on a 16 bits pour coder 3 composantes, cela fait 5 bits pour chaque composante (16/3 = 5), leurs valeurs peuvent donc varier de 0 à 31. Il est possible de trouver la valeur d'une composante codée sur 5 bits en connaissant celle codée sur 24 bits en divisant par 8. (car 255/31 = 8). Autre chose, sur GBA les composantes ne sont pas dans le même ordre, c'est à dire qu'au lieu d'avoir RVB on a BVR.
Je sens que je vous perds déjà, mais un exemple est toujours le bienvenu. Imaginons que je veux retrouver la valeur hexadécimale de la couleur qui se trouve sur l'image au dessus. Je connais ses composantes qui sont: R = 88, V = 176, B = 48 (codé sur 8 bits par composante). Je divise par 8 pour obtenir les valeurs codées sur 5 bits par composante. J'obtiens R = 11, V = 22, B = 6. Je convertis en binaire: R = 01011, V = 10110, B = 00110.
Remarque : pour ceux qui ne savent pas faire une conversion Décimal->Binaire vous pouvez utiliser la calculatrice Windows en mode programmeur. (Affichage->Programmeur)
Il me suffit alors de les mettre dans l'ordre BVR pour obtenir la valeur correspondant à ma couleur, codée sur 16 bits. Soit 001 1010 1100 1011, et si on convertit en hexadécimal, on retrouve bien le #1ACB que l'on pouvait voir sur l'image.
Remarque : les plus perspicaces d'entre vous auront remarqué que 5 * 3 = 15 bits, donc 15 bits suffisent pour coder une couleur, mais la console est capable de lire uniquement des paquets de 8 bits (1 octet), il faut donc utiliser 16 bits pour coder une couleur. Il reste alors 1 bit qui n'a pas d'utilité, pas à ma connaissance en tous cas, et de ce que j'ai pu observer il est toujours à 0.
Remarque : le logiciel NSE donne directement les valeurs en little-endian (inversé).
Un point important à connaître est que la première couleur d'une palette correspond toujours à la transparence, il ne reste donc que 15 couleurs d'utilisables en plus de la transparence. Mais normalement vous le saviez déjà.
La structure d'une palette dans la ROM est simple, il s'agit tout simplement d'une suite de couleurs codées sur 16 bits. Par exemple la palette du héros
est codée de la façon suivante dans la ROM :
Mais pour que la console sache quelle couleur de la palette elle doit utiliser, on attribue un indice à chaque couleur, de #0 à #F. Ainsi la première couleur est à l'indice 0, la deuxième à l'indice 1, etc. Cette notion est vraiment importante car c'est là-dessus que tout reposera quand on cherchera nos images.
Autre chose à savoir qui nous sera utile pour la suite c'est que la console n'est capable d'utiliser qu'un certain nombre de palettes à la fois, 16 pour les sprites (numérotées de #0 à #F), et 16 autres pour les backgrounds (numérotées de #0 à #F).
Comme vous le savez une image ne peut pas avoir n'importe quelles dimensions, il faut obligatoirement qu'elle soit un multiple de 8. On remarque d'ailleurs que la plupart des images sont en 1616, 1632, 3232, ou encore 6464.
Je vous préviens, à partir de là il va falloir être extrêmement attentif, la compréhension de ce qui suit est essentiel pour retrouver une image mais c'est aussi la partie compliquée à comprendre de la théorie.
La console n'est capable de charger que des carrés de 8*8, que l'on appelle bloc, une image est donc formée d'un ensemble de blocs. C'est aussi de cette façon qu'est structurée une image dans la ROM, par un ensemble de blocs mis les uns à la suite des autres. Certains me diront "Ok, mais ça change quoi ?". Et bien c'est totalement différent de si les informations étaient structurées ligne par ligne. Pour vous en convaincre regardez l'exemple suivant (dimension: 16*16):
Si l'information était structurée ligne par ligne j'aurais eu: 8 rouge, 8 bleu, 8 rouge, 8 bleu, ..., 8 vert, 8 blanc, 8 vert, 8 blanc, etc. Alors qu'en structurant l'information par bloc j'obtiens: 64 rouge, 64 bleu, 64 vert, 64 blanc.
Maintenant que l'on sait comment est structurée une image observons comment est codé un pixel. C'est ici qu'on va avoir besoin des indices de la palette. La couleur d'un pixel est en fait définie par son indice, et l'image est uniquement composée d'indices. On a vu que l'indice peut varier entre #0 et #F, chaque octet correspond donc à deux pixels. Prenons cette image 88 (dimension: 88)
, et la palette suivante: Blanc Rouge Vert Bleu puis le reste Noir. Voilà comment serait codée l'image dans la ROM :
La première étape est donc d'ouvrir VBA et de faire en sorte que l'image que vous cherchez apparaisse à l'écran.
À partir de là je vais distinguer deux cas d'images : les sprites et ce qui fait partie des backgrounds. Car les outils à utiliser ne sont pas tous à fait les mêmes. Remarque : au début vous aurez peut-être du mal à savoir si vous cherchez un sprite ou un élément du background mais avec l'habitude vous ferez facilement la différence. Et si vous ne trouvez pas votre élément avec un des outils c'est qu'il faut utilisez l'autre.
Observez maintenant les informations affichées, on remarque une ligne "Pal:", et bien il s'agit du numéro de la palette en mémoire que votre sprite utilise (0 dans l'exemple ci-dessus), retenez-le. Vous pouvez fermer cet outil, on en aura pas besoin dans l'immédiat. Si vous avez trouvé votre image dans le visualiseur OAM alors vous pouvez passé directement à la partie: "rechercher la palette dans la mémoire".
Une petite explication s'impose : rappelez-vous que les images sont composées de blocs de 8*8. Et pour les sprites, la palette utilisée est la même pour tous les blocs. Mais en revanche pour les background chaque bloc peut utiliser une palette différente (parmi les 16 en mémoire).
Pour en revenir à notre background vous devez donc cliquer sur une partie de l'image recherchée pour avoir la palette qui lui correspond, retenez le numéro de la palette.
Les palettes sont rangées dans l'ordre (de #0 à #F), vous ne devriez donc pas avoir trop de problème pour retrouver celle de votre image. Remarque : vous pouvez voir la valeur d'une couleur en cliquant dessus.
Remarque : vérifier bien que votre recherche ne donne qu'un seul résultat, il se peut que plusieurs palettes partagent les mêmes couleurs.
Remarque : le principe est le même avec les palettes en 256 couleurs.
Vous remarquerez que quand on clique sur une partie de l'image (dans le viewer) elle se retrouve affichée à un endroit, ce qui est affiché est en fait un bloc de 8*8 qui fait partie de notre image. Mais pour notre recherche seule une ou deux lignes suffisent. Et plus il y a de variations de couleurs dans ces lignes mieux c'est, donc faite en sorte de trouver les lignes les plus adaptées sur votre image. Pour moi ce sera la 2eme ligne de ce bloc :
Remarque : il se peut que certaines images possèdent très peu de variations de couleurs, ce genre d'images donne beaucoup de résultats lors de la recherche, elles vous obligeront donc à essayer différentes lignes pour la recherche voir même à utiliser plusieurs lignes à la fois.
Une fois que vous avez identifié quelle ligne sera la plus appropriée il faut essayer de reproduire la façon dont elle serait codée dans la ROM. Pour ça cliquez sur le premier pixel de la ligne, les valeurs de ses composantes devraient s'afficher, il ne vous reste plus qu'à retrouver de quelle couleur il s'agit dans la palette et à noter son index, souvenez vous, on a fait ça dans un des exercices que j'ai donné dans la partie théorique. Pour la deuxième ligne de la main j'obtiens donc ceci:
Remarque : parfois le pointeur ne pointe pas directement sur la palette mais quelques octets plus tôt. Donc si la recherche ne donne pas de résultat essayez de prendre un offset un peu avant.
Si vous regardez les données autour de votre résultat vous devriez voir qu'il y a d'autres pointeurs, et bien la méthode consiste à vérifier un par un chaque pointeur avec NSE, car souvent le pointeur de la palette et de l'image sont proche. Je ne vous donne pas d'exemple cette fois car la main qui me servait d'exemple jusqu'à présent ne suit pas cette règle.
Les nombres précédés d'un '#' sont en hexadécimal, sinon ils sont en décimal. Les bases de l'hexadécimal sont requises pour comprendre le tuto, mais rassurez-vous, savoir que #A = 10, #B = 11, etc. devrait suffire.
Les outils nécessaires
Les outils nécessaires vont ici énormément nous simplifier la tâche, nous donnant presque directement la solution. Le premier est VisualBoyAdvance, et oui, votre fameux émulateur va ici beaucoup nous aider. Votre éditeur Hexadécimal. On utilisera aussi Namless Sprite Editor (NSE) pour visualiser et vérifier nos résultats.Le stockage des données
On va commencer par une bonne dose de théorie, car il est nécessaire que vous compreniez comment sont stockées les images et les palettes dans la ROM. (pour les couleurs c'est moins important mais de toute manière c'est simple à comprendre)Les couleurs
Comme vous le savez, les palettes sont composées de couleurs, on va donc tenter de comprendre comment sont codées ces couleurs.Vous avez tous déjà créé vos propres palettes car celles par défaut ne vous convenaient pas, pour ça vous avez par exemple utilisez l'outil d'édition de palette du logiciel Advance-Map. Mais pour la plupart d'entre vous la valeur hexadécimale correspondant aux différentes couleurs était incompréhensible (je suis même persuadé que certains ne savent pas de quelle valeur je parle). Celle qui se trouve dans le coin en bas à gauche :
Et bien il en est de même pour vos jeux Pokémon (et tous les jeux GBA), sauf qu'au lieu de coder les couleurs sur 24 bits, la console n'utilise que 16 bits (2 octets) pour limiter la place que prend une couleur (16 bits ça fait quand même 32 768 couleurs possibles). Comme on a 16 bits pour coder 3 composantes, cela fait 5 bits pour chaque composante (16/3 = 5), leurs valeurs peuvent donc varier de 0 à 31. Il est possible de trouver la valeur d'une composante codée sur 5 bits en connaissant celle codée sur 24 bits en divisant par 8. (car 255/31 = 8). Autre chose, sur GBA les composantes ne sont pas dans le même ordre, c'est à dire qu'au lieu d'avoir RVB on a BVR.
Je sens que je vous perds déjà, mais un exemple est toujours le bienvenu. Imaginons que je veux retrouver la valeur hexadécimale de la couleur qui se trouve sur l'image au dessus. Je connais ses composantes qui sont: R = 88, V = 176, B = 48 (codé sur 8 bits par composante). Je divise par 8 pour obtenir les valeurs codées sur 5 bits par composante. J'obtiens R = 11, V = 22, B = 6. Je convertis en binaire: R = 01011, V = 10110, B = 00110.
Remarque : pour ceux qui ne savent pas faire une conversion Décimal->Binaire vous pouvez utiliser la calculatrice Windows en mode programmeur. (Affichage->Programmeur)
Il me suffit alors de les mettre dans l'ordre BVR pour obtenir la valeur correspondant à ma couleur, codée sur 16 bits. Soit 001 1010 1100 1011, et si on convertit en hexadécimal, on retrouve bien le #1ACB que l'on pouvait voir sur l'image.
Remarque : les plus perspicaces d'entre vous auront remarqué que 5 * 3 = 15 bits, donc 15 bits suffisent pour coder une couleur, mais la console est capable de lire uniquement des paquets de 8 bits (1 octet), il faut donc utiliser 16 bits pour coder une couleur. Il reste alors 1 bit qui n'a pas d'utilité, pas à ma connaissance en tous cas, et de ce que j'ai pu observer il est toujours à 0.
Exercice : pour être sûr que vous ayez compris je vous propose un petit exercice, essayez de le faire sans vous baser sur mon exemple, ce serait trop simple et montrerait juste que vous êtes capable de me copier comme un imbécile. La couleur à convertir est ce violet: R = 136, V = 56, B = 160.
En réalité les couleurs ne sont pas directement sous cette forme dans la ROM, elles sont en little-endian (inversé), on retrouvera donc notre couleur #1ACB sous la forme #CB1A dans la ROM. Mais quand la console "lit" la ROM, elle interprète la couleur comment étant #1ACB. Si vous voulez mieux comprendre pourquoi (Google -> little-endian).Remarque : le logiciel NSE donne directement les valeurs en little-endian (inversé).
Les palettes
Il existe en GBA deux types de palettes, les palettes de 16 couleurs et les palettes de 256 couleurs. L'avantage d'avoir plusieurs types de palette est que l'une prend moins de place que l'autre et sûrement pour les performances. Car comme vous le savez maintenant chaque couleur a une taille de 2 octets, donc une palette en 16c a une taille de 32 octets alors qu'une palette en 256c a une taille de 512 octets, c'est radicalement différent. C'est pour ça que la plupart des images des jeux GBA utilisent les palettes 16c, les palettes 256c ne sont utilisées que quand c'est réellement nécessaire.Un point important à connaître est que la première couleur d'une palette correspond toujours à la transparence, il ne reste donc que 15 couleurs d'utilisables en plus de la transparence. Mais normalement vous le saviez déjà.
La structure d'une palette dans la ROM est simple, il s'agit tout simplement d'une suite de couleurs codées sur 16 bits. Par exemple la palette du héros
est codée de la façon suivante dans la ROM :F051 F521 1F4B 5B3A 0F21 0869 E73C 8E62<br />
AD14 BD7F D66A BF25 F81C 7F2F 771E 0000
Mais pour que la console sache quelle couleur de la palette elle doit utiliser, on attribue un indice à chaque couleur, de #0 à #F. Ainsi la première couleur est à l'indice 0, la deuxième à l'indice 1, etc. Cette notion est vraiment importante car c'est là-dessus que tout reposera quand on cherchera nos images.
Exercice : Extrêmement simple mais on aura besoin de faire ce genre de chose pour retrouver une image, donc je veux être sûr que vous ayez compris. Je veux que dans la palette du héros (donnée au dessus) vous me donniez l'indice des couleurs D66A, E73C, et 771E. Mais aussi que vous me donniez les couleurs qui se trouvent aux indices 9, 3, et 4.
Remarque : certaines palettes n'ont pas exactement la même structure, je ne sais pas pourquoi mais elles sont composées de #00 tous les 8 octets. Ce qui donne ce genre de chose (les YYYY sont les couleurs) :YYYY YYYY YYYY YYYY 00 YYYY YYYY YYYY YYYY 00 YYYY YYYY YYYY YYYY 00 YYYY YYYY YYYY YYYY
Autre chose à savoir qui nous sera utile pour la suite c'est que la console n'est capable d'utiliser qu'un certain nombre de palettes à la fois, 16 pour les sprites (numérotées de #0 à #F), et 16 autres pour les backgrounds (numérotées de #0 à #F).
Les images
Tout comme pour les palettes il va falloir distinguer deux types d'images, celles qui utilisent une palette de 16 couleurs et celles qui utilisent une palette de 256 couleurs. J'expliquerais seulement celles qui utilisent 16 couleurs car ce sont les plus fréquentes mais aussi car celles en 256 couleurs sont bien souvent compressées pour prendre moins de place, donc savoir comment elles se structure ne nous aidera pas à les trouver. Remarque : il est possible que certaines images en 16 couleurs soient elles aussi compressées pour prendre moins de place, mais on sera quand même en mesure de les trouver.Comme vous le savez une image ne peut pas avoir n'importe quelles dimensions, il faut obligatoirement qu'elle soit un multiple de 8. On remarque d'ailleurs que la plupart des images sont en 1616, 1632, 3232, ou encore 6464.
Je vous préviens, à partir de là il va falloir être extrêmement attentif, la compréhension de ce qui suit est essentiel pour retrouver une image mais c'est aussi la partie compliquée à comprendre de la théorie.
La console n'est capable de charger que des carrés de 8*8, que l'on appelle bloc, une image est donc formée d'un ensemble de blocs. C'est aussi de cette façon qu'est structurée une image dans la ROM, par un ensemble de blocs mis les uns à la suite des autres. Certains me diront "Ok, mais ça change quoi ?". Et bien c'est totalement différent de si les informations étaient structurées ligne par ligne. Pour vous en convaincre regardez l'exemple suivant (dimension: 16*16):
Si l'information était structurée ligne par ligne j'aurais eu: 8 rouge, 8 bleu, 8 rouge, 8 bleu, ..., 8 vert, 8 blanc, 8 vert, 8 blanc, etc. Alors qu'en structurant l'information par bloc j'obtiens: 64 rouge, 64 bleu, 64 vert, 64 blanc.
Maintenant que l'on sait comment est structurée une image observons comment est codé un pixel. C'est ici qu'on va avoir besoin des indices de la palette. La couleur d'un pixel est en fait définie par son indice, et l'image est uniquement composée d'indices. On a vu que l'indice peut varier entre #0 et #F, chaque octet correspond donc à deux pixels. Prenons cette image 88 (dimension: 88)
, et la palette suivante: Blanc Rouge Vert Bleu puis le reste Noir. Voilà comment serait codée l'image dans la ROM :00 11 11 00 01 22 22 10 12 23 32 21 12 33 33 21<br />
12 33 33 21 12 23 32 21 01 22 22 10 00 11 11 00
00 11 11 00 10 22 22 01 21 32 23 12 21 33 33 12<br />
21 33 33 12 21 32 23 12 10 22 22 01 00 11 11 00
Exercice : celui-ci sera plus complet que les premiers pour être sûr que vous maîtrisiez la chose. Vous allez devoir me refaire les données de l'image qui suit, en utilisant la palette en haut de l'image. Bon courage.
Si vous n'avez pas réussi, recommencez tranquillement à lire cette partie. Vous devez absolument réussir cet exercice car on en aura besoin à chaque fois que l'on voudra trouver une image.
On a enfin terminé avec la théorie, on va maintenant pouvoir mettre en pratique ce que je viens de vous apprendre. Si vous avez compris la partie théorique dans son intégralité la suite ne devrait pas vous poser de problème, sinon, je me répète, relisez la partie sur les palette et sur les images.Retrouver la palette
Avec ce que vous savez maintenant il existe plusieurs méthodes qui vous permettront de trouver la palette et l'image recherchée, mais VBA met à notre disposition des outils qui nous simplifient vraiment la tâche, alors pourquoi s'en priver.La première étape est donc d'ouvrir VBA et de faire en sorte que l'image que vous cherchez apparaisse à l'écran.
À partir de là je vais distinguer deux cas d'images : les sprites et ce qui fait partie des backgrounds. Car les outils à utiliser ne sont pas tous à fait les mêmes. Remarque : au début vous aurez peut-être du mal à savoir si vous cherchez un sprite ou un élément du background mais avec l'habitude vous ferez facilement la différence. Et si vous ne trouvez pas votre élément avec un des outils c'est qu'il faut utilisez l'autre.
Quel est le numéro de la palette: les sprites
Si l'image que vous cherchez est un sprite alors ouvrez le visualiseur d'OAM (Tools->OAM Viewer...). Et utilisez les flèches en haut à gauche pour retrouver votre sprite. Voilà ce que vous devriez obtenir :
Observez maintenant les informations affichées, on remarque une ligne "Pal:", et bien il s'agit du numéro de la palette en mémoire que votre sprite utilise (0 dans l'exemple ci-dessus), retenez-le. Vous pouvez fermer cet outil, on en aura pas besoin dans l'immédiat. Si vous avez trouvé votre image dans le visualiseur OAM alors vous pouvez passé directement à la partie: "rechercher la palette dans la mémoire".
Exercice : cette fois l'exercice sera de trouver le numéro de la palette de l'overworld du héros.
Quel est le numéro de la palette: les backgrounds
Si vous n'avez pas trouvé l'image recherchée dans le visualiseur OAM cela signifie qu'elle fait partie du background, et la méthode est quelque peu différente. Cette fois il va falloir utiliser le visualiseur de Map (Tools->Map Viewer...).
Une petite explication s'impose : rappelez-vous que les images sont composées de blocs de 8*8. Et pour les sprites, la palette utilisée est la même pour tous les blocs. Mais en revanche pour les background chaque bloc peut utiliser une palette différente (parmi les 16 en mémoire).
Pour en revenir à notre background vous devez donc cliquer sur une partie de l'image recherchée pour avoir la palette qui lui correspond, retenez le numéro de la palette.
Exercice : vous devez trouver le numéro de la palette du Centre Pokémon (l'extérieur du bâtiment).
Rechercher la palette dans la mémoire
Maintenant que l'on connaît le numéro de la palette en mémoire on va pouvoir la visualiser. Pour commencer ouvrez le visualiseur de palette (Tools->Palette Viewer...). Le menu suivant devrait s'ouvrir :
Les palettes sont rangées dans l'ordre (de #0 à #F), vous ne devriez donc pas avoir trop de problème pour retrouver celle de votre image. Remarque : vous pouvez voir la valeur d'une couleur en cliquant dessus.
Rechercher la palette dans la ROM
Maintenant que l'on connaît la palette il ne reste plus qu'à trouver où elle se trouve dans la ROM. Pour ça on va refaire la palette sous sa forme hexadécimale, comme on l'a fait dans la partie théorique. Je met donc chaque couleur obtenue grâce au visualiseur de VBA les unes à la suite des autres pour obtenir ma palette. Par exemple la palette de la main (voir image plus haut) est :0000 5652 2D4A 7FFF 7FF9 76EB 668B 520A<br />
3DAA 2D4A 0000 7B7B 5A94 5652 3DCE 2D4A
0000 5256 4A2D FF7F F97F EB76 8B66 0A52<br />
AA3D 4A2D 0000 7B7B 945A 5256 CE3D 4A2D
Remarque : vérifier bien que votre recherche ne donne qu'un seul résultat, il se peut que plusieurs palettes partagent les mêmes couleurs.
Exercice : vous devez retrouver à quel offset se trouve la palette du héros.
Vous voyez ? Une fois que l'on a compris le système, retrouver la palette est extrêmement simple et rapide.Remarque : le principe est le même avec les palettes en 256 couleurs.
Retrouver l'image
Il est nécessaire d'avoir trouvé la palette avant de chercher l'image, qu'elle soit en 16 ou 256 couleurs, compressée ou non. Sinon vous n'avez aucune chance de la trouver avec cette méthode.Les images 16c non compressées
L'idée sera comme pour les palettes d'essayer d'imaginer à quoi ressemble l'image dans la ROM pour ensuite faire une recherche. Encore une fois VBA va énormément nous simplifier la tâche. La première chose à faire est d'ouvrir l'OAM Viewer ou le Map Viewer suivant votre image.Vous remarquerez que quand on clique sur une partie de l'image (dans le viewer) elle se retrouve affichée à un endroit, ce qui est affiché est en fait un bloc de 8*8 qui fait partie de notre image. Mais pour notre recherche seule une ou deux lignes suffisent. Et plus il y a de variations de couleurs dans ces lignes mieux c'est, donc faite en sorte de trouver les lignes les plus adaptées sur votre image. Pour moi ce sera la 2eme ligne de ce bloc :
Remarque : il se peut que certaines images possèdent très peu de variations de couleurs, ce genre d'images donne beaucoup de résultats lors de la recherche, elles vous obligeront donc à essayer différentes lignes pour la recherche voir même à utiliser plusieurs lignes à la fois.
Une fois que vous avez identifié quelle ligne sera la plus appropriée il faut essayer de reproduire la façon dont elle serait codée dans la ROM. Pour ça cliquez sur le premier pixel de la ligne, les valeurs de ses composantes devraient s'afficher, il ne vous reste plus qu'à retrouver de quelle couleur il s'agit dans la palette et à noter son index, souvenez vous, on a fait ça dans un des exercices que j'ai donné dans la partie théorique. Pour la deuxième ligne de la main j'obtiens donc ceci:
2B 33 B2 CC
B2 33 2B CC
Exercice : cet exercice va être le plus difficile de ce tuto (sans compter l'exercice qui se trouve tous à la fin) mais je suis sûr que vous y arriverez. Vous allez devoir retrouver l'offset de l'image du truc qui montre qu'un Pokémon porte un objet (visible dans le menu Pokémon). Pour ça il faudra utiliser l'OAM viewer et non le Map Viewer, et la palette est de l'image est la numéro #0.
Les images 256c ou compressées
Pour ce genre d'images il n'y a pas de miracle, soit vous la trouvez dans UnlZ-GBA, ou alors vous allez devoir tâtonner. Pour cette méthode on va avoir besoin de l'offset de notre palette, et on va cherchez le pointeur qui lui correspond. Pour ceux qui ne savent pas comment faire, commencez par inverser l'offset de la palette puis rajoutez 08 à la fin, par exemple pour la main vu plus haut : #3C8630 devient #30863C08. Et ensuite je lance une recherche pour #30863C08.Remarque : parfois le pointeur ne pointe pas directement sur la palette mais quelques octets plus tôt. Donc si la recherche ne donne pas de résultat essayez de prendre un offset un peu avant.
Si vous regardez les données autour de votre résultat vous devriez voir qu'il y a d'autres pointeurs, et bien la méthode consiste à vérifier un par un chaque pointeur avec NSE, car souvent le pointeur de la palette et de l'image sont proche. Je ne vous donne pas d'exemple cette fois car la main qui me servait d'exemple jusqu'à présent ne suit pas cette règle.
Exercice : la palette d'une des fenêtres de texte se trouve à l'offset #469244, à vous de retrouver son image avec cette méthode.
Exercice final
Maintenant vous avez tous les outils pour retrouver à peu près n'importe quelle image et sa palette. Mais je sens que vous manquez d'entrainement, un exercice complet est donc le meilleur moyen de s'entraîner et de vérifier que vous avez bien compris le tuto. Si vous n'y arrivez pas, ne regardez pas tout de suite la correction, faite une pause, relisez la partie qui vous fait défaut, puis ré-essayez.L'énoncé
Votre mission est de retrouver les offsets (palette et image) de la petite Poké Ball qui nous indique si on a déjà capturé un Pokémon ou non, c'est la même que celle qui indique combien de Pokémon il reste dans notre équipe et dans l'équipe adverse. Pour ceux qui ne voient toujours pas de quoi je parle, c'est celle-là :
Retrouvez la correction de chaque exercice sur le topic du forum.
Par Unifag
