OkamiDen - Traduction française

[BahaBulle]

En fait les overlays ne sont pas chargés au démarrage du jeu. Ils sont chargés en fonction des besoins.
Sinon ça ne servirait pas à grand chose d'avoir des overlays, autant avoir un seul exécutable. Puisque le fait d'avoir des overlays permet de réduire la taille de l'exécutable qui lui est forcément en RAM à tout moment.

Étant donné que fichier y9.bin donne les informations sur où charger les overlays en RAM et quelle est leur taille, théoriquement, en prenant tous les overlays chargés à la même adresse (mais pas en même temps, hein ), on devrai pouvoir se baser sur la taille du plus grand sans que ça ne pose problème. Mais cela reste de la théorie tant qu'on a pas essayé

[Lyan53]

J'ai juste utilisé Dsdecmp qui est un logiciel s'utilisant en lignes de commandes

- Il suffit simplement de recompresser le fichier (compression overlay) avec ce logiciel

- D'éditer celui-ci pour fixer la taille du fichier compressé dans le header (qui se trouve à la toute fin de ce dernier puisqu'il est compressé de la fin au début contrairement au lz type 10 ou 11 qui lui va du debut à la fin)
On trouve cette taille à "- 8 octets" de la fin du fichier
Le souci qu'a dsdecmp, c'est qu'il table sur la taille sans le header alors qu'il faut prendre en compte celui-ci (il faut donc mettre la taille réelle du fichier compressé)

- Adapter dans l'index "y9.bin" la taille du fichier compressé qui changera certainement


Je ferais plus tard un détail là-dessus pour expliquer quelques petites bricoles à propos de ce header

Merci de votre aide =) et j'éspère trouver au moins une ou deux autres personnes pour m'aider dans cette lourde tache

Petite chose à savoir à ce propos ^^

Depuis sa sortie l'année dernière et bien qu'on ne l'ait pas encore commencé puisqu'on bosse sur d'autres trucs à terminer avant, il est dans les projets qu'on avait l'intention de se faire (enfin d'ici quelques mois qd on aura fini ce qu'on a actuellement sur le feu ^^)
J'en ai discuté avec l'équipe, et si tu es d'accord, pinktagada (traductrice) et moi-même (romhackeur et graphiste) te proposons notre aide et support sur ce projet, car de toute façon il est (enfin était) sur notre ToDoList des jeux à traduire prochainement.


Donc si tu veux bien de notre aide, on peut s'y coller tous ensemble, juste que nous on aura pour le moment d'autres trucs à terminer avant d'être totalement disponibles dessus


Bref, à toi de voir si tu es intéressé ou non par notre proposition

En fait les overlays ne sont pas chargés au démarrage du jeu. Ils sont chargés en fonction des besoins.
Sinon ça ne servirait pas à grand chose d'avoir des overlays, autant avoir un seul exécutable. Puisque le fait d'avoir des overlays permet de réduire la taille de l'exécutable qui lui est forcément en RAM à tout moment.

Étant donné que fichier y9.bin donne les informations sur où charger les overlays en RAM et quelle est leur taille, théoriquement, en prenant tous les overlays chargés à la même adresse (mais pas en même temps, hein ), on devrai pouvoir se baser sur la taille du plus grand sans que ça ne pose problème. Mais cela reste de la théorie tant qu'on a pas essayé

Okay je ne savais pas, intéressant tout ça ^^
Du coup faut pas que les textes soient situés dans l'overlay le plus gros sinon c'est la misère mais ça laisse une certaine marge de manoeuvre tout de même

Et sinon, la solution de rechange consiste à mettre en place une DTE pour ces quelques textes si jamais ça foire, bref, y'a moyen de gérer tout ça je pense ^^

Petite question néanmoins pour Baha :

