taude

je fait aussi les stickers avec de la lamination + papier mat à pas chère je reviendrais sur ce sujet en ce qui concerne les crystal cases voici le tuto manuel et petite précision si vous n'avais pas de lamineuse il y en a en accès libre chez bureau vallée : et les modèles: Contour-SNES.fcm Contour-NES-02.svg Contour-SMS-A.fcm Contour-SMS-A.svg Contour-NES.fcm Contour-N64.svg Contour-N64.fcm Contour-GENESIS-Norm.svg Contour-GENESIS-Norm.fcm Contour-GENESIS-EA.svg Contour-GENESIS-EA.fcm Coutour-SNES.svg Plis-GENESIS-EA.fcm Plis-GENESIS-EA.svg Plis-GENESIS-Norm.fcm Plis-GENESIS-Norm.SVG Plis-N64.fcm Plis-N64.svg Plis-NES.fcm Plis-NES.svg Plis-SMS.fcm Plis-SMS.svg Plis-SNES.fcm Plis-SNES.svg

ca marche aussi sans! je vous post une vidéo complémentaire pour ça!

Je fais un petit tour de nettoyage des templates et je vous partage tout ce que j'ai ! J'en ai pour la SNES, NES, N64, Master System et différents formats de Mega Drive.

Voici mon tout premier tutoriel pour vous présenter mon processus de création de crystal cases. Le prix de ces boîtes est de 12 centimes l'unité, correspondant au coût des feuilles de plastification, et elles vous permettront d'obtenir des boîtes de protection pour toutes les tailles de cartouches (n'est-ce pas Micromachines sur Megadrive ?). J'espère que cela vous plaira ! Je publierai d'autres tutoriels dans ce style, par exemple pour adapter ce processus à la création de mini-boîtes plastifiées à l'image des jeux. Le résultat: Le tuto:

Après un simple commutateur HDMI fait le travail vu que la seul console qui me reste en scart constamment branché c'est le slot MVS consolisé!

Imagine un instant : un RPG en 3D à la première personne sur une console 8 bits. Oui, tu as bien lu. Dès que j'ai découvert ce jeu, j'ai été bluffé. Elite sur NES, c’est le genre de titre qui te fait te demander comment un tel exploit est possible sur une console aussi limitée. Pourtant, il est là, avec un univers gigantesque, des combats spatiaux, du commerce, et une liberté totale d’exploration. L’adaptation NES de Elite, exclusivement sortie sur les consoles PAL avec des textes en français, propose une expérience unique. Dans ce jeu, tu commences aux commandes d’un simple vaisseau spatial et tu peux choisir ta voie : commercer de planète en planète pour gagner des crédits, traquer des pirates pour devenir un chasseur de primes redouté, ou même basculer du côté obscur et te lancer dans la piraterie spatiale. Chaque système solaire a ses particularités, avec des marchandises qui fluctuent en fonction de l'offre et la demande. L'univers est généré de manière procédurale, ce qui te donne l’impression que l’exploration est infinie. Le gameplay est étonnamment varié pour un jeu NES. Tu dois gérer les ressources de ton vaisseau, t’assurer que tu as suffisamment de carburant pour tes voyages, et être prêt à te défendre contre des ennemis à tout moment. Les combats se déroulent en 3D fil de fer, avec une vraie sensation d’immersion, ce qui est impressionnant pour l'époque. Chaque victoire en combat spatial te donne l’occasion d’améliorer ton vaisseau avec des armes plus puissantes, des boucliers renforcés, ou même des propulseurs plus rapides. La jouabilité est incroyablement fluide, surtout pour un jeu de cette envergure avec seulement deux boutons. Le bouton B permet de naviguer facilement dans les menus constamment affichés à l'écran, mais aussi de gérer la vitesse du vaisseau en accélérant ou en décélérant. Le bouton A, quant à lui, est utilisé pour tirer. Ce qui impressionne vraiment, c'est à quel point les déplacements du vaisseau sont précis et contrôlables, offrant une véritable sensation de maîtrise dans l’espace, malgré la simplicité des commandes. Un autre aspect qui rend cette version unique, c’est la possibilité de jouer à deux. Le mode deux joueurs te permet de partager l’aventure avec un ami qui sera ton copilote! Je ai découvert récemment cet adaptation, et ce jeu m’a vraiment fait réfléchir. Elite sur NES, à lui seul, représente tout ce qu’est la programmation à mes yeux : la capacité de créer un univers entier, de repousser les limites du possible, et tout ça dans une simple petite cartouche. C’est fascinant de voir comment, avec si peu de moyens, les développeurs ont réussi à faire entrer quelque chose d’aussi vaste et complexe sur une console aussi modeste que la NES. Ce jeu est la preuve que, même avec des ressources limitées, la créativité et la maîtrise technique peuvent donner vie à des mondes incroyables. J'ai récemment acquis ce jeu pour 30 euros, et à ce prix-là, je trouve que c'est donné !

Merci @chomel pour ta réponse! En ce qui concerne l'aspect collectionnite, j'essaie de me restreindre, mais ce n'est pas évident. Je suis encore en phase d'acquisition, mais je dirais que j'ai en moyenne 30 jeux par console, sauf pour la SNES et l'ensemble DS/3DS, où je suis plus autour des 80 jeux. Pour la Saturn, la Neo Geo Pocket et la Master System, je possède 2 ou 3 jeux chacune. Concernant le "setup" : j'essaie autant que possible de passer par l'HDMI pour des raisons de commodité. Je suis notamment très satisfait des adaptateurs Kaico, qui ont l'avantage d'être passifs dans la majorité des cas. Seul celui de la PS2, s'alimente directement via le port USB de celle-ci, mais a l'avantage de transmettre le signal en YUV, ce qui permet d'afficher les jeux PS1. Pour les consoles où je n'ai pas le choix, j'utilise un adaptateur péritel-HDMI, qui a l'avantage de faire passer ma NES, et qui est normalement branché à ma Neo Geo MVS. l'adaptateur scart/hdmi bon marché qui me conviens bien:

Bonjour à tous ! À travers ce post, je vais vous présenter ma ludothèque ! Je tiens à ce terme car, d'une part, je souhaite limiter mes acquisitions de jeux en effectuant une véritable curation, et d'autre part, les jeux doivent toujours être accessibles et prêts à être joués : pas de vitrines, et le moins de jeux en boîte possible. Mon objectif est de pouvoir présenter un véritable musée du jeu vidéo à mon neveu, qui a actuellement 9 ans. Je me fixe également une limite de 100 jeux maximum par plateforme. Cette ludothèque n'est pas réellement une possession personnelle, elle est perçue comme une propriété commune à ma fratrie, regroupée sous le nom de "La Fraternelle de la Cartouche" ! Je vais commencer par vous partager une photo des consoles, toujours prêtes à l'emploi :

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.

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 !

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.

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.

Merci à tous pour votre accueil chaleureux! n'hésitez pas à faire un tour sur : pour suivre mes avancements sur le projet de Traduction!

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.

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