Ligne 3 (00:0003) : elle contient des virgules sans guillemets (« Et vous, comment vous appelez-vous ? »), ce qui décalait toutes les colonnes. Le script recolle maintenant ces champs. Je vous conseille quand même de mettre ce texte entre guillemets dans le CSV.
Les accents ne passent pas. L’arbre de Huffman du jeu ne contient que de l’ASCII, car les octets à partir de 0x80 sont réservés au dictionnaire. Aucun é, è, à, ê, ù, ’ ni … ne peut donc être écrit tel quel. Par défaut, le script les remplace par leur équivalent ASCII (é devient e, ’ devient ‘, … devient ...) et affiche le décompte des remplacements. Le résultat donne par exemple « Bon sang ! Mais qui etes-vous donc ? ». Avec --accents=error, il s’arrête au premier caractère non supporté. Pour de vrais accents, il faudrait savoir quelle police le jeu utilise, puis étendre le dictionnaire ou l’arbre

Je viens d’analyser vos polices : elles ne couvrent que les caractères 0x21 à 0x7F, donc aucun accent. Je teste maintenant la piste suivante : dessiner les accents dans des emplacements ASCII inutilisés par le jeu, puis reconstruire l’arbre de Huffman pour les encoder. Je termine l’analyse du format des polices.

Point d’étape : les polices 1 bit sont lues et réécrites à l’identique. Mon générateur d’accents fonctionne sur 4 d’entre elles. Pour les deux petites polices 5 px (DGATE010 et 013), il n’y a pas de place au-dessus des minuscules : j’adapte le dessin des accents. Ensuite je reconstruis l’arbre de Huffman dans le script de réinsertion et je vérifie le rendu.

J’ai les accents français sur le papier : une version du script de réinsertion qui les encode et 8 polices patchées. Rien n’a été testé dans le jeu, car je n’ai pas l’exécutable. Les 8 polices patchées et le DAT de test sont dans l’archive ; l’image jointe montre le rendu des accents.

Ce que contiennent vos polices. Elles ne couvrent que les caractères 0x21 à 0x7F, donc aucun accent. Étendre le dictionnaire ne sert à rien : ses jetons ne font que produire des octets que la police doit pouvoir afficher.

La solution que j’ai retenue.

• Emplacements réutilisés : le texte anglais n’utilise jamais # & * + = @ ^ \ { | } ~, qui n'ont même pas de code dans l'arbre de Huffman. J'ai remplacé leurs glyphes par é è ê à â ç ù û î ô ë ï dans les polices (table dans fr_charmap.py`).
• Arbre de Huffman étendu : le script reconstruit l’arbre avec ces 12 octets et recode tous les enregistrements. L’arbre passe de 214 à 226 symboles, avec la même profondeur maximale de 18.
• Vérification : chaque chaîne est relue après encodage. Les 5 444 enregistrements non traduits se redécodent à l’identique, et les 6 premiers contiennent bien les accents.
• Polices : patch_fonts.py dessine les accents dans les 8 polices 1 bit. Le rendu est correct sur les 8, y compris les deux petites polices 5 px, où l’accent tient sur un seul pixel.

Limites à connaître.

• Polices 8 bits : DGATE015, 016 et 017 sont des polices couleur dont je n’ai pas déchiffré le format ; je les ai laissées intactes. Si l’une d’elles sert aux dialogues, les accents y seront faux.
• Majuscules et ligatures : les majuscules accentuées perdent leur accent (É devient E), faute de place au-dessus. œ devient oe, « » deviennent “, ’ devient ‘ et … devient ...
• Caractères réservés : un # & * + = @ ^ \ { | } ~` tapé tel quel dans le CSV déclenche une erreur, puisque ces octets affichent désormais des accents.
• Extraction : si vous réextrayez le DAT avec extraer_DGATESTR.py, les accents apparaissent sous forme de ces symboles (par exemple } pour ê), pas de lettres accentuées.
• Risque moteur : l’arbre fait désormais 12 mots de plus. Je n’ai pas pu vérifier que le moteur du jeu l’accepte.