Traduction Dragon Quest V

[taude 23]

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

[taude 23]

J12 : Décompression des sprites des textes

J'ai décidé de décompresser les sprites des textes pour ajouter un outil d'affichage de ces sprites dans mon logiciel de traduction. L'objectif initial est de pouvoir afficher l'intégralité des sprites disponibles afin de vérifier s'il y en a des non utilisés ou déjà présents dont j'aurais besoin, comme les accents. À terme, cela devrait me permettre, en implémentant la logique inverse, d'ajouter de nouveaux sprites.

J'ai essayé de comprendre l'algorithme de compression. De ce que je comprends, la valeur du caractère décompressé sert à naviguer dans une liste de valeurs qui permet d'accéder ligne par ligne au sprite, sachant que certaines lettres partagent les mêmes lignes. Comprendre l'intégralité de cet algorithme me semble être une tâche trop complexe pour mon petit cerveau, donc j'ai décidé de me concentrer sur sa réimplémention en Python. La tâche est compliquée car elle me demande de réimplémenter des logiques d'opérateurs ASM comme ROR en prenant en compte la retenue (carry). Mais en cette fin de journée, j'ai réussi à retrouver la première ligne d'un sprite de lettre à partir de sa valeur décompressée. Etape suivante: réussir a décompresser toutes les lignes des lettres qui d'ailleurs peuvent avoir une hauteur variable.

[yoda07 103]

Franchement chapeau pour tes explications, c’est vraiment intéressant. 

Bon moi je suis loin d’avoir ces compétences,  des que ces compressé dans la rom je suis coincé. Là j’essaie d’apprendre à  duper les script.

[taude 23]

Merci pour ton retour positif, Yoda. Je suis heureux que le récit te plaise. Il est également là pour laisser une trace pour tous ceux qui voudraient se lancer, afin d'éviter les erreurs que j'ai commises et que je vais commettre !

Jour 13 : Décompression des sprites utilisés dans les dialogues

Aujourd'hui, j'ai pu finaliser l'extraction des sprites. Cela m'a demandé pas mal de débogage de mon code Python et de la ROM SNES pour pouvoir complètement rétro-ingénierer l'algorithme. Le résultat, c'est que j'ai pu explorer l'ensemble des caractères affichables et apprendre à mieux connaître cet algorithme. J'ai également repéré des adresses vides, idéales pour créer mes propres sprites, et qui semblent avoir été pensées pour fonctionner avec des sprites non compressés ! J'ai donc pu faire des tests d'implémentation de nouvelles lettres, et cela semble fonctionner. Mais il y a un hic : d'une manière ou d'une autre, la taille, la hauteur et le positionnement vertical des lettres sont gérés quelque part au cours du processus, mais pour le moment, je suis passé à côté. Sans cette compréhension, je ne pourrais pas intégrer proprement les nouvelles lettres. Cela va donc être ma recherche pour les prochains jours.

  

[arcoroce 18]

Salut, je suis avec intérêt ton process. De mon côté, je suis simplement le script de reld. Je suis incapable de faire le taf décryptage que tu fais, chapeaux.

[taude 23]

Merci de ton intérêt arcoroce! j'espère que cette traduction aussi trouvera son publique!

 

Jour 14 : Injection des nouvelles lettres

Aujourd'hui, j'ai fait un grand pas en avant ! J'ai réussi à intégrer les nouvelles lettres de bout en bout. J'ai commencé à essayer de comprendre comment étaient définis la hauteur, la largeur et la ligne de flottaison des caractères. Pour cela, j'ai tenté de repérer quelle valeur était mise en WRAM et correspondait, et j'ai fini par trouver deux valeurs situées à peu près là où le texte est décompressé, qui variaient de manière logique entre les caractères en majuscules et en minuscules. En retraçant leur initialisation dans le débogueur, je me suis aperçu qu'elles provenaient de la liste des valeurs permettant de retrouver les pointeurs vers les sprites des lettres.

