Contexte du projet

Le dépôt adonis-singh/re4 propose une reconstruction complète du build de débogage G4BE08 de Resident Evil 4 pour la Nintendo GameCube, daté du 25 novembre 2004. Le projet reproduit le fichier main.dol et les 114 modules REL à l’identique, comme le montre le fichier config/G4BE08/build.sha1 qui valide chaque construction. Au total, plus de 1 083 objets (675 dans le DOL, 408 dans les REL) et 15 641 fonctions sont générés, à partir d’environ 555 000 lignes de code C/C++ et 33 000 lignes d’en‑têtes.

Méthodologie de reconstruction

Le code source est organisé en répertoires src/ (logique du jeu) et include/ (structures et prototypes). La compilation s’effectue sous Linux avec Python 3, Ninja et les compilateurs originaux : SN Systems ProDG 3.9.3 (GCC 2.95.3) et Metrowerks CodeWarrior 2.4.7/GC 1.2.5n. Le processus démarre par la commande suivante, qui télécharge les outils nécessaires et prépare les images de disque :

python3 configure.py && ninja

Les images ISO des deux disques de débogage sont requises ; elles sont copiées dans orig/G4BE08/ avant la configuration. Les scripts Python tools/bytecmp.py et tools/fdiff.py comparent chaque objet généré avec le binaire original, garantissant une correspondance octet à octet.

Analyse des contraintes de compilation

Obtenir une correspondance exacte nécessite de reproduire les choix de registre et les ordonnancements d’instructions propres aux compilateurs historiques. Lorsque le compilateur impose une forme de source particulière, les développeurs insèrent des commentaires // COMPILER-DIFF: (644 occurrences) pour forcer le même résultat, par exemple en utilisant asm("rN") afin de contraindre un registre. Aucun de ces fragments n’émet d’instruction supplémentaire ; le script tools/asmcheck.py confirme que seules 231 instructions proviennent de modèles asm, toutes liées aux kernels matériels.

Le projet documente également les mécanismes de chaque compilateur dans docs/matching.md, détaillant comment les différences de génération de code sont neutralisées. Cette approche montre les limites de la rétro‑ingénierie : sans accès aux sources originales, il faut souvent recourir à des constructions artificielles pour reproduire fidèlement le binaire.

Implications et limites

La décompilation fournit une base exploitable pour la recherche académique sur les moteurs de jeu de l’époque et pour le portage vers d’autres plateformes. Cependant, le dépôt ne contient aucun asset du jeu ; les textures, modèles et sons restent propriétaires et doivent être extraits séparément. De plus, la dépendance aux compilateurs originaux rend la reproduction difficile sur des environnements modernes sans les sources GPL de SN Systems. Malgré ces contraintes, le projet démontre qu’une reconstruction byte‑identique est possible grâce à une combinaison d’analyse statique, de scripts de comparaison et de modifications ciblées du code source.