« GoldenEye 007 est décompilé à 100 % » ressemble à une phrase très simple. Elle donne presque l’impression qu’un programme a avalé la cartouche Nintendo 64, puis recraché le dossier source que Rare avait sur ses machines en 1997.

Ce n’est pas ce qui s’est passé.

Le projet communautaire a reconstruit une représentation source du programme suffisamment précise pour reproduire les versions commerciales visées. Le dépôt peut construire les ROM américaine, japonaise et européenne et vérifie leurs empreintes SHA-1 attendues.1 Son site de suivi indique désormais que la décompilation a atteint son objectif complet.2

C’est un résultat beaucoup plus intéressant qu’une simple conversion automatique, justement parce que le code original n’était pas disponible.

Décompiler n’est pas retrouver les fichiers de Rare

Une cartouche contient les instructions machine destinées au processeur de la Nintendo 64. Autour se trouvent images, sons, autres ressources et toute l’organisation produite par les outils de compilation de l’époque. Ce binaire ne conserve pas gentiment les noms de variables, les commentaires, l’intention du programmeur ou la structure exacte des fichiers sources.

Le travail de décompilation consiste à remonter depuis ce résultat vers une source lisible qui explique le même comportement. Dans un projet dit matching, l’objectif va encore plus loin : le code reconstruit doit, lorsqu’il est compilé dans les bonnes conditions, produire le même binaire que l’original.

Le dépôt de décompilation de Perfect Dark, autre projet N64 de la même communauté, donne la définition sans détour : avec le compilateur utilisé par les développeurs d’origine, une matching decompilation produit un résultat identique au jeu commercial, octet pour octet.3

GoldenEye suit cette logique. Son build utilise notamment l’ancien compilateur IDO et compare la ROM générée aux hashes connus des versions US, JP et PAL.1

Le hash est une preuve beaucoup plus exigeante qu’un jeu qui « a l’air de marcher »

Si une réécriture lance la première mission, affiche les bons ennemis et permet de terminer le jeu, elle peut sembler fidèle. Pourtant, des milliers de détails internes peuvent encore différer : ordre des instructions, calculs, disposition en mémoire, branchements ou comportement dans des cas rares.

Le matching impose une contrainte plus sévère. Le build doit retrouver le résultat attendu du compilateur, pas seulement un comportement visuellement similaire.

Cela transforme la décompilation en problème presque archéologique. Une fonction peut être comprise dans son principe et rester non matching parce qu’une boucle est écrite différemment, qu’un type n’est pas le bon ou que le compilateur choisit alors une autre séquence d’instructions. Il faut parfois réécrire du C qui paraît moins élégant simplement parce que cette forme correspond mieux au binaire de 1997.

Le « 100 % » marque donc l’achèvement d’une métrique très précise du projet. Ce n’est pas une note de qualité générale donnée au code reconstruit.

Les noms symboliques peuvent avoir été retrouvés, déduits ou recréés. Les commentaires ne réapparaissent pas depuis le silicium. Certaines structures restent documentées progressivement. Le README principal appelle d’ailleurs encore le dépôt une décompilation « WIP », alors même qu’il sait reconstruire les trois ROM ciblées.1

Une base peut être entièrement matching et continuer à être nettoyée, renommée, documentée ou adaptée. Les humains, dans un élan de complication tout à fait prévisible, ont plusieurs définitions possibles du mot « fini ».

Les assets ne sont pas soudain devenus libres

Autre malentendu facile : disposer du dépôt ne revient pas à télécharger GoldenEye 007 sous forme de projet prêt à distribuer.

Le README précise que le dépôt ne contient pas tous les assets nécessaires à la compilation. L’utilisateur doit fournir sa propre copie non modifiée de la ROM, puis les scripts extraient les éléments requis pour le build.1

Cette séparation est fondamentale pour comprendre la structure du projet. D’un côté se trouvent la reconstruction logicielle, les outils, les symboles et le système de build. De l’autre restent des contenus issus du jeu commercial : graphismes, sons, modèles, textes et autres données que le dépôt ne fournit pas intégralement.

Cela ne résout pas d’un coup toutes les questions de droits liées à la décompilation. En revanche, ça explique pourquoi un projet de préservation peut être techniquement très complet sans devenir pour autant une distribution complète du jeu.