En expérimentant avec l'algorithme rétro-ingénieré et en essayant de comprendre comment étaient faites les informations dans la liste, j'ai fini par comprendre la "compression" des sprites et l'utilité des valeurs dans la liste : en fait, la liste se présente sous la forme de 10 octets, les trois premiers servent à associer l'élément de la liste à la valeur de la lettre décompressée, le suivant à la largeur de la lettre, les quatre suivants à déterminer l'adresse, puis les deux derniers permettent entre autres de calculer la hauteur du sprite. En expérimentant, je me suis aperçu que la hauteur sert aussi à définir la ligne de flottaison !

J'ai également compris que les sprites n'étaient pas vraiment compressés. En fait, ils sont codés avec des largeurs variables, ce qui rend leur visualisation impossible avec Tile Molester. J'ai donc pu créer les sprites des lettres accentuées, il me restait à permettre de compresser de telles lettres. J'ai donc cherché des places disponibles dans l'arbre binaire pour associer les nouvelles valeurs des lettres décompressées dans la table des valeurs de la ROM. Pour cela, toujours dans l'optique où j'ai la flemme de parcourir l'arbre binaire dans le sens inverse (j'en avais des vertiges rien que de penser à coder cet algorithme), j'ai brut forcé l'arbre d'Huffman en testant toutes les valeurs binaires de 0 à FFFF (en testant aussi toutes les combinaisons de nombre de zéros en début) et en regardant s'il y avait une valeur lorsque j'atteignais la table des valeurs, si non je récupérais la représentation binaire du chemin. J'ai trié ces chemins et gardé les plus courts pour encoder mes nouvelles lettres. J'ai ensuite modifié mon logiciel de compression/décompression pour prendre en compte ces nouvelles lettres et le tour était joué. J'ai également commencé à créer un patch IPS car, mine de rien, les modifications commencent à être suffisamment importantes pour être contraignantes à entrer à la main dans l'émulateur.

J'ai également fait un tour dans la ROM pour essayer de comprendre comment les dialogues étaient pointés, et j'ai trouvé ce qui semble être une jolie table de pointeurs ! Mais cela sera pour le prochain épisode.

[arcoroce 18]

Il y a 4 heures, taude a dit :

Merci de ton intérêt arcoroce! j'espère que cette traduction aussi trouvera son publique!

Je n'en doute pas. Courage à toi !

[taude 23]

Jour 15 : Exploitation de la table de pointeurs / Création du logiciel de traduction

Bonjour à tous,

Aujourd'hui, j'ai finalisé l'ajout de tous les caractères manquants (é, è, à, ù, â, û, ô, ê, ç) dans l'ensemble de la chaîne de texte et testé cette mise à jour sur la première séquence du jeu.

Ensuite, je me suis lancé dans l'exploitation de la table des pointeurs que j'avais repérée hier. Cette table organise les pointeurs de la manière suivante : il s'agit de groupes de 6 octets où les 21 bits de gauche décrivent l'adresse du dialogue, et les 3 bits de droite indiquent l'offset (en nombre de bits) à partir duquel le dialogue commence dans la chaîne compressée selon la méthode de Huffman.

J'ai donc développé un programme en Python qui intègre ces fonctionnalités pour naviguer dans la table des pointeurs et afficher les dialogues en les décompressant. L'idée est que nous puissions ouvrir la ROM patchée en anglais ; si le checksum correspond à la ROM adéquate, l'interface se charge. Cette interface permet alors de naviguer de dialogue en dialogue.

L'objectif final est de pouvoir modifier les conversations et mettre à jour les pointeurs dans la table en conséquence. Pour cela, j'ai créé des fonctions pour la conversion des adresses ROM (lorom/cpu) et pour générer un patch IPS.

De plus, j'ai ajouté une fonctionnalité intéressante : la possibilité de traduire automatiquement les dialogues en cours grâce à ChatGPT. J'ai mis en place un prompt qui assure que les éléments nécessaires pour le scripting des dialogues sont préservés au mieux. J'ai également ajouté un bouton permettant de traduire l'intégralité des textes et mis en place un petit système de base de données pour sauvegarder ces traductions et les modifications manuelles. Cela me permet de générer la traduction en attendant d'intégrer le système de modification des pointeurs pour créer le patch IPS.

Les prochaines étapes consisteront donc à développer cette logique pour tester une première version du jeu avec des dialogues intégralement traduits.

À suivre !

[M0nsieurL 38]

Hé bé, joli projet !

Tu vas finir par faire un éditeur de texte complet pour le jeu !
Pour ce qui est de la traduction, tu trouvera peut être des personnes pour ce genre de projet ?
Cet opus est sorti sur NDS si jamais tu veux reprendre cette "base"...

Au fait, tu connais https://problemkaputt.de/fullsnes.htm

[taude 23]

Merci pour tes encouragements @M0nsieurL.

J'ai conscience d'être peut-être le seul client pour cette traduction ! J'ai également la version DS, mais je rêve d'ajouter ce jeu mythique à ma collection SNES et de le terminer sur cette plateforme ! Si jamais je suis débordé, je tenterai peut-être de trouver de l'aide pour la traduction sur des sites de fans de DQ, sait-on jamais ?

De plus, je vois ce projet, qui me semble complexe, comme un défi et un projet pédagogique. Si j'arrive à le terminer, je me sentirai capable de traduire n'importe quel jeu. Je pourrai alors m'attaquer à des projets qui me plaisent et qui sont attendus par la communauté, comme par exemple Shadowrun !

Pour le site oui je le connais ça fait partie des ressource que j'utilise en complément de chatgpt! Mais merci pour ton aide elle est bienvenue!

 

Jour 16/17 : gestion de l'insertion des traductions, optimisation de la compression et génération du patch IPS.

Comme évoqué précédemment, je me suis attelé à l'insertion des textes en gérant la table de pointeurs. Cette tâche consistait à mettre à jour cette table en fonction du nouveau contenu traduit et à insérer ce contenu dans la ROM. Je me suis confronté à deux difficultés principales : la première était la jonction entre les différents blocs de dialogue. Étant donné que la compression est binaire, l'adresse vers un octet n'était pas suffisante. En effet, en plus de l'adresse, il est nécessaire de prendre en compte un offset qui définit la position du premier bit de la conversation dans cet octet. Je gérais déjà le bit de début, mais pas le bit de fin, qui devenait lors de l'insertion le bit de début de la conversation suivante. Après quelques itérations, je suis parvenu à modifier la table pour prendre en compte cet offset de fin. Pour information, dans la table de pointeurs, les 4 premiers bits sont destinés à cet offset, et les 20 suivants au pointeur de la conversation.

La deuxième difficulté concernait le changement de banque lors de l'insertion. Pour donner un peu de contexte, les dialogues sont stockés de manière contiguë dans des banques différentes. Je me suis beaucoup interrogé à ce sujet : fallait-il que je remplisse la fin de la banque avec le début de la conversation, qui coupait la banque, et recopier ce même début en début de banque suivante ? Ou bien traverser les banques avec la conversation ? J'ai finalement choisi cette dernière solution après quelques tests. De plus, la traduction dépassait le nombre de banques prévu initialement. J'ai donc scanné la ROM dans l'espoir de trouver des banques vides (et il y en avait) et ajouté la logique de remplissage de ces banques si nécessaire. Néanmoins, cela ne me convenait pas, car je me suis aperçu que j'avais besoin de trois banques supplémentaires pour insérer toute la traduction. J'ai donc eu une idée : optimiser l'arbre de Huffman en fonction de la traduction du jeu. C'est-à-dire compter le nombre réel de caractères dans la traduction et choisir, pour les lettres/éléments de script les plus utilisés, les chemins les plus courts dans l'arbre afin d'obtenir une représentation binaire des éléments la plus courte possible. Là aussi, je me suis confronté à plusieurs difficultés. Mon idée première était de substituer directement les valeurs dans la table des valeurs, ce que j'ai fait avant de me rendre compte que ces valeurs étaient directement liées à la manière de récupérer les informations de sprite. Cela m'aurait donc obligé à modifier la table des sprites et leurs informations associées, ce qui me semblait trop fastidieux. Je suis donc revenu en arrière et ai décidé de conserver la valeur cible des éléments, mais de changer directement l'adresse pointée de ces éléments dans l'arbre de Huffman. Après quelques itérations, j'ai réussi à intégrer cette logique.

Enfin, au cours de mes tests, je suis tombé sur les phases de combat dont les textes n'étaient pas présents dans les dialogues que j'extrayais. Et cela est normal : ils utilisent les sprites de lettres des menus, et donc les valeurs compressées ainsi que la table des pointeurs ne sont pas les mêmes. Je me suis contenté de faire du repérage pour identifier où se situaient ces tables et ces dialogues, et j'ai décidé de remettre cela à plus tard.

En conclusion, j'ai avancé ma traduction jusqu'au manoir des Lenoir et finalisé la logique d'injection des textes ainsi que la production du patch IPS (avec la modification de l'arbre d'Huffman mes nouveaux sprites ect..). Mon prochain objectif est d'ajouter des éléments de vérification et de correction algorithmique de la traduction afin de pouvoir automatiser la traduction et de m'assurer de pouvoir livrer rapidement un patch complet sans bug.

[M0nsieurL 38]

C'est bien normal, tu t'attaques à une série que j'affectionne particulièrement.
Une fois finalisée et si tu la rend publique, ta traduction trônera dans ma petite collection (et même si je n'ai plus le temps de jouer, je demanderai à mon petit gars de se faire ce RPG légendaire, il a 9 ans).
Si tu as le temps, tu pourrais coder un petit quelque chose pour les déterminants ? (Quand on trouve un objet), enfin c'est peut être stupéfatoire, mais toujours sympathique, plutôt qu'un "Vous trouvez : Feuille D'Yggdrasil".
"Vous trouvez une Feuille d'Yggdrasil"

Hiei- s'était attaqué à la traduction de ce jeu il me semble, il y a des années, je ne sais pas s'il lui reste des choses ou si ma mémoire me fait défaut.

Shadowrun ?? J'ai un script traduit (grossièrement tout de même) qui traîne depuis au moins 10 ans dans mes archives... Peut être plus tard !

[taude 23]

Jours 18 à 25 : restauration des sprites japonais pour la version française de SoulBlazer, première démo de Dragon Quest 5

Ces derniers jours ont été consacrés à la restauration des sprites de la version japonaise de SoulBlazer pour la version française. En effet, à la fin du jeu, le personnage de Lisa a été redessiné : ses bras en position de prière ont été supprimés, et sa bouche ainsi que ses yeux ont été redessinés. J'ai donc commencé à fouiller la ROM et à déboguer afin de trouver où se situaient les données et les instructions impliquées. J'ai finalement localisé les sprites, mais ceux-ci étaient compressés. En examinant l'OAM (Object Attribute Memory), je me suis aussi rendu compte que les zones correspondant à la bouche n'étaient pas délimitées de la même manière que dans la version japonaise.

En effectuant quelques recherches sur Internet, j'ai découvert un outil très utile : SNES Tiles Kitten, qui permet d'afficher, décompresser et réinjecter directement des sprites. Cerise sur le gâteau, cet outil gère la compression propre aux jeux Quintet ! J'ai donc rapidement pu reconstituer les sprites nécessaires en migrant les parties du sprite japonais (yeux et bouche) pour correspondre à l'arrangement des sprites français. Une agréable surprise : les mains étaient bien présentes dans les sprites de la version française.

Lors de mes recherches précédentes, j'avais identifié la routine qui gérait le chargement des sprites dans l'OAM, mais sans savoir exactement quel sprite était concerné. Cependant, j'avais découvert que cette partie du code déterminait la position des sprites dans le fond d'écran. J'ai donc repris mes essais dans cette zone, espérant réinjecter les bras supprimés. J'étais quelque peu découragé, car ces bras étaient composés de 10 tuiles, et je me disais que réécrire une routine de chargement et d'animation des bras dépassait mes compétences. En poursuivant mes tests, j'ai compris qu'une adresse, dans la routine qui gère la position des tuiles, menait à une sous-routine, et que celle-ci lisait une zone de mémoire spécifique.

En expérimentant sur cette zone, j'ai découvert qu'elle correspondait à un identifiant qui permettait de charger l'ensemble des sprites d'un élément (bouche, yeux). En modifiant cet identifiant, j'ai pu réinjecter les bras en entier et identifier l'ID "7" qui correspondait aux bras ! J'étais soulagé de ne pas avoir à réécrire tout le code de chargement des tuiles. Cependant, un problème demeurait : l'instruction qui charge les yeux et celle qui charge la bouche se suivaient, ainsi que toutes les autres instructions qui gèrent cette scène. Je me demandais donc comment insérer l'instruction pour positionner les bras.

En analysant le code, j'ai découvert une routine existante avec l'indice "7", et encore mieux, grâce au débogueur, j'ai constaté que cette zone de code n'était pas utilisée. En redirigeant l'instruction des yeux vers cette sous-routine, cela a permis d'afficher les bras, mais l'animation bloquait la scène. Après de nouveaux essais, j'ai découvert qu'un octet permettait de définir le moment de déclenchement de l'animation, et j'ai réalisé que l'animation était complète ! Quelle chance !

Il me restait cependant un problème à résoudre : rajouter les tuiles sans remplacer celles des yeux. J'ai donc recréé l'instruction d'ajout des bras et l'ai insérée à la fin de celles qui chargent les yeux et la bouche, ce qui ajoutait 11 octets. Cela a décalé le reste du code vers une instruction d'animation inutilisée, longue d'une vingtaine d'octets. J'ai alors déplacé cette instruction dans une zone vide et mis à jour l'adresse dans l'instruction de chargement des bras. J'ai ensuite modifié toutes les adresses des instructions suivantes en y ajoutant ces 11 octets, et tout a fonctionné !

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Pour Dragon Quest, je me suis confronté à l'immense tâche de traduire le jeu. Au-delà de l'aspect technique, le script contient plus de 85 000 mots ! J'ai donc accepté l'idée d'avoir besoin d'aide et j'ai modifié l'outil que j'avais créé pour exporter tout le script du jeu, ainsi que pour réinjecter les parties traduites. Il gère désormais les conflits de traduction avec un système de verrouillage des parties validées. J'ai également ajouté des fonctionnalités tel que la recherche et le remplacement. Une fois cet outil en place, mon frère est venu me donner un coup de main, et nous avons pu avancer sur la traduction des dialogues du jeu, que je vous propose aujourd'hui en démo. À ce jour, environ 15 % des dialogues sont traduits.

Vous trouverez ici un patch IPS à appliquer sur une version sans header, ainsi que les scripts du jeu.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Pour la suite, je prévois d'aider à la traduction des scènes entre les niveaux de Go Go Ackman 3, mais ce sera pour un prochain épisode !

Dq5-eng-sh.ips raw_text-v3.txt trad_text-v3.txt

[M0nsieurL 38]

Beau boulot !

Quelle rom doit-on patcher ? (quel est son CRC ?)

Je ne parviens pas à télécharger les scripts, j'aurais bien aimé y jeter un œil (Ichigo, j'ai un échec de connexion sécurisé).

Si seulement j'avais le temps :'( La série des dragon quest est une série que j'affectionne particulièrement et cet opus était génial).

[taude 23]

Bonjour MonsieurL et merci pour ton intérêt ça me motive vraiment!

Je serais très heureux de pouvoir te permettre de procéder ce merveilleux jeux dans ta collection!

j'ai tout reposter sur wetransfert même la rom:

https://we.tl/t-FbNUO5O4pn

le md5 que je calcul et que j'utilise dans mon éditeur d'ailleurs c'est:
e191589ab9f6d9b89411815202885b3f

c'est pas évident pour la rom:
c'est la rom japonaise patché en anglais et sans header

[arcoroce 18]

Beau boulot en tous cas !

[M0nsieurL 38]

Merci beaucoup, je vais tâcher de me dégager du temps ce dimanche pour tester (j'ai regardé un peu le script, c'est pas super clair avec les [end_bloc 900A] Je pense que cela gagnerait en compréhension avec un code du type [objet 900A].

Après j'ai traduit quelques jeux par le passé, j'ai juste du mal avec les traductions "automatiques"... (Certaines tournures sont trop littérales à mon goût) Il me semble que Generation IX avait fait un patch avec le google traduction de l'époque (c'était avant 2010) pour FF6 sur snes... Bah c'était de la merde :D

Effectivement pour la rom, c'est un peu le bordel à trouver... Il faudra penser à faire le patch avec la rom no-intro japonaise je pense (et créditer les auteurs de la version anglaise quand tu diffuseras, enfin si tu le fait).

[taude 23]

Bonjour MonsieurL, et encore merci pour ton intérêt.

En effet, les balises ne sont pas claires, je vais essayer de corriger cela ! De même, pour la version de base sur laquelle appliquer le patch, je partirai de la version japonaise.

Je créditerai bien évidemment l’équipe de traduction anglaise et publierai mon travail dans son intégralité.

Concernant la traduction automatique, elle me sert uniquement de "base". Je repasse ensuite sur tout le jeu pour faire une traduction manuelle (j'ai déjà retraduit environ 15 % du jeu).

Le tout début (la scène d'intro), j'ai un script que j'avais refait à la main que je vais remigrer dans la version en cours. Si la traduction te semble trop mécanique jusqu'au monde des fées, c'est que j'ai mal fait mon travail et donc n'hésites pas à me faire des retours.

Je vais m'atteler à corriger tout cela pour la prochaine mise à jour !

[M0nsieurL 38]

J'ai eu un bug sous zsnes (bon je sais que ce n'est pas le meilleur émulateur, mais tout de même).
Quelques passages me chagrinent dans la traduction, mais je pense que tu y remédieras plus tard.

Il va falloir gérer les noms des héros selon leurs longueur, sinon ce genre de chose sera courante.
Une solution de "facilité" serait de prendre à défaut 8 largeur de caractères pour les noms, mais ce ne sera pas "esthétique".

Bon , je retourne bosser un peu... pour changer

[chomel 59]

Roooohhhh... tu vas pas nous faire croire que quand on est instit, on bosse le weekend et le soir et pendant les petites vacances...

[M0nsieurL 38]

Non, bien évidemment.
Je me demande pourquoi tant d'enseignants quittent le navire pour faire autre chose.
C'est incompréhensible, nous avons les vacances pourtant et des salaires mirobolants ! (Bon je gagnais plus quand j'avais 20 ans, mais passons)...
C'est peut-être la charge mentale monstrueuse et les conditions de travail qui font que nous avons perdu des milliers de collègues et de prétendant(e)s aux postes de professeur(e)s ?
J'ai quand même eu le temps de jouer un peu à DQV !
Bon dimanche soir, je m'en vais préparer mes cahiers

[chomel 59]

Punaise t'es mieux organisé que moi, depuis la rentrée j'ai rien touché en terme de JV, si ce n'est me balader sur le forum. Mais bon j'essaie de pas trop me plaindre parce qu'au final, il y a plein d'autres métiers avec des contraintes. C'est surtout l'image qu'on peut nous renvoyer qui agace. La semaine, lors d'une réunion de rentrée, y a 2 collègues qui se sont fait gueuler dessus violemment par un père d'élève parce qu'en EPS, elles avaient un projet rando avec un séjour de 2 jours avec nuitée et que pour le gars, c'était encore une excuse pour pas bosser. Et le tout devant des enfants de la classe et la gamine d'une des enseignantes. Le gars a dû se faire recadrer par l'inspectrice. Mais bon ça doit aussi arriver dans d'autres métiers. De toute façon, le jour où j'en pourrai plus, je changerai aussi. Pour l'instant ça va. 

Pour en revenir au sujet, une question que je me suis toujours posée sur les DQ. Y a pas moyen de changer un peu la fenêtre de dialogue? J'ai toujours trouvé ce gris un peu moche.

En tout cas, bonne continuation pour cette aventure. Je trouve que ces derniers sujets de trad ouverts sur le forum redonnent un peu de souffle à UC.

 

Bon, je retourne bosser.