Enfin, je vais pouvoir mieux gérer mes offsets ! Mais au fait, c'est quoi un offset ?
Il faut déjà savoir qu'une ROM GBA est écrite en hexadécimal, un système utilisant 16 caractères :
Donc, en théorie, on pourrait tout modifier juste en touchant aux octets via un éditeur hexadécimal. Bon, en pratique, c'est assez long et fastidieux, c'est pour cela que l'on se sert de logiciels qui font ces modifications pour vous.
On peut effectuer plusieurs types de travaux sur ces offsets : directement modifier les données écrites à cet offset, ou écrire sur des octets vierges.
On peut effectuer les modifications sur offset libre sans souci d'effacer d'anciennes données si c'est bien fait. Mais la plupart du temps, il faudra repointer. Cela consiste à utiliser un pointeur, une " commande " qui va aller à un offset donné pour récupérer et transcrire le contenu à cet offset donné.
Prenons un exemple avec un script basique :
***
En réalité, lorsque vous jouez à votre jeu, il y a beaucoup plus d'offsets utilisés que ceux que vous pouvez observer dans votre éditeur hexadécimal. Pour faire simple, il y a des offsets de 0x00000000 à 0x07FFFFFF en plus de ce que vous pouvez voir dans l'éditeur hexadécimal. Après ces offsets, il y a une suite d'offsets commençant par 0x08XXXXXX : ce sont ces offsets-là que vous pouvez voir dans votre éditeur hexadécimal. Par exemple, si vous trouvez une adresse libre à l'offset 0xA48000, son " véritable " offset est 0x08A48000. C'est pourquoi, si vous voulez pointer vers cet offset dans un script, vous devez utiliser 0x8 devant l'offset choisi !
*
C'est valable pour toutes les modifications, comme pour les sprites, ou encore les attaques, etc.
Parfois, les logiciels ont aussi besoin de repointer pour écrire de nouvelles données. Vous aurez donc à donner un offset libre contenant suffisamment d'espace pour accepter les modifications, et le logiciel fera le lien avec le pointeur et le reste tout seul.
En bleu, les options basiques de recherche : Rechercher, Suivante (cf. le paragraphe qui suit sur l'intervalle de recherche), et Copier pour copier l'offset que vous donne le logiciel. On a aussi un petit convertisseur hexadécimal/décimal en bas à droite. Nous avons, en rouge, le nombre d'octets libres que vous souhaitez. Dans 99% des cas, c'est le logiciel qui vous donne l'espace nécessaire.
Vous pouvez, en plus, sur Advance-Map, effectuer une " double vérification ". Il suffit de cocher " spécifier zone de recherche ", et de mettre en offset de départ celui fourni par FSF, et en offset de fin $FFFFFF (qui est tout simplement le dernier de la ROM). Vous faites " OK " et vous sélectionnez un des offsets proposés.
Encadré en vert, c'est l'intervalle de recherche. Il s'agit du nombre d'octets que FSF va laisser vierges avant de rechercher un nouvel offset lorsque vous faites " suivant ". En gros, ça laisse un nombre défini de FF vides avant de chercher un nouvel offset. Bien gérer cela permet d'éviter de nombreux bugs dus au chevauchement des offsets (modification d'octets qui empiètent sur d'autres octets modifiés). C'est surtout utilisé pour les scripts : vu qu'il faut un certain nombre d'offsets libres avant de compiler le tout en une fois, on ne peut donc pas effectuer une recherche " classique ".
La première question qui vient à l'esprit est : " mais combien d'octets libres doit faire l'offset ? ". Alors, si vous avez du temps à perdre, vous pouvez toujours calculer grâce à XSE. En faisant F1, la liste des commandes ainsi que les octets nécessaires apparaissent. Si vous êtes comme moi et que vous n'avez pas de temps à perdre, vous prenez des offsets très grands pour être sûr d'avoir suffisamment d'octets à disposition (entre 1000 et 10000 pour un script). De toute façon, comme dit précédemment, les octets non nécessaires ne seront pas utilisés, pourquoi s'embêter ?
Bon, voyons voir ce que ça donne en pratique :
NB : Cette méthode est applicable à toutes les recherches d'offsets, pas seulement pour les offsets secondaires d'un script, cela fonctionne pour tout. L'avantage du visualiseur hexadécimal de XSE est que vous pouvez visualiser les offsets et les octets tout en travaillant sur la ROM. Cependant, pour des modifications en touchant directement à l'hexadécimal, utilisez HxD.
Bon, on applique la méthode pour tous les autres offsets et on se retrouve avec ça :
1. Un texte déformé
Voici un script basique :
Si on a vu qu'un texte pouvait être transformé en n'importe quoi, un script entier peut faire la même chose. Un exemple rapide : imaginons que je fasse un script avec pas mal de commandes sur un offset avec très peu d'espace libre. À la décompilation du script, voici le résultat :
3. Un sprite explosé
Bien, maintenant que vous avez vu qu'un script pouvait n'en faire qu'à sa tête, je vais vous montrer un dernier exemple, qui touche un tout autre domaine : les images, plus précisément les sprites. Prenons ce script :
Enfin bref, il y a deux sortes de bugs provoqués par cette mauvaise gestion des offsets. Le premier type regroupe les trois bugs présentés précédemment : ils ne sont absolument pas graves ni dangereux pour votre projet. En effet, il est très simple de réécrire un texte ou, au pire, de refaire son script en entier. Pour ce qui est du sprite, il est très simple avec Advance Sprite Editor ou NSE de réinsérer un sprite " clean ".
En revanche, certaines fois, vous provoquerez de graves bugs, très mauvais pour votre ROM. Pour mon top personnel, j'en ai fait des belles : faire disparaître le sprite du héros, provoquer un tremblement de terre continu, un reset incessant du jeu après l'écran de démarrage, ou encore des choses beaucoup plus surprenantes comme je vous laisse les découvrir :
Dans ces cas-là, il n'y a pas vraiment de solution miracle : il faut faire des sauvegardes (backups) régulièrement. Si un tel bug survient, utilisez une ancienne sauvegarde afin de pouvoir continuer sans garder le bug provoqué.
Chaque donnée stockée a une taille qui lui est propre. Ainsi, si votre message fait 100 octets de longueur, le script va charger 100 octets à partir de l'offset indiqué. Vous aurez alors besoin d'un espace libre minimum de 100 octets à un offset, offset que vous pouvez trouver en utilisant un logiciel comme FSF ou bien en regardant directement dans un éditeur hexadécimal.
Si vous enregistrez des données sans leur donner l'espace dont elles ont besoin, alors vous provoquerez différents bugs, de grandeur et de gravité variables. Les plus bénins seront simples à corriger, mais certains seront beaucoup plus coriaces et embêtants : on ne le redira jamais assez, il vous faut faire des sauvegardes régulièrement afin d'éviter ce genre de problème.
Enfin, voici un petit schéma récapitulatif de ce tutoriel :
Merci de nous avoir lus, nous espérons que ce tutoriel vous aura été utile et que vous ferez moins d'erreurs concernant les offsets !
Il faut déjà savoir qu'une ROM GBA est écrite en hexadécimal, un système utilisant 16 caractères :
- Les chiffres de 0 à 9
- Les lettres de A à F
Donc, en théorie, on pourrait tout modifier juste en touchant aux octets via un éditeur hexadécimal. Bon, en pratique, c'est assez long et fastidieux, c'est pour cela que l'on se sert de logiciels qui font ces modifications pour vous.
Mais les offsets dans tout ça ?
Alors pour faire simple, un offset, c'est une adresse (pas tout à fait vrai, mais c'est grosso modo ce qu'il faut concevoir pour comprendre la suite). Et, à cette adresse, vous allez trouver une suite d'octets, comme vous pouvez le voir sur la capture d'écran ci-dessus. Il y a des offsets " occupés ", où un ou plusieurs octets y sont modifiés, et des offsets " libres ", qui contiennent pour octets des suites de FF. Attention cependant, un octet FF ne signifiera pas systématiquement que l'octet est vierge.On peut effectuer plusieurs types de travaux sur ces offsets : directement modifier les données écrites à cet offset, ou écrire sur des octets vierges.
On peut effectuer les modifications sur offset libre sans souci d'effacer d'anciennes données si c'est bien fait. Mais la plupart du temps, il faudra repointer. Cela consiste à utiliser un pointeur, une " commande " qui va aller à un offset donné pour récupérer et transcrire le contenu à cet offset donné.
Prenons un exemple avec un script basique :
'----------
#org 0xoffset1
msgbox 0x8offset2 MSG_SIGN
end
#org 0xoffset2
= Texte.
***
Petite explication concernant le " 8 "
(Cependant, ce n'est pas très important, il n'est pas primordial de comprendre ce point pour la suite).En réalité, lorsque vous jouez à votre jeu, il y a beaucoup plus d'offsets utilisés que ceux que vous pouvez observer dans votre éditeur hexadécimal. Pour faire simple, il y a des offsets de 0x00000000 à 0x07FFFFFF en plus de ce que vous pouvez voir dans l'éditeur hexadécimal. Après ces offsets, il y a une suite d'offsets commençant par 0x08XXXXXX : ce sont ces offsets-là que vous pouvez voir dans votre éditeur hexadécimal. Par exemple, si vous trouvez une adresse libre à l'offset 0xA48000, son " véritable " offset est 0x08A48000. C'est pourquoi, si vous voulez pointer vers cet offset dans un script, vous devez utiliser 0x8 devant l'offset choisi !
*
C'est valable pour toutes les modifications, comme pour les sprites, ou encore les attaques, etc.
Parfois, les logiciels ont aussi besoin de repointer pour écrire de nouvelles données. Vous aurez donc à donner un offset libre contenant suffisamment d'espace pour accepter les modifications, et le logiciel fera le lien avec le pointeur et le reste tout seul.
Mais comment bien définir l'offset pour les modifications de la ROM ?
Pour les repoints classiques, le plus souvent sur Advance-Map, mais la méthode est valable pour les autres logiciels. Il n'y a pas de technique à proprement parler, mais il est vrai qu'un peu de méthodologie et de logique s'impose pour éviter les bugs les plus fréquents. Le logiciel dont on va se servir est FSF (Free Space Finder). Il va repérer les suites de " FF ", soit les espaces libres de votre ROM, et va fournir un offset à partir de ces données. Il suffit de lui donner la taille de l'espace nécessaire, en octets, ainsi que l'intervalle de recherche. Regardons cela de plus près :
En bleu, les options basiques de recherche : Rechercher, Suivante (cf. le paragraphe qui suit sur l'intervalle de recherche), et Copier pour copier l'offset que vous donne le logiciel. On a aussi un petit convertisseur hexadécimal/décimal en bas à droite. Nous avons, en rouge, le nombre d'octets libres que vous souhaitez. Dans 99% des cas, c'est le logiciel qui vous donne l'espace nécessaire.
Recherche d'offsets classique
Vous pouvez, en plus, sur Advance-Map, effectuer une " double vérification ". Il suffit de cocher " spécifier zone de recherche ", et de mettre en offset de départ celui fourni par FSF, et en offset de fin $FFFFFF (qui est tout simplement le dernier de la ROM). Vous faites " OK " et vous sélectionnez un des offsets proposés.
Encadré en vert, c'est l'intervalle de recherche. Il s'agit du nombre d'octets que FSF va laisser vierges avant de rechercher un nouvel offset lorsque vous faites " suivant ". En gros, ça laisse un nombre défini de FF vides avant de chercher un nouvel offset. Bien gérer cela permet d'éviter de nombreux bugs dus au chevauchement des offsets (modification d'octets qui empiètent sur d'autres octets modifiés). C'est surtout utilisé pour les scripts : vu qu'il faut un certain nombre d'offsets libres avant de compiler le tout en une fois, on ne peut donc pas effectuer une recherche " classique ".
Recherches d'offsets pour les scripts
Je vous donne donc une méthode qui, selon moi, est la plus sûre, même si elle est un peu longue. On va utiliser :- Advance-Map
- Free Space Finder
- XSE
'----------
#org 0xoffset1
lock
faceplayer
msgbox 0x8offset2 MSG_YESNO
compare LASTRESULT 0x1
if 0x1 goto 0x8offset3
release
end
#org 0xoffset3
msgbox 0x8offset4 MSG_NORMAL
release
end
#org 0xoffset2
= Oui ou non?
#org 0xoffset4
= Ok.
La première question qui vient à l'esprit est : " mais combien d'octets libres doit faire l'offset ? ". Alors, si vous avez du temps à perdre, vous pouvez toujours calculer grâce à XSE. En faisant F1, la liste des commandes ainsi que les octets nécessaires apparaissent. Si vous êtes comme moi et que vous n'avez pas de temps à perdre, vous prenez des offsets très grands pour être sûr d'avoir suffisamment d'octets à disposition (entre 1000 et 10000 pour un script). De toute façon, comme dit précédemment, les octets non nécessaires ne seront pas utilisés, pourquoi s'embêter ?
Bon, voyons voir ce que ça donne en pratique :
NB : Cette méthode est applicable à toutes les recherches d'offsets, pas seulement pour les offsets secondaires d'un script, cela fonctionne pour tout. L'avantage du visualiseur hexadécimal de XSE est que vous pouvez visualiser les offsets et les octets tout en travaillant sur la ROM. Cependant, pour des modifications en touchant directement à l'hexadécimal, utilisez HxD.
Bon, on applique la méthode pour tous les autres offsets et on se retrouve avec ça :
J'ai un bug, que faire ?!
Abordons une partie sensible : les bugs. Au vu de la complexité et de la fragilité d'une ROM, une mauvaise manipulation au niveau des offsets peut causer de gros dommages à votre jeu, parfois irréversibles, parfois réparables. Regardons ça de plus près.Quelques exemples de bugs
On va commencer par de l'observation ! Je vais vous montrer quelques exemples de bugs que l'on peut obtenir si on gère mal les offsets.1. Un texte déformé
Voici un script basique :
'---------------
#org 0x800384
msgbox 0x8800385 MSG_FACE '"Bonjour !"
end
'---------
' Strings
'---------
#org 0x800385
= Bonjour !
'---------------
#org 0x800384
msgbox 0x8800385 MSG_YESNO '" <Â\h80ËÌÈÁÒ\h80À ÉÀFÊ\h71ËÁ"<
end
'---------
' Strings
'---------
#org 0x800385
= <Â\h80ËÌÈÁÒ\h80À ÉÀFÊ\h71ËÁ
Si on a vu qu'un texte pouvait être transformé en n'importe quoi, un script entier peut faire la même chose. Un exemple rapide : imaginons que je fasse un script avec pas mal de commandes sur un offset avec très peu d'espace libre. À la décompilation du script, voici le résultat :
'---------------
#org 0x800384
loadpointer 0xBC 0xE3DEE2E3
3. Un sprite explosé
Bien, maintenant que vous avez vu qu'un script pouvait n'en faire qu'à sa tête, je vais vous montrer un dernier exemple, qui touche un tout autre domaine : les images, plus précisément les sprites. Prenons ce script :
'---------------
#org 0x800974
showpokepic 0x1 0x1 0x1
end
Et ensuite, que faire contre ces bugs ?
Vous avez vu que de nombreux bugs peuvent survenir si on ne fait pas attention à la manière dont on manipule nos offsets. Cependant, il arrive parfois que, même en ayant beaucoup d'expérience, en faisant très attention et en prenant de nombreuses précautions, on détruise des données stockées précédemment. Je parle en connaissance de cause, j'ai déjà détruit des dizaines de ROM comme ça !Enfin bref, il y a deux sortes de bugs provoqués par cette mauvaise gestion des offsets. Le premier type regroupe les trois bugs présentés précédemment : ils ne sont absolument pas graves ni dangereux pour votre projet. En effet, il est très simple de réécrire un texte ou, au pire, de refaire son script en entier. Pour ce qui est du sprite, il est très simple avec Advance Sprite Editor ou NSE de réinsérer un sprite " clean ".
En revanche, certaines fois, vous provoquerez de graves bugs, très mauvais pour votre ROM. Pour mon top personnel, j'en ai fait des belles : faire disparaître le sprite du héros, provoquer un tremblement de terre continu, un reset incessant du jeu après l'écran de démarrage, ou encore des choses beaucoup plus surprenantes comme je vous laisse les découvrir :
Dans ces cas-là, il n'y a pas vraiment de solution miracle : il faut faire des sauvegardes (backups) régulièrement. Si un tel bug survient, utilisez une ancienne sauvegarde afin de pouvoir continuer sans garder le bug provoqué.
Rapide conclusion
Bon, maintenant, vous devriez commencer à cerner le sujet et à savoir ce qu'est un offset, ainsi que son fonctionnement.Pour récapituler :
Un offset est une adresse dans votre ROM. À cette adresse sont stockées des informations telles que des messages, des images, des scripts, ou toute autre donnée du jeu. Le jeu, lorsqu'il a besoin de ces données, va les chercher à l'offset qu'on lui indique, comme dans les scripts, par exemple.Chaque donnée stockée a une taille qui lui est propre. Ainsi, si votre message fait 100 octets de longueur, le script va charger 100 octets à partir de l'offset indiqué. Vous aurez alors besoin d'un espace libre minimum de 100 octets à un offset, offset que vous pouvez trouver en utilisant un logiciel comme FSF ou bien en regardant directement dans un éditeur hexadécimal.
Si vous enregistrez des données sans leur donner l'espace dont elles ont besoin, alors vous provoquerez différents bugs, de grandeur et de gravité variables. Les plus bénins seront simples à corriger, mais certains seront beaucoup plus coriaces et embêtants : on ne le redira jamais assez, il vous faut faire des sauvegardes régulièrement afin d'éviter ce genre de problème.
Enfin, voici un petit schéma récapitulatif de ce tutoriel :
Merci de nous avoir lus, nous espérons que ce tutoriel vous aura été utile et que vous ferez moins d'erreurs concernant les offsets !
Merci de ne pas copier ce tutoriel, même partiellement, ou encore de ne prendre aucune image ou ressource sans nous en demander la permission.
Si vous avez des questions, dirigez-vous sur le topic dédié du forum.(gba)-la-gestion-des-offsets/)
Par
Myst et Mickey'**