Peut-on considerer que si dans l'index des overlay, l'adresse de chargement est la même sur plusieurs à la suite, seul un d'entre eux sera chargé en RAM ??
(La logique voudrait que oui et d'ailleurs je me demandais pourquoi plusieurs overlays ont la même adresse justement)

[lesnico]

Petite chose à savoir à ce propos ^^

Depuis sa sortie l'année dernière et bien qu'on ne l'ait pas encore commencé puisqu'on bosse sur d'autres trucs à terminer avant, il est dans les projets qu'on avait l'intention de se faire (enfin d'ici quelques mois qd on aura fini ce qu'on a actuellement sur le feu ^^)
J'en ai discuté avec l'équipe, et si tu es d'accord, pinktagada (traductrice) et moi-même (romhackeur et graphiste) te proposons notre aide et support sur ce projet, car de toute façon il est (enfin était) sur notre ToDoList des jeux à traduire prochainement.


Donc si tu veux bien de notre aide, on peut s'y coller tous ensemble, juste que nous on aura pour le moment d'autres trucs à terminer avant d'être totalement disponibles dessus


Bref, à toi de voir si tu es intéressé ou non par notre proposition

Ca serait un plaisir pour moi de travailler avec deux personnes experimentés comme vous Pour l'instant je continue le travail jusqu'à que vous pourrez m'aider ! J'avais justement besoin d'un graphiste, car j'ai du mal à éditer les images...

[BahaBulle]

Petite question néanmoins pour Baha :

Peut-on considerer que si dans l'index des overlay, l'adresse de chargement est la même sur plusieurs à la suite, seul un d'entre eux sera chargé en RAM ??
(La logique voudrait que oui et d'ailleurs je me demandais pourquoi plusieurs overlays ont la même adresse justement)

Théoriquement, c'est ça. Un seul de ces overlays sera chargé à la fois.
Bien sûr, après, vu que tout est possible, rien ne dit que les developpeurs utilisent ces informations mais bon, ça doit être rare.

[Lyan53]

Théoriquement, c'est ça. Un seul de ces overlays sera chargé à la fois.
Bien sûr, après, vu que tout est possible, rien ne dit que les developpeurs utilisent ces informations mais bon, ça doit être rare.

Mwoké, donc d'après ce que je constate rien que sur ce screen, on peut avoir rapidement pas mal de place dispo pour peu que le fichier le plus gros ne contienne pas trop de textes

A voir après si y'a moyen de déplacer les blocs de texte sur la fin du fichier en modifiant les pointeurs de ces derniers sans que ça cause de probleme ^^

Ca serait un plaisir pour moi de travailler avec deux personnes experimentés comme vous Pour l'instant je continue le travail jusqu'à que vous pourrez m'aider ! J'avais justement besoin d'un graphiste, car j'ai du mal à éditer les images...

Pour les images, les formats étant standards, ça ne posera pas trop de problème à éditer en théorie bien qu'il se peut que certains graphismes demandent à être étendu, mais rien d'insurmontable pour moi sur ce type de fichier ('fin normalement faudra confirmer ça à l'usage après)

Par contre, si ça ne te dérange pas, il faudra que je jette un oeil sur quelques bricoles comme la font modifiée, et la manière dont les outils espagnols gèrent le code du jeu sur les divers formats de scripts (m'assurer qu'une fois traduit, ce dernier ressort proprement pour pas qu'on se retrouve emmerdé avec des bugs à la con)

Normalement tout devrait rouler, mais mieux vaut vérifier tout de même par prudence

Suivant les formats des scripts, on pourra peut être même utiliser un éditeur en ligne avec màj en temps réel, pour faciliter les travaux, gérer les doublons, les retours lignes auto suivant la longueur de celles-ci, etc...


Bref à étudier tout ça

.............................................................................

Concernant le header situé à la fin des overlays compressés, voilà le détail :

Il peut faire de 0x08 à 0x0B octets en taille :


Dans l'exemple ci dessus, il fait 0x0B octets car du padding est utilisé pour la mise en forme.
La mise en forme est importante du fait qu'un fichier compressé peut faire un nombre d'octets impair et que le code du jeu est lu 32 bits (4 octets) par 32 bits.
Du padding composé de 0xFF est ajouté pour que le header tombe sur un offset se terminant par "0x.0, 0x.4, 0x.8 ou 0x.C" afin de respecter cette règle des 32 bits

• de 0 à 3 octets (en bleu) => il s'agit de padding (0xFF) utilisé pour la mise en forme du fichier
• 3 octets (en rouge) => taille du fichier compressé
• 1 octet (en violet) => taille du header
• 4 octets (en orange)=> différentiel de taille entre le fichier non-compressé et le fichier une fois compressé

[jerome674]

pour information :

pour modifier les overlays, voici ce que m'a conseillé hackotedelaplaque :

- connaitre l'adresse en Ram de chargement de ton overlay de type 0x02XXXXXX. Ça tu le sais, ca se trouve dans la table des overlay (y9.bin).
- identifier dans ton overlay le code qui déclenche le texte. Plus loin tu trouveras le pointeur de texte. A moins que tu ais une table comme tu le suggères dans ton jeu. Le pointeur aura la forme 0x02XXXXXX. D'où l'intérêt de connaître l'adresse de chargement de l'overlay. Exemple : Pour un overlay chargé à 0x02100000, si ton texte est à 0x1F0 son pointeur sera 0x021001F0. Et bien sûr, on est en little endian donc cherche F0011002.
- balayer l'overlay pour enregistrer dans un tableau (ou mieux une linked list) l'adresse et la longueur de chaque plage de texte. Au passage, nettoyage du texte original (remplacé par des 00).
- Ensuite, lorsque l'éditeur de texte que tu as programmé cherchera à réinserrer le texte traduit, tu compares sa longueur avec chacune des plages. Si ça rentre, tu écris le texte dans cette plage et tu mets à jour le pointeur de texte avec le pointeur de plage libre. Sinon, tu passes à la plage suivante.
Si ça ne rentre pas pour chacune des plages, tu écris en fin de fichier et tu repointes la bonne adresse.

autre méthode :
L'autre consiste à créer un overlay "propre" c'est à dire avec tout le texte en fin de fichier.
Pour ce faire, fais une boucle qui :
- coupe la plage de texte et repointe toutes les adresses (attention, on parle ici de toute adresse ! Pas seulement les pointeurs de texte !!) qui suivent la césure (et seulement celles qui suivent, pas avant) pour retrancher la valeur de la longueur de coupe. Exemple : avec le même offset de chargement de l'overlay (0x02100000). Si tu coupes la première plage à 0x1F0 sur 0x150 octets, tu dois rechercher toute valeur long > à 0x021001F0 (attention little endian : F0011002) et la remplacer par valeur - 0x150.
Et ainsi de suite pour chaque coupe.
- Ensuite tu écris ton texte en fin de fichier et tu repointes les adresses.

[lesnico]

Dernières nouvelles :

Je travaille presque en coopération avec Xulitony qui traduit, lui, le jeu e Espagnol. Nous utilisons les mêmes outils et parlons beaucoup ensemble, donc cela permet de se rendre compte d'erreurs éventuelles.
Malheureusement, nous nnous sommes rendus compte qu'avec notre programme de traduction du jeu, nous ne pouvions traduire les dialogues, il y a, semble t'il un oubli de la part du dev car nous avons remarqué (pas sur à 100%) que les dialogues utilisaient les pointeurs. Ces dialogues sont dans le dossier "script" et ont pour extension : .EVB.

Les autres textes du jeu (cinématiques, techniques du pinceau, objets...) marchent correctement.

Pour l'instant, je traduis quand même les dialogues que je trasfère ensuite en .XML. Mon logiciel peut les importer et donc j'attends une version corrigée. Malheureusement, le dev n'a pas du tout le temps en ce moment et je chercherai donc un developeur qui pourrai me faire un programme pour traduire ces scripts
Il sera remercié grandement, dans les crédits

Bonne journée

[BahaBulle]

il y a, semble t'il un oubli de la part du dev car nous avons remarqué (pas sur à 100%) que les dialogues utilisaient les pointeurs.

Il a extrait les textes sans les pointeurs ? O_o
Et qu'est-ce qui vous faire dire qu'ils ne sont pas gérés ?

je chercherai donc un developeur qui pourrai me faire un programme pour traduire ces scripts

Il n'y a pas de ça ici

[Lyan53]

Les fichiers .EVB sont les plus techniques du jeu à aborder, là faut carrément avant toute chose en percer les mystères et vu qu'ils embarquent pas uniquement les textes mais des datas en prime, c'est pas de la tarte...
Leur structure est assez complexe et personnellement, je n'ai pas trouvé assez de données dessus lors des mes analyses, qui permettraient à un programmeur de coder un outil pour ces derniers (il manque trop d'informations, je n'ai pu identifier que la manière dont les textes sont stockés mais rien qui permet de définir comment les trouver dans les fichier)

Ce dernier détail ayant son importance car il faut un outil capable de localiser l'offset ou ces textes sont stockés et ça change d'un fichier sur l'autre


Tous les autres fichiers contenant du texte sont très simples à aborder et ne posent aucun problème, c'est les .EVB qui sont justement le point central du hack pour ce jeu donc autant dire qu'il manque carrément l'outil principal de traduction


Sinon à ma connaissance ce jeu n'utilise pas de pointeurs pour les textes sauf dans les overlays

[lesnico]

Bonne nouvelle les amis !

C'est Pleonex, le créateur de Tinke himself qui s'est appliqué à rendre l'édition des fichiers .evb fonctionnelles !

nous devrions avoir le nouveau programme dans qq jours !

je vous tiens au jus !