Tweet
Ça fait longtemps que ça me trottait dans la tête d'écrire une aide sur l'art et la manière de modifier un programme, mais vu les différentes compétences que l'on acquiert à exercer ce genre d'activité et la difficulté à les faire partager en se faisant comprendre par des non-initiés, j'avais toujours reculé devant ce genre d'initiative.
Alors voila, j'ai essayé de classer les méthodes selon le degré de compétences des amateurs.
Et désolé, je vais être assez volubile ici, mais je vais essayer de parler de tous les problèmes que l'on peut rencontrer.
Déjà si c'est pour traduire un jeu, commencez à chercher avec Google s'il n'existe pas dans la langue que vous souhaitez ou posez la question sur le forum. Si la réponse est négative, cherchez s'il n'existe pas déjà d'outils pour modifier ce jeu.
Et ne pas prendre systématiquement toutes les affirmations suivantes au pied de la lettre. Ce sont juste des cas généraux et il y a bien sûr toujours des exceptions.
Niveau 1:
Prérequis: Savoir se servir d'un éditeur hexadécimal.
Il est hors de question de commencer d'emblée à modifier les fichiers avec un éditeur texte. Ces programmes modifient ou suppriment ce qui ne leur paraît pas être du texte et transforment parfois les fins de ligne même s'il s'agit de texte pur.
Donc ouvrir chacun des fichiers du jeu avec un éditeur hexadécimal.
Souvent en début de fichier il y a quelques caractères qui indiquent le type de fichier. Par exemple un fichier qui commence par MZ a de fortes chances d'être un programme exe.
Pour les autres types, il est rare de tomber sur des types standard.
On peut faire une recherche sur le net à partir du ou des textes qu'on trouve au début de ces fichiers.
Sur http://myfileformats.com on trouve énormément d'informations sur les formats standard de fichiers.
Sur http://www.wotsit.org également plus quelques formats de fichiers de jeux.
Il vaut mieux avoir quelques notions de programmation pour comprendre certains, mais ça peut quand même aider sans.
Un outil comme Dragon Unpacker permet de désarchiver les fichiers archives de certains jeux mais comme il ne permet pas de les réarchiver et que le jeu ne tournera pas la plupart du temps avec ces fichiers désarchivés, ce n'est pas très utile à ce niveau.
Les programmes Exe ou Com DOS:
La plupart du temps, ils sont compressés pour tenir moins de place sur les disquettes ou pour les protéger. Lorsqu'on les lance ils sont décompressés en mémoire avant exécution normale.
Pour pouvoir modifier ces programmes il faut commencer par les décompresser avec UNP par exemple.
Il n'est pas nécessaire de les recompresser ensuite pour les faire fonctionner.
On peut passer systématiquement Unp sur un programme Dos, au pire celui-ci n'est pas modifié si Unp ne détecte pas qu'il a été compressé.
Les programmes Exe Windows:
Les ressources comprises dans l'exe sont en général au format standard et il est facile de les modifier à l'aide d'un éditeur de ressources standard Windows.
Il existe énormément de sharewares disponibles pour modifier ces programmes.
Il faut faire simplement la distinction entre 2 grandes catégories d'exe pour choisir le bon outil:
- Les programmes 16 bits (Windows 3).
- Les programmes 32 bits (Windows 98 et suivants).
2 catégories intermédiaires existent; Les programmes développés pour le Win32s de Win3 et ceux pour Win95. Là rien n'est garanti pour leur modification.
Les accents dans les textes:
Si le jeu est un programme Dos, est d'origine anglo-saxonne et n'existe pas dans d'autres langues que l'anglais, il est probable que les accents ne seront pas gérés dans les textes et vous n'aurez alors pas à vous préoccuper du choix d'une police dans l'éditeur.
En effet les polices Dos et Windows sont les mêmes pour le jeu Ascii standard et non accentué de 128 caractères.
Par contre pour modifier les textes accentués d'un programme Dos, vous devrez sélectionner dans l'éditeur le jeu de caractères Dos. Et pour modifier un programme windows, le jeu de caractères ANSI.
Ceci concerne en fait tous les caractères entre 129 et 255.
Pour info, un caractère est codé sur 8 bits donc il existe 256 caractères possibles de 0 à 255. (On ne parlera pas d'unicode ici dont les caractères sont codés sur 16 bits voire 32)
Les fins de ligne:
Quand on ouvre un fichier qui paraît ne contenir que du texte pur, la fin de chaque ligne peut être codée de 2 manières principales;
Standard Dos: 0D + 0A en hexa ce qui correspond à CR + LF (Carriage return + Line Feed)
Autres standards: 0A en hexa (LF) seulement.
Si le fichier est au standard Dos, pas de problème, on peut le modifier avec n'importe quel éditeur texte à la condition de l'enregistrer ensuite au format texte seulement.
Sinon, je ne vois que le bloc-notes qui ne convertit pas les LF en CR+LF
Et il faut conserver le même type de fins de lignes que dans l'original afin que le programme du jeu affiche correctement ces textes.
Les fins de texte peuvent également être un 00h pour un programme compilé à partir de sources en langage C/C++, un $ pour un programme d'origine Pascal ou tout autre caractère particulier choisi par les programmeurs.
Adresses des lignes:
Il est rare qu'un programme recherche la nième ligne en lisant tout le fichier, comptant le nombre de lignes au fur et à mesure et s'arrêtant sur la bonne ligne.
En général il y a une table qui indique les adresses où commencent les textes.
Cette table peut-être incluse au début du même fichier, rarement à la fin, ou dans un autre fichier, voire dans l'exe.
Cette table se présente sous la forme de nombres écrits en hexa sur 1, 2 ou 4 octets chacun.
Quand il y a plusieurs octets pour renseigner les nombres, il faut les lire à partir de la droite.
C'est la notation dite "little endian" typique des processeurs Intel.
Il est possible aussi que d'autres valeurs soient renseignées dans cette table, comme la longueur des textes, ou le type de textes.
Dans ce cas on pourrait avoir une table du genre;
Adresse texte 1, Longueur texte 1, Type texte 1, Adresse texte 2, Longueur texte 2, Type texte 2, ...
Donc en modifiant la longueur des textes il faut veiller à modifier également ces valeurs.
Il faut savoir aussi que cette table peut exister de manière redondante et sous une autre forme dans un autre fichier. C'est après des tests de modification qu'on peut s'en rendre compte.
Les images:
C'est très fastidieux de modifier des images à la main dans un éditeur hexa, mais s'il y a très peu de textes sous forme d'images, c'est réalisable.
Il faut tout d'abord qu'elles soient affichables simplement.
Pour ce faire, ajoutez l'extension .RAW au fichier pour qu'il s'ouvre automatiquement avec Photoshop.
Ce dernier vous demande alors quelques informations sur l'image;
- Largeur: Mettez 320 pour l'instant.
- Hauteur: Taille fichier / 320 (Prenez la valeur entière par défaut).
- Couches: 1 (correspond à 1 octet par pixel, soit du 256 couleurs)
- Taille entête: 0 (On affiche à partir du début du fichier)
Si le fichier contient des images non compressées et codées à 1 octet par pixel, vous devriez voir apparaître des images en nuances de gris car en mode RAW on ne nous demande pas où est la palette de couleurs.
Si on remarque plusieurs fois la même image en écho en largeur et très étirée en hauteur, c'est qu'on a défini une trop grande largeur d'image. Exemple, l'image apparaît 4 fois en largeur, choisir 320/4 comme nouvelle largeur.
Si l'image apparaît décalée en diagonale, ajuster la largeur d'une unité en plus ou en moins selon le sens.
Maintenant que vous avez l'image en clair mais simplement décalée à gauche ou à droite, recommencez en jouant sur la Taille entête pour qu'elle s'inscrive en entier dans la fenêtre.
Pour retrouver l'adresse de l'image dans le fichier, il ne reste plus qu'à repérer les coordonnées XY du coin haut gauche de l'image puis de calculer Adresse = Y * largeur + X + Taille entête.
A partir de cette adresse et connaissant la largeur d'une ligne, on peut modifier l'image avec un éditeur hexa.
Niveau 2:
Prérequis: Savoir Programmer (ou s'y mettre, ou connaître quelqu'un prêt à le faire pour vous)
Là ça ouvre plein de possibilités, surtout celle d'automatiser certaines tâches que l'on ne peut faire que manuellement autrement. Ainsi il est plus facile de faire un programme qui exporte et importe des textes et modifier ceux-ci dans un éditeur texte plutôt que de modifier ces textes dans un éditeur hexa et mettre à jour à la main toutes les adresses et les longueurs de ces textes.
La tâche essentielle et la plus difficile consiste à identifier de quelle manière sont structurés les fichiers à modifier. Ensuite la partie programmation est aisée, ce n'est que de la conversion de fichiers binaires.
Desarchivage des ressources:
Quand le jeu est constitué de très peu de fichiers, on peut s'attendre à ce que ces fichiers soient des archives, c'est à dire qu'ils contiennent eux-mêmes de plus petits fichiers.
Les archives peuvent être compressées mais en général ce sont plutôt les fichiers inclus qui le sont, parfois il y a double compression.
Dans l'archive elle-même ou dans un autre fichier on trouvera une table qui contient le nom des fichiers inclus, leur adresse, leur taille, ...
La difficulté est de trouver comment elle est organisée.
Par rapport à une table de textes on est ici aidé par le fait qu'elle contient les noms de fichiers. Donc on pourra repérer plus facilement quelque chose de la forme:
Nom fichier 1, Adresse fichier 1, Longueur fichier 1, Type fichier 1, ...,
Nom fichier 2, Adresse fichier 2, Longueur fichier 2, Type fichier 2, ...
Certaines informations sont parfois redondantes et inutiles pour l'export, mais il sera obligatoire de les modifier à l'import si le programme du jeu en a besoin.
Exemple: On peut retrouver Adresse fichier 2 avec Adresse fichier 1 + Longueur fichier 1.
Parmi les informations utiles on devrait trouver aussi en tête d'archive le nombre de fichiers inclus.
Une fois ces informations retrouvées on peut entamer le programme de desarchivage/archivage.
Décompression des ressources:
C'est à mon avis la partie la plus difficile et chaque jeu est un cas particulier.
On est quand même aidé par le fait qu'on travaille sur d'anciens jeux et que les techniques de compression utilisées alors étaient assez rudimentaires.
Il y principalement 3 familles de compresseurs utilisés.
- RLE : On indique le nombre de répétitions de tel octet.
Un texte compressé en RLE ne sera pratiquement pas modifié car il y a rarement des lettres identiques qui se suivent. Par contre une image 256 couleurs pourra être relativement compressée.
- LZ : On réutilise des suites d'octets précédentes.
Un texte compressé avec LZ est reconnaissable au fait que le début du texte est en clair puis on trouve ensuite des octets bizarres au milieu du texte indiquant quelle suite précédente utiliser.
- LZH/LZW : On Remplace chaque octet ou chaîne par un code entre 2 et 12 bits selon sa fréquence.
Un texte compressé ainsi sera absolument illisible et il faudra aller lire la méthode de décompression dans l'exe (Niveau 3)
Les techniques de compression RLE et LZ utilisent une liste très limitée d'instructions pour définir ce qu'il faut faire du texte qui suit. Mais ces instructions sont souvent définies par le programmeur du jeu.
Dans l'octet définissant l'instruction, les bits de gauche pourront définir l'action à faire (copie, duplication, déplacement, ...) et les bits de droite le compte d'octets suivants à gérer.
Regarder les formats standard pour s'aider.
Une méthode simple pour trouver la signification de ces instructions est de les modifier au niveau du bit, voir l'effet que ça donne dans le jeu et en déduire le fonctionnement.
Conversion des ressources:
Une fois les ressources désarchivées et décompressées, il ne reste plus qu'à les convertir dans un format standard pour pouvoir les modifier simplement; TXT, WAV, BMP, GIF animé. C'est toujours possible.
Le cas des musiques est particulier. On trouvera 2 familles, les musiques Adlib et les musiques Midi et on ne pourra pas convertir de l'une à l'autre de manière satisfaisante. Donc choisir un format de fichier qui correspond.
Textes: S'il y a une seule langue le format TXT est bien adapté. (Ce n'est pas un format d'ailleurs)
Il est conseillé de démarrer chaque ligne de texte avec un numéro de ressource et/ou un numéro de ligne qui sera contrôlé à l'import afin de vérifier qu'aucune ligne n'a été supprimée ou insérée par le traducteur et ainsi conserver la synchronisation des données.
Pour des textes multilingues ou qui contiennent en plus des informations par exemple les coordonnées de l'affichage de ce texte, je préconise le format Excel texte.
Il est très simple à créer, il suffit d'insérer une tabulation dans les textes pour changer de colonne et de nommer le fichier avec le suffixe XLS
Images: Pour une image 256 couleurs ou plus, le plus simple pour démarrer est le format BMP.
Penser juste que les images commencent par la dernière ligne et que chaque ligne doit faire un multiple de 4 octets.
Pour une image 16 couleurs vous trouverez sans doute les données organisées par plans de couleurs comme dans le format LBM ou IFF. Dans ce cas, il vaut mieux utiliser directement ce format plutôt que de faire la conversion au format BMP par programme.
Il faut faire la distinction aussi entre les images de fond d'écran et celles des sprites qui s'affichent sur ces fonds. Il sera peut-être plus adapté pour ces sprites d'utiliser le format GIF qui permet de définir des transparences.
Animations: Soit on exporte toutes les images individuelles, soit on réalise une animation dans un format standard.
Mais puisque le programme est destiné à réimporter ces images, elles seront sûrement plus faciles à modifier si elles sont exportées individuellement.
Là je préconise le format GIF qui permet d'afficher en transparent tout ce qui n'est pas différent de l'image précédente.
Palettes de couleurs: Elles sont utilisées pour les images et les animations.
Ce sont une des ressources les plus difficiles à repérer. En effet, par souci d'économie de place dans les jeux d'install et à cause du fait qu'une image de fond et les sprites qui s'affichent dessus utilisent la même palette, cette palette n'est enregistrée qu'une fois et non dans chaque image.
Pour chaque couleur de la palette 16 ou 256 couleurs, on trouvera toujours 3 octets définissant l'intensité des primitives Rouge Vert Bleu dans cet ordre ou dans l'ordre BVR comme dans un fichier BMP.
On pourra trouver ou non pour chaque couleur un quatrième octet pour l'intensité.
Et enfin les primitives pourront être codées de 0 à 3F ou de 0 à FF.
Donc faire la conversion en conséquence.
Pour les programmes CGA 4 couleurs, les couleurs sont prédéfinies et sélectionnables parmi 2 jeux et on ne peut pas les modifier.
Pour les programmes 16 couleurs ou plus, il n'y a pas de palette.
Polices de caractères: Là aussi, ces ressources sont difficiles à repérer et si elles ne sont pas contenues dans un fichier dont le nom contient car, chr, let, fnt, ... je ne peux pas donner de conseil universel pour les retrouver.
Et pourtant on en a souvent besoin pour traduire un jeu afin d'y rajouter des lettres accentuées.
Alors, juste un tuyau; Les polices des anciens jeux sont toujours des bitmaps, jamais des polices vectorielles. Donc elles sont enregistrées sous la forme d'images 2 couleurs; un bit à 0 indiquant pixel transparent et un bit à 1 indiquant pixel de la couleur d'écriture. Donc un octet pourra représenter les 8 pixels d'une ligne d'un caractère.
Là aussi, c'est par essais de modification manuelle d'un fichier que l'on peut arriver à comprendre la structure des polices.
Sons: Tout d'abord, il faut repérer ces sons parmi les archives.
Pour les sons 8 bits on trouvera des suites d'octets qui tournent autour de la valeur moyenne 80h.
Parfois autour de la valeur moyenne 0, c'est à dire 00h, 01h, FFh, 02h, FEh, ...
Pour les sons 16 bits, regardez en hexa un fichier WAV standard pour voir son apparence.
Mono ou stéréo: Là, il faut écouter les sons dans le jeu pour le détecter et ensuite regarder dans l'entête des ressources s'il y a un octet qui correspond.
Fréquence d'échantillonnage: Quelques fréquences standard sont 11025, 22050, 44100 Hz.
On pourra retrouver ces fréquences dans l'entête de la ressource son ou pas du tout ou carrément une fréquence bâtarde. Là aussi il faut faire des essais.
Musiques: Elles sont très difficiles à repérer si elles ne contiennent pas des entêtes standard, donc procéder par élimination une fois les autres ressources décortiquées.
Niveau 3:
Prérequis: être à l'aise en assembleur. (ou le devenir)
A partir des techniques de désassemblage et de débuggage d'un programme il n'y a plus aucune limite aux modifications que l'on peut opérer dans celui-ci.
Bon, c'est tout pour l'instant.
A suivre ...
Alors voila, j'ai essayé de classer les méthodes selon le degré de compétences des amateurs.
Et désolé, je vais être assez volubile ici, mais je vais essayer de parler de tous les problèmes que l'on peut rencontrer.
Déjà si c'est pour traduire un jeu, commencez à chercher avec Google s'il n'existe pas dans la langue que vous souhaitez ou posez la question sur le forum. Si la réponse est négative, cherchez s'il n'existe pas déjà d'outils pour modifier ce jeu.
Et ne pas prendre systématiquement toutes les affirmations suivantes au pied de la lettre. Ce sont juste des cas généraux et il y a bien sûr toujours des exceptions.
Niveau 1:
Prérequis: Savoir se servir d'un éditeur hexadécimal.
Il est hors de question de commencer d'emblée à modifier les fichiers avec un éditeur texte. Ces programmes modifient ou suppriment ce qui ne leur paraît pas être du texte et transforment parfois les fins de ligne même s'il s'agit de texte pur.
Donc ouvrir chacun des fichiers du jeu avec un éditeur hexadécimal.
Souvent en début de fichier il y a quelques caractères qui indiquent le type de fichier. Par exemple un fichier qui commence par MZ a de fortes chances d'être un programme exe.
Pour les autres types, il est rare de tomber sur des types standard.
On peut faire une recherche sur le net à partir du ou des textes qu'on trouve au début de ces fichiers.
Sur http://myfileformats.com on trouve énormément d'informations sur les formats standard de fichiers.
Sur http://www.wotsit.org également plus quelques formats de fichiers de jeux.
Il vaut mieux avoir quelques notions de programmation pour comprendre certains, mais ça peut quand même aider sans.
Un outil comme Dragon Unpacker permet de désarchiver les fichiers archives de certains jeux mais comme il ne permet pas de les réarchiver et que le jeu ne tournera pas la plupart du temps avec ces fichiers désarchivés, ce n'est pas très utile à ce niveau.
Les programmes Exe ou Com DOS:
La plupart du temps, ils sont compressés pour tenir moins de place sur les disquettes ou pour les protéger. Lorsqu'on les lance ils sont décompressés en mémoire avant exécution normale.
Pour pouvoir modifier ces programmes il faut commencer par les décompresser avec UNP par exemple.
Il n'est pas nécessaire de les recompresser ensuite pour les faire fonctionner.
On peut passer systématiquement Unp sur un programme Dos, au pire celui-ci n'est pas modifié si Unp ne détecte pas qu'il a été compressé.
Les programmes Exe Windows:
Les ressources comprises dans l'exe sont en général au format standard et il est facile de les modifier à l'aide d'un éditeur de ressources standard Windows.
Il existe énormément de sharewares disponibles pour modifier ces programmes.
Il faut faire simplement la distinction entre 2 grandes catégories d'exe pour choisir le bon outil:
- Les programmes 16 bits (Windows 3).
- Les programmes 32 bits (Windows 98 et suivants).
2 catégories intermédiaires existent; Les programmes développés pour le Win32s de Win3 et ceux pour Win95. Là rien n'est garanti pour leur modification.
Les accents dans les textes:
Si le jeu est un programme Dos, est d'origine anglo-saxonne et n'existe pas dans d'autres langues que l'anglais, il est probable que les accents ne seront pas gérés dans les textes et vous n'aurez alors pas à vous préoccuper du choix d'une police dans l'éditeur.
En effet les polices Dos et Windows sont les mêmes pour le jeu Ascii standard et non accentué de 128 caractères.
Par contre pour modifier les textes accentués d'un programme Dos, vous devrez sélectionner dans l'éditeur le jeu de caractères Dos. Et pour modifier un programme windows, le jeu de caractères ANSI.
Ceci concerne en fait tous les caractères entre 129 et 255.
Pour info, un caractère est codé sur 8 bits donc il existe 256 caractères possibles de 0 à 255. (On ne parlera pas d'unicode ici dont les caractères sont codés sur 16 bits voire 32)
Les fins de ligne:
Quand on ouvre un fichier qui paraît ne contenir que du texte pur, la fin de chaque ligne peut être codée de 2 manières principales;
Standard Dos: 0D + 0A en hexa ce qui correspond à CR + LF (Carriage return + Line Feed)
Autres standards: 0A en hexa (LF) seulement.
Si le fichier est au standard Dos, pas de problème, on peut le modifier avec n'importe quel éditeur texte à la condition de l'enregistrer ensuite au format texte seulement.
Sinon, je ne vois que le bloc-notes qui ne convertit pas les LF en CR+LF
Et il faut conserver le même type de fins de lignes que dans l'original afin que le programme du jeu affiche correctement ces textes.
Les fins de texte peuvent également être un 00h pour un programme compilé à partir de sources en langage C/C++, un $ pour un programme d'origine Pascal ou tout autre caractère particulier choisi par les programmeurs.
Adresses des lignes:
Il est rare qu'un programme recherche la nième ligne en lisant tout le fichier, comptant le nombre de lignes au fur et à mesure et s'arrêtant sur la bonne ligne.
En général il y a une table qui indique les adresses où commencent les textes.
Cette table peut-être incluse au début du même fichier, rarement à la fin, ou dans un autre fichier, voire dans l'exe.
Cette table se présente sous la forme de nombres écrits en hexa sur 1, 2 ou 4 octets chacun.
Quand il y a plusieurs octets pour renseigner les nombres, il faut les lire à partir de la droite.
C'est la notation dite "little endian" typique des processeurs Intel.
Il est possible aussi que d'autres valeurs soient renseignées dans cette table, comme la longueur des textes, ou le type de textes.
Dans ce cas on pourrait avoir une table du genre;
Adresse texte 1, Longueur texte 1, Type texte 1, Adresse texte 2, Longueur texte 2, Type texte 2, ...
Donc en modifiant la longueur des textes il faut veiller à modifier également ces valeurs.
Il faut savoir aussi que cette table peut exister de manière redondante et sous une autre forme dans un autre fichier. C'est après des tests de modification qu'on peut s'en rendre compte.
Les images:
C'est très fastidieux de modifier des images à la main dans un éditeur hexa, mais s'il y a très peu de textes sous forme d'images, c'est réalisable.
Il faut tout d'abord qu'elles soient affichables simplement.
Pour ce faire, ajoutez l'extension .RAW au fichier pour qu'il s'ouvre automatiquement avec Photoshop.
Ce dernier vous demande alors quelques informations sur l'image;
- Largeur: Mettez 320 pour l'instant.
- Hauteur: Taille fichier / 320 (Prenez la valeur entière par défaut).
- Couches: 1 (correspond à 1 octet par pixel, soit du 256 couleurs)
- Taille entête: 0 (On affiche à partir du début du fichier)
Si le fichier contient des images non compressées et codées à 1 octet par pixel, vous devriez voir apparaître des images en nuances de gris car en mode RAW on ne nous demande pas où est la palette de couleurs.
Si on remarque plusieurs fois la même image en écho en largeur et très étirée en hauteur, c'est qu'on a défini une trop grande largeur d'image. Exemple, l'image apparaît 4 fois en largeur, choisir 320/4 comme nouvelle largeur.
Si l'image apparaît décalée en diagonale, ajuster la largeur d'une unité en plus ou en moins selon le sens.
Maintenant que vous avez l'image en clair mais simplement décalée à gauche ou à droite, recommencez en jouant sur la Taille entête pour qu'elle s'inscrive en entier dans la fenêtre.
Pour retrouver l'adresse de l'image dans le fichier, il ne reste plus qu'à repérer les coordonnées XY du coin haut gauche de l'image puis de calculer Adresse = Y * largeur + X + Taille entête.
A partir de cette adresse et connaissant la largeur d'une ligne, on peut modifier l'image avec un éditeur hexa.
Niveau 2:
Prérequis: Savoir Programmer (ou s'y mettre, ou connaître quelqu'un prêt à le faire pour vous)
Là ça ouvre plein de possibilités, surtout celle d'automatiser certaines tâches que l'on ne peut faire que manuellement autrement. Ainsi il est plus facile de faire un programme qui exporte et importe des textes et modifier ceux-ci dans un éditeur texte plutôt que de modifier ces textes dans un éditeur hexa et mettre à jour à la main toutes les adresses et les longueurs de ces textes.
La tâche essentielle et la plus difficile consiste à identifier de quelle manière sont structurés les fichiers à modifier. Ensuite la partie programmation est aisée, ce n'est que de la conversion de fichiers binaires.
Desarchivage des ressources:
Quand le jeu est constitué de très peu de fichiers, on peut s'attendre à ce que ces fichiers soient des archives, c'est à dire qu'ils contiennent eux-mêmes de plus petits fichiers.
Les archives peuvent être compressées mais en général ce sont plutôt les fichiers inclus qui le sont, parfois il y a double compression.
Dans l'archive elle-même ou dans un autre fichier on trouvera une table qui contient le nom des fichiers inclus, leur adresse, leur taille, ...
La difficulté est de trouver comment elle est organisée.
Par rapport à une table de textes on est ici aidé par le fait qu'elle contient les noms de fichiers. Donc on pourra repérer plus facilement quelque chose de la forme:
Nom fichier 1, Adresse fichier 1, Longueur fichier 1, Type fichier 1, ...,
Nom fichier 2, Adresse fichier 2, Longueur fichier 2, Type fichier 2, ...
Certaines informations sont parfois redondantes et inutiles pour l'export, mais il sera obligatoire de les modifier à l'import si le programme du jeu en a besoin.
Exemple: On peut retrouver Adresse fichier 2 avec Adresse fichier 1 + Longueur fichier 1.
Parmi les informations utiles on devrait trouver aussi en tête d'archive le nombre de fichiers inclus.
Une fois ces informations retrouvées on peut entamer le programme de desarchivage/archivage.
Décompression des ressources:
C'est à mon avis la partie la plus difficile et chaque jeu est un cas particulier.
On est quand même aidé par le fait qu'on travaille sur d'anciens jeux et que les techniques de compression utilisées alors étaient assez rudimentaires.
Il y principalement 3 familles de compresseurs utilisés.
- RLE : On indique le nombre de répétitions de tel octet.
Un texte compressé en RLE ne sera pratiquement pas modifié car il y a rarement des lettres identiques qui se suivent. Par contre une image 256 couleurs pourra être relativement compressée.
- LZ : On réutilise des suites d'octets précédentes.
Un texte compressé avec LZ est reconnaissable au fait que le début du texte est en clair puis on trouve ensuite des octets bizarres au milieu du texte indiquant quelle suite précédente utiliser.
- LZH/LZW : On Remplace chaque octet ou chaîne par un code entre 2 et 12 bits selon sa fréquence.
Un texte compressé ainsi sera absolument illisible et il faudra aller lire la méthode de décompression dans l'exe (Niveau 3)
Les techniques de compression RLE et LZ utilisent une liste très limitée d'instructions pour définir ce qu'il faut faire du texte qui suit. Mais ces instructions sont souvent définies par le programmeur du jeu.
Dans l'octet définissant l'instruction, les bits de gauche pourront définir l'action à faire (copie, duplication, déplacement, ...) et les bits de droite le compte d'octets suivants à gérer.
Regarder les formats standard pour s'aider.
Une méthode simple pour trouver la signification de ces instructions est de les modifier au niveau du bit, voir l'effet que ça donne dans le jeu et en déduire le fonctionnement.
Conversion des ressources:
Une fois les ressources désarchivées et décompressées, il ne reste plus qu'à les convertir dans un format standard pour pouvoir les modifier simplement; TXT, WAV, BMP, GIF animé. C'est toujours possible.
Le cas des musiques est particulier. On trouvera 2 familles, les musiques Adlib et les musiques Midi et on ne pourra pas convertir de l'une à l'autre de manière satisfaisante. Donc choisir un format de fichier qui correspond.
Textes: S'il y a une seule langue le format TXT est bien adapté. (Ce n'est pas un format d'ailleurs)
Il est conseillé de démarrer chaque ligne de texte avec un numéro de ressource et/ou un numéro de ligne qui sera contrôlé à l'import afin de vérifier qu'aucune ligne n'a été supprimée ou insérée par le traducteur et ainsi conserver la synchronisation des données.
Pour des textes multilingues ou qui contiennent en plus des informations par exemple les coordonnées de l'affichage de ce texte, je préconise le format Excel texte.
Il est très simple à créer, il suffit d'insérer une tabulation dans les textes pour changer de colonne et de nommer le fichier avec le suffixe XLS
Images: Pour une image 256 couleurs ou plus, le plus simple pour démarrer est le format BMP.
Penser juste que les images commencent par la dernière ligne et que chaque ligne doit faire un multiple de 4 octets.
Pour une image 16 couleurs vous trouverez sans doute les données organisées par plans de couleurs comme dans le format LBM ou IFF. Dans ce cas, il vaut mieux utiliser directement ce format plutôt que de faire la conversion au format BMP par programme.
Il faut faire la distinction aussi entre les images de fond d'écran et celles des sprites qui s'affichent sur ces fonds. Il sera peut-être plus adapté pour ces sprites d'utiliser le format GIF qui permet de définir des transparences.
Animations: Soit on exporte toutes les images individuelles, soit on réalise une animation dans un format standard.
Mais puisque le programme est destiné à réimporter ces images, elles seront sûrement plus faciles à modifier si elles sont exportées individuellement.
Là je préconise le format GIF qui permet d'afficher en transparent tout ce qui n'est pas différent de l'image précédente.
Palettes de couleurs: Elles sont utilisées pour les images et les animations.
Ce sont une des ressources les plus difficiles à repérer. En effet, par souci d'économie de place dans les jeux d'install et à cause du fait qu'une image de fond et les sprites qui s'affichent dessus utilisent la même palette, cette palette n'est enregistrée qu'une fois et non dans chaque image.
Pour chaque couleur de la palette 16 ou 256 couleurs, on trouvera toujours 3 octets définissant l'intensité des primitives Rouge Vert Bleu dans cet ordre ou dans l'ordre BVR comme dans un fichier BMP.
On pourra trouver ou non pour chaque couleur un quatrième octet pour l'intensité.
Et enfin les primitives pourront être codées de 0 à 3F ou de 0 à FF.
Donc faire la conversion en conséquence.
Pour les programmes CGA 4 couleurs, les couleurs sont prédéfinies et sélectionnables parmi 2 jeux et on ne peut pas les modifier.
Pour les programmes 16 couleurs ou plus, il n'y a pas de palette.
Polices de caractères: Là aussi, ces ressources sont difficiles à repérer et si elles ne sont pas contenues dans un fichier dont le nom contient car, chr, let, fnt, ... je ne peux pas donner de conseil universel pour les retrouver.
Et pourtant on en a souvent besoin pour traduire un jeu afin d'y rajouter des lettres accentuées.
Alors, juste un tuyau; Les polices des anciens jeux sont toujours des bitmaps, jamais des polices vectorielles. Donc elles sont enregistrées sous la forme d'images 2 couleurs; un bit à 0 indiquant pixel transparent et un bit à 1 indiquant pixel de la couleur d'écriture. Donc un octet pourra représenter les 8 pixels d'une ligne d'un caractère.
Là aussi, c'est par essais de modification manuelle d'un fichier que l'on peut arriver à comprendre la structure des polices.
Sons: Tout d'abord, il faut repérer ces sons parmi les archives.
Pour les sons 8 bits on trouvera des suites d'octets qui tournent autour de la valeur moyenne 80h.
Parfois autour de la valeur moyenne 0, c'est à dire 00h, 01h, FFh, 02h, FEh, ...
Pour les sons 16 bits, regardez en hexa un fichier WAV standard pour voir son apparence.
Mono ou stéréo: Là, il faut écouter les sons dans le jeu pour le détecter et ensuite regarder dans l'entête des ressources s'il y a un octet qui correspond.
Fréquence d'échantillonnage: Quelques fréquences standard sont 11025, 22050, 44100 Hz.
On pourra retrouver ces fréquences dans l'entête de la ressource son ou pas du tout ou carrément une fréquence bâtarde. Là aussi il faut faire des essais.
Musiques: Elles sont très difficiles à repérer si elles ne contiennent pas des entêtes standard, donc procéder par élimination une fois les autres ressources décortiquées.
Niveau 3:
Prérequis: être à l'aise en assembleur. (ou le devenir)
A partir des techniques de désassemblage et de débuggage d'un programme il n'y a plus aucune limite aux modifications que l'on peut opérer dans celui-ci.
Bon, c'est tout pour l'instant.
A suivre ...
Merci.
)
Commentaire