Presque tous les jeux Nintendo 64 peuvent désormais être recompilés en ports PC natifs
(tomshardware.com)- Les jeux Nintendo 64 sortis en 1996 peuvent désormais être recompilés en ports PC natifs au lieu d’être émulés, ce qui permet d’ajouter des améliorations comme le ray tracing, l’ultrawide et un framerate élevé
- N64Recomp et Zelda64Recomp, publiés sur GitHub par Mr-Wiseguy, sont les outils clés ; Zelda64Recomp porte The Legend of Zelda: Majora's Mask sur PC
- Cette approche diffère du port PC de Super Mario 64 basé sur une décompilation complète, publié en 2020, mais les deux s’exécutent nativement sur PC et peuvent améliorer les performances ainsi que la précision des effets
- Alors qu’une décompilation manuelle exige des années de travail par une ou plusieurs personnes, N64Recomp propose une approche pour convertir plus rapidement les jeux N64 en une forme exécutable sur PC
- Le résultat n’inclut pas les assets, un ROM est donc nécessaire pour jouer ; Banjo-Kazooie, Rocket Robot et Superman 64 sont aussi cités comme exemples de fonctionnement
Évolution de la manière de porter les jeux N64
- En 2024, le matériel d’origine de la Nintendo 64 et ses jeux continuent de susciter un fort intérêt dans la communauté des passionnés
- L’étape suivante du jeu N64 avancé pourrait ne plus être l’émulation, mais les ports PC recompilés
- Mr-Wiseguy a publié sur GitHub N64Recomp et Zelda64Recomp
- N64Recomp est l’outil de base permettant de transformer des jeux N64 en ports PC natifs
- Zelda64Recomp porte The Legend of Zelda: Majora's Mask sur PC et applique les améliorations graphiques et de confort offertes par N64Recomp
Améliorations possibles sur les ports PC
- Les ports PC recompilés peuvent ajouter aux jeux N64 d’origine des améliorations propres à l’environnement PC
-
Véritable ray tracing
- Déverrouillage de la limite de framerate
- Prise en charge correcte de l’ultrawide
- Améliorations graphiques et de confort attendues sur PC
- Majora's Mask est présenté comme exemple de comparaison en ultrawide entre une exécution en émulation et une recompilation PC native
-
Différences avec le port PC de Super Mario 64
- Le port PC de Super Mario 64 basé sur une décompilation complète, publié en 2020, a permis des fonctionnalités comme le ray tracing et le remplacement complet des modèles, et continue encore aujourd’hui à recevoir des mods
- Les ports recompilés diffèrent dans leur méthode de production des ports par décompilation comme le port PC de SM64
- Les deux approches s’exécutent nativement sur PC, et peuvent à la fois améliorer les performances et la précision des effets par rapport au matériel d’origine, tout en offrant les améliorations typiques du PC que l’on attend de l’émulation
Pourquoi N64Recomp est important
- N64Recomp est un outil qui, avec son approche par recompilation, cherche à réunir les avantages de l’émulation et des ports natifs
- Décompiler manuellement un jeu N64 demande des années de travail à une ou plusieurs personnes
- Un outil capable de convertir plus efficacement des jeux N64 en versions rapidement exécutables sur PC peut aussi être utile aux acteurs de la préservation
RT64 et exemples d’exécution
- Dario est le développeur du plugin RT64, utilisé par N64Recomp et certains émulateurs N64
- D’après le billet de Dario, Wiseguy a travaillé pendant un an, en privé, sur un outil permettant de créer des ports PC de jeux N64 sans décompilation complète
- Le résultat n’inclut pas les assets, et seul le ROM est nécessaire pour jouer
- Les jeux suivants sont cités comme exemples de fonctionnement
- Banjo-Kazooie
- Rocket Robot
- Superman 64
Autres mouvements dans l’écosystème N64
- D’autres avancées continuent également pour les fans de la ludothèque N64 et du matériel d’origine
- L’open source SummerCart64 est une flash cart pour console d’origine, avec prise en charge du 64DD
- Des jeux homebrew N64 et des ROM hacks compatibles avec le vrai matériel continuent aussi d’être publiés
- Smash Remix, qui propose 30 combattants
- Peach's Fury, un projet de réécriture du moteur de Mario 64
2 commentaires
Avis sur Hacker News
Pour utiliser cet outil, il faut toujours d’abord désassembler la ROM, puis ajouter beaucoup de commentaires pour qu’elle puisse être recompilée
L’outil en lui-même est excellent, mais l’idée qu’il transforme presque en un clic une ROM arbitraire en exécutable autonome paraît exagérée
Dans la vidéo du billet, ils ont recompilé un jeu N64 non nommé et il tournait bien, sans qu’il paraisse nécessaire d’ajouter des commentaires particuliers
Une ROM est littéralement en lecture seule, donc on peut imaginer un système où l’on fournit la ROM et on obtient un portage natif
Une conversion binaire vers binaire semblerait plus intuitive, et ne nécessiterait sans doute pas non plus d’intervention humaine
Vraiment génial
Plusieurs outils de base créés pour la décompilation N64 se diffusent vers des packages de décompilation pour d’autres systèmes
J’ai vu récemment https://decomp.me/, qui prend en charge la décompilation collaborative pour plusieurs systèmes avec les SDK associés et des préréglages matériels
J’ai l’impression que cette dynamique va s’étendre à davantage de systèmes dans les prochaines années
J’ai vu ça à sa sortie, et comme je ne suis pas vraiment la scène du ROM hacking, je me demande pourquoi une telle approche est arrivée si tard
Traduire des instructions assembleur en C puis recompiler semble être une méthode évidente à essayer tôt ou tard, donc je me demande s’il y avait auparavant un obstacle majeur qui la rendait impossible, et ce qui l’a levé aujourd’hui
En parcourant rapidement le dépôt GitHub, on dirait qu’ils utilisent rt64 en interne pour le support du ray tracing (https://github.com/rt64/rt64)
rt64 utilise une technique d’ubershaders pour émuler le GPU, et cet excellent article explique ce que sont les ubershaders, pourquoi ils sont nécessaires, et à quel point c’est infernal : https://dolphin-emu.org/blog/2017/07/30/ubershaders/
Faire de la recompilation statique d’un code machine vers un autre langage se situe, en pratique, entre le très difficile et le généralement impossible [1]
Pour bien faire ce type de recompilation, il faut aussi une aide du côté du binaire qui facilite le travail [2], ainsi que des patchs pour le faire fonctionner par-dessus [3]
La recompilation dynamique n’a pas ces problèmes, donc si l’on fournit le binaire original et les ressources, c’est-à-dire la ROM, on peut généralement produire un logiciel qui émule ce programme
Il y a beaucoup de confusion sur le degré de généralité de cette solution
En revanche, c’est extrêmement impressionnant et très précieux pour réduire la charge de travail nécessaire à la recompilation ou au portage, mais cela ne remplace pas la nécessité des émulateurs traditionnels
[1] : https://cs.stackexchange.com/questions/155511/why-is-static-...
[2] : Les binaires des jeux N64 évitent par hasard plusieurs éléments qui rendent la recompilation statique générale difficile, ce qui peut favoriser cette approche, mais je ne le sais pas vraiment
[3] : Le dépôt de recompilation de Majora's Mask contient beaucoup de patchs faits à la main pour que tout fonctionne : https://github.com/Mr-Wiseguy/Zelda64Recomp
Jamulator avait déjà fait ça pour la NES en 2013, mais on dirait que presque personne n’y a prêté attention
https://andrewkelley.me/post/jamulator.html
Il y a aussi Winlator, qui permet d’exécuter des programmes Windows sur Android
https://github.com/brunodev85/winlator
Et la vidéo YouTube liée dans l’article, elle utilise une voix IA ?
Voici ce qui est écrit dans le dépôt GitHub de N64Recomp[0] :
"This is not the first project that uses static recompilation on game console binaries. A well known example is jamulator, which targets NES binaries."
[0]: https://github.com/Mr-Wiseguy/N64Recomp
Dans ce cas, la recompilation ne fait que compliquer les choses sans apporter beaucoup d’avantages
La N64 a un matériel fixe, donc c’est un peu plus simple
Cela dit, ce projet s’appuie encore sur l’émulation pour le RDP
Je ne sais pas comment il gère le microcode RSP généré, et il se peut qu’il ne le gère tout simplement pas
Beaucoup de jeux utilisaient simplement la bibliothèque officielle
S’il était sorti avec des améliorations similaires pour Zelda, il aurait probablement été bien plus populaire
On dirait que l’intérêt vient moins de la méthode elle-même que de ce qu’on peut désormais en faire
La narration de la vidéo est simplement faite par une vraie personne appelée Nerrel
C’est assez surprenant, dans un sens intéressant, de voir à quel point les voix IA sont devenues bonnes : on en vient à soupçonner d’être une IA quelqu’un qui ne parle pas comme on s’y attend
Sa narration a toujours eu un ton tellement plat qu’elle sonnait déjà comme une IA, et j’aime bien l’effet que ça produit mélangé à son humour
Ce serait bien que tous les exécutables de jeux soient indépendants du système d’exploitation, un peu comme WebAssembly
Par exemple quelque chose comme GameAssembly
Sur les versions récentes de macOS, on ne peut plus jouer aux jeux 32 bits, et les jeux Windows 32 bits ne fonctionnent pas non plus avec Wine
Il est presque impossible de trouver des fichiers
.exe64 bits qui tournent correctement avec Wine/CrossoverSur console, surtout pour les anciens titres et les exclusivités de plateforme, on dépend souvent de détails d’implémentation GPU très bas niveau
Les consoles plus anciennes avaient aussi d’autres puces dédiées qui faisaient des tâches importantes au-delà des simples entrées-sorties
Par exemple, la puce audio de la SNES était un CPU totalement indépendant qui exécutait son propre petit programme en parallèle du CPU et du GPU
Bien sûr, on pourrait imposer à l’avenir une machine virtuelle de haut niveau pour tout développement de jeu, mais vu que les spécifications matérielles des consoles sont fixes, ce ne serait probablement pas compétitif pour les titres qui veulent exploiter les graphismes les plus récents
Sur Debian, il fallait lancer :
dpkg --add-architecture i386 && apt-get updateEnsuite, il suffit d’installer le paquet
wine32Les jeux ont besoin de nombreuses API : API graphiques, API de fenêtres, API d’entrée, API audio, API disque, etc.
Parfois, il faut même des modules noyau à cause de l’anti-triche ou de la protection contre la copie
Ce qui est regrettable, c’est que les systèmes d’exploitation open source n’essaient pas de fournir un ensemble commun d’API permettant aux développeurs d’écrire et tester leur code une seule fois pour qu’il fonctionne partout
Il y a bien Flatpak, mais d’après ce que j’en comprends, c’est moins un ensemble d’API qu’un emballage de distributions Linux dans une machine virtuelle, sans réelle spécification ni documentation
C’est assez laid, et ce n’est pas compatible avec les petits systèmes d’exploitation non Linux
J’ai fait tourner GTA IV sur un M1 mini
Il semble que la version 32 bits de Wine installée par PlayOnMac intègre une sorte d’émulation "32 on 64", mais c’est tellement difficile à rechercher que je ne sais pas vraiment comment cela fonctionne
C’est amusant de voir que Mac est plus compatible avec de vieux programmes Windows qu’avec d’anciens programmes Mac
Sans la JVM, je doute que Minecraft aurait pris en charge Linux, les systèmes de type BSD, etc.
La Bedrock Edition, qui n’est pas la version JVM, prend en charge Windows, les consoles et les téléphones, mais pas macOS alors que cela semblerait pourtant tout à fait possible
J’espère que ça finira par fonctionner aussi sous Linux, afin de pouvoir faire tourner des jeux N64 de manière fiable sur des appareils portables très peu puissants
La N64 a la réputation d’être notoirement difficile à émuler, mais avec un build natif pour la plateforme, les problèmes de performances disparaissent
On peut voir des exemples ici : https://github.com/Mr-Wiseguy/Zelda64Recomp?tab=readme-ov-fi...
Je ne connais pas bien les détails de l’émulation N64, mais je fais tourner des émulateurs N64 sans problème depuis le début des années 2010
J’ai surtout joué aux grands classiques, donc je ne sais pas trop ce qu’il en est des performances sur des titres plus de niche
J’y ai joué environ une heure sans rencontrer de problème
Je l’ai testé moi-même
Ça pourrait être assez utile pour des jeux comme GoldenEye
Le jeu suppose des entrées de joystick assez particulières, ce qui le rend difficile à jouer sur PC, donc avoir un portage natif de GoldenEye avec un comportement de souris normal comme dans les autres FPS serait génial
Le système de changement de mode pour la visée, ainsi que le temps que met le curseur à se déplacer puis à revenir au centre, font partie de ce qui rend le jeu intéressant
Si on pouvait courir et viser librement comme dans un FPS PC, ça casserait sans doute la campagne, qui a été conçue en partant de ce principe
Une partie du charme vient du fait de choisir quand s’arrêter pour viser et de garder son sang-froid pendant la visée
Cela dit, ce pourrait être amusant si on gardait le changement de mode, et que la souris 1) faisait pivoter Bond comme le stick gauche/droite et 2) ne contrôlait le curseur qu’en « mode visée » quand on appuie sur R
Honnêtement, je trouve dommage que tous les shooters soient passés directement au schéma Quake avec WASD + visée libre à la souris
Le système de changement de mode donne à GoldenEye une sensation physique que j’aime beaucoup
https://github.com/Graslu/1964GEPD/releases/tag/latest
Ça marche aussi sur Perfect Dark
C’est assez intéressant, mais je me demande si ça pourrait déboucher sur une version de Conker qui fonctionne correctement sur MiSTer
Par exemple, pourrait-on s’en servir pour aider à la décompilation, puis quelqu’un pourrait-il créer une version modifiée ?
Je me demande quel est l’avantage par rapport à un émulateur
Au fond, est-ce que ce n’est pas juste une forme d’émulateur qui traduit à l’avance ?
Ce genre d’approche existait déjà autrefois avec des choses comme Bleem, et ça peut avoir un avantage en performances, mais sur un PC moderne, un bon émulateur fonctionne généralement très bien
https://en.wikipedia.org/wiki/Bleem!
En général, le but d’un émulateur N64 est de reproduire fidèlement le fonctionnement de la console d’origine
À l’inverse, beaucoup de gens veulent jouer à SM64, OOT et MM en 60 fps, en widescreen, avec des texture packs, des randomizers et diverses améliorations graphiques
Pour ces gens-là, le fait que ces jeux tournaient à l’origine sur N64 n’a pratiquement aucune importance
C’est plutôt un obstacle
Le pipeline graphique de la N64 est pénible à émuler et gêne activement les améliorations modernes
Ce projet semble davantage viser à traiter le jeu lui-même de manière moderne et à retirer complètement les éléments centrés sur la N64 de l’équation
Aujourd’hui, les ordinateurs sont devenus tellement plus rapides que la N64 que la différence n’est peut-être plus perceptible
Les émulateurs classiques compilent-ils généralement à l’avance, ou utilisent-ils du JIT ?
Sinon, je me demande pourquoi ils ne le font pas
Cette approche, c’est-à-dire la compilation préalable, semble avoir de gros avantages
En revanche, sauf si TeknoParrot fonctionne de cette manière, je ne sais pas trop ce qu’il en est de la traduction préalable
Par exemple, on peut utiliser TeknoParrot pour faire tourner sous Windows des jeux d’arcade Linux qui utilisent des binaires ELF, mais comme l’architecture est la même, je n’appellerais pas ça de l’émulation dans un cas comme dans l’autre
L’exécution interprétée consiste à écrire une machine virtuelle qui représente les différents états des composants de la machine, puis à exécuter des instructions qui modifient cet état avec des niveaux de précision variables
La puissance des passionnés ! Au-delà de l’ajout d’un compilateur JIT aux émulateurs, on peut désormais même transformer en C via le binary lifting puis recompiler.