Aller au contenu

Classement


Contenu populaire

Affichage du contenu avec la meilleure réputation le 02/09/2024 dans Messages

  1. 1 point
    Bonjour, j'ouvre ce post pour tenir un journal, partager mes avancées et difficultés, mes réussites, sollicité de l'aide et recueillir vos retours sur le projet que je me suis lancer de traduire dragon quest V sur snes. Je vais commencer par faire une rétrospective des premiers jours pour revenir dans le présent par ailleur. Jour 1 recherche d'outil mise en pratique de la technique de la recherche relative: J'ai pris le temps de me documenter sur TRAF et d'essayer de comprendre les outils et techniques nécessaires pour traduire une ROM. Je découvre comment patcher une ROM à l'aide d'un fichier IPS et d'un patcher, ce qui m'est utile pour convertir ma ROM de Dragon Quest V en anglais. Je conclus ensuite qu'il me faudrait un logiciel capable de faire de la recherche relative, de créer des tables de conversion, d'ouvrir la ROM pour l'afficher en hexadécimal et de traduire les valeurs hexadécimales en texte. Le programme Olympus de Lyssal regroupe tous ces aspects. Je lance le jeu et cherche, grâce à Olympus, les textes qui composent les menus et les trouve. Victoire ! J'arrive même à modifier le texte du menu en changeant les valeurs hexadécimales ! Mais pour trouver les textes du jeu, je dois compléter ma table de conversion. Je comprends que les hexadécimaux qui constituent la table sont en fait les adresses des sprites des lettres, et je m'équipe donc d'un logiciel qui permet de visualiser les sprites d'une ROM (Tile Molester). Après plusieurs itérations, je trouve les sprites qui sont en 1bpp (1 couche de couleurs). Je retourne sur Olympus, crée ma table, lance le jeu, et recherche les premières lignes de dialogues dans la ROM, mais là, je ne trouve rien. Jour 2 : Débogage Je relance mon apprentissage avec des tutoriels et apprends que si je ne peux pas voir le texte, c'est probablement parce qu'il est compressé. Je commence à m'inquiéter car les méthodes de décompression semblent très complexes et j'ai besoin de savoir quel type de compression est utilisé. Je tente de rechercher des bouts de phrases et des syllabes grâce à ma table, je navigue dans toute la ROM et ne trouve rien de concluant. Je me dis que le patch IPS doit bien modifier les textes, ce qui devrait me permettre de mieux comprendre comment ce texte est constitué. Je trouve l'outil IPS Peek, je regarde ce qui est modifié en grande quantité et rien ne semble avoir de sens. Je décide donc de lancer le jeu en mode débogage et d'essayer de comprendre quelle est la routine d'écriture du texte. Je finis par utiliser Bsnes-plus et j'arrive à m'arrêter, plus ou moins au moment où le texte est écrit. Mais là, je me heurte à mes limites de connaissance en ASM et je n'arrive à rien. Jour 3-6 : Apprentissage de l'ASM SNES et ChatGPT Je passe ces jours à essayer de trouver des points d'arrêt en remontant la stack trace qui me permettent de m'arrêter uniquement une seule fois avant que le texte ne s'affiche et juste après que les premières lettres s'affichent. Grâce à la stack trace, je trouve un endroit qui semble être une bonne entrée et finis par voir que le dialogue s'écrit en VRAM avant d'être affiché, et je pose un breakpoint au moment où cet endroit en VRAM est écrit. Je commence alors un long et fastidieux travail qui consiste à essayer de comprendre, étape par étape, ce que fait le code. Je demande à ChatGPT l'utilité de tel opcode, de tel registre, je me renseigne sur le hardware de la SNES. Je n'avance pas sur mon problème, mais j'ai appris beaucoup de choses ! Par exemple, ce qu'est le DMA et comment cela fonctionne. Je me fais des tableaux avec les opcodes et leurs fonctionnalités. ChatGPT m'aide réellement, car au lieu d'avoir une simple phrase d'explication pour l'opcode, je peux lui poser des questions de base et il m'aide à élargir mes recherches dans les documentations, me permettant de mieux saisir le contexte. Jour 7 : Tournant crucial avec le dump de mémoire et l'éditeur hexadécimal Content de mes nouvelles compétences, je réalise que je n'avance pas sur le fond du problème. Je me remets en question et décide de tenter une nouvelle approche. Je fais un dump de la WRAM avant et après les breakpoints que j'avais définis, puis je fais une comparaison avec HxD. Je finis par identifier une zone de la RAM autour de $E00 qui semble avoir changé de manière suspecte. Je relance la ROM, édite cette zone avant que l'écriture n'apparaisse et, bingo, le texte affiché change. Je pose un breakpoint sur l'écriture de cette zone et je suis sûr que ce qui aboutit à cette écriture est bien le processus de décompression. Je remonte la stack, lis le code et ne comprends rien... Jour 8 : Passage à Mesen-S et l'algorithme de compression Ce qui me bloque, c'est que je ne comprends pas pourquoi, à partir d'une zone de la ROM, un octet est lu avec des masques successifs de 01, puis 02, puis 04, et en fonction du résultat obtenu, il va chercher un octet dans une autre partie de la ROM, et parfois soit continue de chercher dans cette partie en changeant le masque, soit va chercher un octet dans une zone différente de la ROM pour l'afficher. Je pense avoir affaire à un algorithme de type LZ. Mais en comparant avec des tutoriels, je ne comprends toujours pas comment le texte est compressé. Je change d'émulateur pour Mesen-S et me sens plus à l'aise avec son debugger. Jour 9 : Compréhension de l'algorithme de décompression Après une bonne nuit de sommeil, je comprends que l'algorithme se base sur un arbre binaire. En fonction de la valeur binaire de la première zone examinée, si c'est 1, on va à droite, si c'est 0, à gauche. En fonction de la valeur trouvée dans l'arbre, il sait s'il doit continuer à naviguer dans l'arbre ou s'il doit aller chercher la valeur. Dans l'arbre, il récupère 4 octets : les deux derniers déterminent s'il doit s'arrêter (8x 1000 ****) ou continuer (0x 0000 ****), et dans tous les cas, les deux autres octets sont des adresses, soit pour l'arbre binaire, soit pour la table des valeurs. Jour 10-11 : Création de l'outil de compression/décompression du texte Je me lance donc dans un code Python aider par chatGPT et crée une interface qui permet de décompresser le texte, ce que j'arrive à faire assez rapidement en dumpant les éléments nécessaires de la ROM, comme l'arbre binaire et la table des valeurs. J'arrive à traduire les valeurs trouvées en lettres en injectant des valeurs dans le jeu grâce à mes découvertes précédentes. Je finis par traduire les éléments récupérés dans le patch via IPS Peek, ce qui me permet de rajouter encore des éléments dans la table de conversion en lettres. Je découvre aussi qu'il y a des valeurs dans l'arbre qui finissent par 9x et conclus que ce sont des éléments qui contrôlent l'affichage du texte (fin de phrase, attente d'entrée du joueur, etc.). J'obtiens une bonne décompression et décide de me lancer dans la compression. Pour ce faire, j'ai la flemme d'intégrer la logique inverse qui me demanderait de parcourir l'arbre dans les deux sens inverse et de prendre le plus court chemin vers la racine. J'ai donc l'idée de construire une table à partir des éléments de décompression : dès que je décompresse une valeur, je stocke la lettre et la valeur binaire et je me servirais de cette table pour compresser le texte. Ceci fait, j'ai un outil qui me permet de compresser et décompresser le texte et j'arrive à injecter le texte français de toute la première scène. Mais je ne suis pas satisfait : 1) j'aimerais ajouter les accents absents à priori 2) je me dis que si je ne comprends pas exactement comment sont pointés les dialogues, je vais me retrouver avec des problèmes par la suite où le texte affiché ne sera plus le bon. A bientôt pour la suite qui sera en direct et merci de m'avoir lue ;p
×
×
  • Créer...