Traduction d'Utima Underworld II

[Sylvain_rocher]

Après une semaine dessus, j'ai ENFIN réussi à finir proprement la traduction du menu principal. Il était vraiment très très galère, beaucoup moins facile que pour Underworld 1. Sur un point en particulier, et c'est plutôt étonnant.

En fait, le jeu affiche d'abord une image sur laquelle il superpose 4 petites images contenant les textes qu'on voit. Or, et à la différence de Underworld 1, et bien l'arrière-plan de ces 4 imagettes avec le texte sont décalés de plusieurs pixels par rapport à l'image d'origine, et c'est déjà vrai dans la VO (on peut le voir facile quand on tape sur "Journey Onward", si on fait attention, on voit que les pixels changent). Bref, avec la traduction, ça m'a sauté aux yeux et je me suis bien bien fait ch**** pour corriger cela et être pixel perfect

[Sylvain_rocher]

Immense joie dans mon train Paris-Bordeaux : j'arrive à reconstruire le fichier d'origine !!!! Ci-dessous la carte traduite.

Pour les curieux, j'ai rusé car je suis fainéant ... en commençant à implémenter un algo de compression, je me suis rendu compte que ça allait être long, galère et que j'avais pas envie. Donc plutôt que recompresser les données, j'ai plutôt dit au jeu d'arrêter d'utiliser son algorithme de décompression pour lire les données, et le forcer à les lire brut de fonderie ! Et ça a fonctionné ! Alors oui, les nouvelles données font 600ko au lieu de 170ko, mais bon, en 2025, who cares ?

[Sylvain_rocher]

Nouvelles du matin : j’ai réussi à décompresser le fichier c’est bon ! Le code récupéré avait des bugs pour la décompression des images (c’était indiqué dans le readme, il ne marchait bien que pour la décompression des conversations). Mais du coup ça m’a aidé à mieux comprendre l’algo : je confirme qu’avec juste le texte que je vous ai cité, j’aurais jamais trouvé …

Bref, c’est une bonne nouvelle pour la traduction, mais j’ai fait que la moitié du chemin : il faut que je code l’algo de compression maintenant

[Sylvain_rocher]

J'ai eu un coup de bol ce matin : j'ai trouvé sur le net un bout de code en C++ qui a l'air de décoder le fichier. Ca devrait pouvoir m'aider.

[Sylvain_rocher]

Ce programme, c'est seulement pour les fichiers exécutables (*.exe).

Ok, alors je confirme qu'il ne pourra rien faire pour moi sur ce sujet

[Ulyssom]

Ce programme, c'est seulement pour les fichiers exécutables (*.exe).

[Sylvain_rocher]

As-tu penser utiliser : Translator++_1.3.22 ou Translator++_6.4.11_x64_[dbadfa8b] ?
Voici quelques liens pour télécharger ces deux versions :
1) Translator++ - Game Translation Tool | RPG Maker Forums
2) Home – Dreamsavior
3) Getting started Translator++: Get the Latest version
4) translator++ tutorial - YouTube

Bonne chance pour la suite, car cela ne semble pas facile de jongler avec les nombreux offset et cies.

Je ne connaissais pas cet outil. De ce que j’ai lu sur leur page et dans les vidéos, je ne vois pas comment il serait capable de décompresser des données par un algorithme maison… d’autant que ces données ne contiennent pas de textes puisque ce sont des images.

Mais qui ne tente rien comme on dit !

[Ulyssom]

As-tu penser utiliser : Translator++_1.3.22 ou Translator++_6.4.11_x64_[dbadfa8b] ?
Voici quelques liens pour télécharger ces deux versions :
1) Translator++ - Game Translation Tool | RPG Maker Forums
2) Home – Dreamsavior
3) Getting started Translator++: Get the Latest version
4) translator++ tutorial - YouTube

Bonne chance pour la suite, car cela ne semble pas facile de jongler avec les nombreux offset et cies.

[Sylvain_rocher]

Bonjour à tous,

Je requière votre aide, j'ai un soucis sur la lecture de certaines images du jeu à traduire : le format a changé depuis Underworld 1.

J'ai un fichier (BYT.ARK) qui contient les images qui m'intéressent : il a un header qui donne le nombre d'images, leur adresse et leur taille. Les données sont compressées, et un algo permet de retrouver les données d'origine. Les seules infos que j'ai pu trouver sur la manière dont sont compressées les images sont celles-ci, en anglais (il faut comprendre qu'un "block" correspond à une image dans le fichier, et ils sont tous compressés) :

A compressed block always starts with an Int32 value that is to be ignored.
If a block is actually compressed, it can be divided into subblocks.
Each compressed subblock starts with an Int8 number; the bits from LSB to
MSB describe if the following byte is just transferred to the target buffer
(bit set) or if we have a copy record (bit cleared). After 8 bytes or copy
record, the next subblock begins with an Int8 again.

The copy record starts with two Int8's:
0000 Int8 0..7: position, bits 0..7
0001 Int8 0..3: copy count
4..7: position, bits 8..11

The copy count is 4 bits long and an offset of 3 is added to it. The
position has 12 bits (accessing the last 4k bytes) and an offset of 18 is
added. The sign bit is bit 11 and should be treated appropriate. As the
position field refers to a position in the current 4k segment, pointers
have to be adjusted, too. Then "copy count" bytes are copied from the
relative "position" to the current one.