Le build demande encore la cartouche sous forme de ROM détenue par l’utilisateur. Le dépôt permet d’étudier cette machine logicielle et de la reconstruire autour des ressources extraites.

Pourquoi cinq ans pour obtenir du C alors que des désassembleurs existent depuis longtemps ?

Un désassembleur peut transformer les instructions machine en assembleur et donner rapidement une première carte du programme. Cela ne suffit pas pour retrouver une source maintenable et matching.

Il faut retrouver où commencent et finissent les fonctions, puis reconnaître les zones qui portent les ressources. Viennent ensuite les appels vers les bibliothèques de la console, les structures, les états globaux et les relations entre systèmes. Ensuite vient le travail ingrat : écrire une version en C, compiler, comparer, comprendre pourquoi quelques instructions diffèrent, recommencer.

GoldenEye ajoute sa propre complexité. Le dépôt réunit les fonctions principales du jeu, sa routine de décompression, les bibliothèques Nintendo utilisées ou modifiées par Rare et les programmes RSP spécifiques au traitement graphique.1 Le binaire final est donc le produit de plusieurs couches historiques, pas d’un unique fichier C qu’il suffirait de traduire à l’envers.

Cette lenteur explique aussi la valeur documentaire du résultat. À mesure que le binaire devient un ensemble de fonctions nommées et reliées, un jeu auparavant étudié surtout depuis son comportement externe devient inspectable comme système logiciel.

On peut suivre le comportement des ennemis, les armes, les missions, le rendu ou la manière dont les objets circulent dans le programme, au lieu d’observer seulement la mémoire d’un émulateur. Le jeu commence à ressembler de nouveau à un programme sur lequel on peut travailler.

Le port PC n’est pas la même étape

La conséquence la plus visible d’une décompilation complète sera probablement la multiplication des ports et des modifications. Mais là encore, le raccourci « 100 % = version PC terminée » ne tient pas.

KholdFuzion maintient déjà GoldenRecomp, un chantier de recompilation native basé sur le travail de décompilation.4 Son README décrit un jeu fonctionnel et stable dans l’état de développement actuel, tout en listant encore plusieurs problèmes avant une éventuelle publication : interface multijoueur, rendu de certains ciels et effets d’eau, cadence de tir liée au 60 Hz natif, contrôles analogiques modernes.4

Le projet doit aussi modifier certains aspects de GoldenEye pour les faire entrer dans les contraintes de N64Recomp. Le README mentionne notamment le retrait de l’usage du TLB dans une branche dédiée et des adaptations du recompiler pour des tables de saut particulières.4

Voilà la différence utile.

La décompilation demande : pouvons-nous reconstruire fidèlement le programme original ?

Le port demande ensuite : comment faire vivre ce programme dans un environnement qui n’est plus la Nintendo 64 ?

Ce deuxième problème inclut le rendu, l’audio, les contrôleurs, le timing, les systèmes modernes et tout ce que le matériel original garantissait implicitement.

Le vrai gain est de rendre le jeu transformable sans perdre sa référence

Une ROM conserve fidèlement le produit livré. Elle contient exactement ce qui a été vendu, mais elle reste difficile à modifier de manière structurée.

Une décompilation matching ajoute une autre forme d’archive : une description lisible dont on peut vérifier qu’elle revient au même binaire lorsqu’on la recompile dans les conditions prévues.

Cette propriété est précieuse pour la conservation, parce qu’elle relie deux besoins souvent opposés. On veut garder une référence exacte au jeu original, mais on veut aussi pouvoir comprendre son fonctionnement, corriger un bug, expérimenter, documenter ou préparer une adaptation à un autre système.

Le matching donne un point fixe. Une modification peut s’en éloigner volontairement, tout en sachant précisément d’où elle part.

C’est aussi ce qui rend le « 100 % » moins spectaculaire et plus important que le titre ne le laisse penser. Rien n’a ressuscité le dépôt source de Rare. Rien n’a transformé les assets du jeu en bien commun. Aucun port moderne n’est automatiquement terminé.

En revanche, un groupe de personnes a reconstruit assez précisément le programme d’un jeu de 1997 pour que les outils puissent repartir d’une source lisible plutôt que seulement du binaire.

Pour la préservation logicielle, c’est un changement de matière première.