Dans mon cas, sur la première image qui commence à l'adresse 0xB6 :

A compressed block always starts with an Int32 value that is to be ignored.

C'est la valeur 0x00FA0000 qu'on retrouve en début de chaque image/block (en bleu dans ma capture) : tout va bien jusque là.

Each compressed subblock starts with an Int8 number; the bits from LSB to
MSB describe if the following byte is just transferred to the target buffer
(bit set) or if we have a copy record (bit cleared).

Le premier octet du sous bloc a la valeur 0x01 (en rouge dans ma capture), donc en binaire, du LSB (Lesser Significant Bit) au MSB, ça fait bien 1 0 0 0 0 0 0 0.
Le 1er bit est à 1, donc l'octet qui suit (0x03, en orange) est à prendre directement en tant que premier pixel de l'image (le target buffer, c'est l'image à terminaison).
Pour la suite, il faut réaliser une "copy record". Donc j'applique ce qui est indiqué :

The copy record starts with two Int8's:
0000 Int8 0..7: position, bits 0..7
0001 Int8 0..3: copy count
4..7: position, bits 8..11

The copy count is 4 bits long and an offset of 3 is added to it. The
position has 12 bits (accessing the last 4k bytes) and an offset of 18 is
added. The sign bit is bit 11 and should be treated appropriate.

Le premier octet vaut 0xEE=1110 1110 (en vert), le second 0xFF=1111 1111 (en jaune).
Donc "copy count", c'est les 4 premiers bits de FF plus 3, soit : 15 + 3 = 18
La position vaut en binaire 1111 1110 1110 + 18 (4 premiers bits, de poids forts, issus de FF, les autres c'est EE). Le bit de poinds fort valant 1 (donc position négative), la position vaudrait donc : - (2030 + 18) = -2048

Admettons ... c'est là que ça se corse :

As the position field refers to a position in the current 4k segment, pointers
have to be adjusted, too. Then "copy count" bytes are copied from the
relative "position" to the current one.

La position semble être relative à la courante, mais ce n'est pas possible car la position est négative, donc je sors du bloc (même du fichier en l'occurence pour ce premier bloc). Je ne comprends pas exactement ce qu'il appelle "segment" : le fait que la position soit codée sur 12 bits fait qu'elle ne peut en effet coder des valeurs entre 0 et 4095 (en faisant abstraction du signe), mais à part ça, ça ne dit pas où aller chercher. Je ne comprends pas non plus la phrase "pointers have to be adjusted" : de quels pointeurs parle-t-il ?

Bref, en l'état, je ne sais pas trop comment avancer car je n'ai grand chose à tester pour essayer d'avancer. Je n'ai pas l'impression que c'est un problème de compréhension de l'anglais, mais bon à ce stade, je suis prêt à toutes éventualités

[Sylvain_rocher]

Au passage, c'est normal que sur la capture d'écran "Force" n'ait pas été traduit et soir resté sous la forme "STR"?

Oui, pour le moment c’est normal car ce bout de phrase est dans l’EXE, et non dans le fichier des textes (STRINGS.PAK). C’était pareil dans le 1. Je te rassure, ce sera traduit à terminaison bien sur

[RetroArchives]

Au passage, c'est normal que sur la capture d'écran "Force" n'ait pas été traduit et soir resté sous la forme "STR"?

[Sylvain_rocher]

Quelques petites news : la traduction commence doucement. RetroArchives a traduit quelques textes, j'ai reporté d'autres traduction du 1. Le report des polices et des lettres avec accents de la traduction du 1 a été aussi rapide que je le pensais, ce qui est une excellente nouvelle ! Voici l'écran de création de l'Avatar pour exemple.

La traduction va peu avancer ces premiers mois par manque de temps. Je commencerai par faire les traductions un peu "techniques" (les éléments graphiques et l'EXE) pendant que Retro avance les autres textes, et d'ici fin février, je pense que je m'y consacrerai pleinement

[Sylvain_rocher]

Quand la traduction sera faite, si ça peut aider, je ferai une relecture comme pour le 1 (pour les coquilles et les fautes) (et si j'ai le temps). Comme on l'a vu, c'est toujours bon d'être plusieurs à relire.

Bien sûr !!

[GT400]

Quand la traduction sera faite, si ça peut aider, je ferai une relecture comme pour le 1 (pour les coquilles et les fautes) (et si j'ai le temps). Comme on l'a vu, c'est toujours bon d'être plusieurs à relire.

[Sylvain_rocher]

Bonjour à tous,

La traduction d'Ultima Underworld II va commencer, doucement, avec RetroArchives !
Comme pour le premier, les textes ont été extraits dans un fichier Excel sur lequel Retro va pouvoir commencer à travailler (pendant que je continue la trad d'Ultima 1 ...), et j'ai déjà reporté des modifications d'oFF_rus pour la construction des phrases.

Il y a la même charge de boulot (si ce n'est plus) que pour le premier, et il faudra aussi modifier les éléments graphiques bien sûr, et surtout s'attaquer à l'EXE. Mais ça viendra dans un second temps