Si vous avez déjà tenté l’expérience, vous voyez de quoi nous vous causons : jouer à un jeu ancien est souvent une chose compliquée, voire impossible. Entre les pilotes plus à jour, les OS non rétrocompatibles ou encore la difficulté de se trouver du matériel (et son prix !), sans parler des jeux en eux-mêmes : le retrogaming, c’est cher ! Mais il existe une autre possibilité pour les bidouilleurs : l’émulation. Outre le flou juridique (voire l’illégalité complète) de la chose, du côté des performances, toutes les consoles sont loin d’être au même niveau. Et pour cause : le principe de l’émulation se base sur l’interprétation du langage de la console ciblée.
Ainsi, votre PC (ou smartphone, vu leur puissance !) va aller reproduire l’état interne du processeur et le modifier en décodant une à une les instructions machines et en reproduisant leur comportement, d’où le terme d’émulation. Pour accélérer la chose, ces instructions sont souvent traduites au fur est à mesure qu’elles sont rencontrées : on parle alors de compilation à la volée ou juste à temps, une technique qui a le désavantage de perdre du temps lors de cette traduction. Si la performance galopante des puces contemporaines permet d’atteindre des conditions acceptables de jeu, ce n’est pas le cas de toutes les machines ; d’où le développement par des petits malins bien motivés d’une autre technique : la recompilation., ce que propose le projet N64Recompiled pour, vous l’aurez deviné, la Nintendo 64. À l’aide de l’outil et d’une bonne dose de code, Majora's Mask (et, à terme, Ocarina of Time) est disponible dans une version native x86, pour notre plus grand bonheur. Attention, il faudra par contre une ROM nord-américaine du jeu pour fonctionner, histoire que la légalité du procédé reste dans la zone grise en suivant la rhétorique de « nous vendons un outil de traduction, les droits d’auteur du jeu ne s’y appliquent donc pas » (un argument qui a par ailleurs récemment été invoqué dans l’affaire Yuzu).
Pourtant, ici, il n’est ni question d’interprétation, ni de reverse engineering (i. e de compréhension par un humain du code assembleur, avant de le réécrire/transformer automatiquement dans un langage « standard » de programmation) dans d’une traduction statique — comprendre « sans avoir à lancer le jeu », c’est à dire directe ! — du langage de la console en langage hôte. Une méthode qui permet ainsi de gagner en performances puisque l’étape de la traduction est totalement absente, mais qui n’est pas magique : une partie de la console reste émulée, l’opération est donc au niveau des performances entre le reverse engineering et l’émulation. Rajoutez qu’une bonne couche de compatibilité doit être présente, que ce soit pour gérer les périphériques d’entrée ou la pile graphique, ici en passant par Vulkan. Reste que la flexibilité de patching lié à la technique, et la perspective d’avoir un bon vieux .exe est ô combien alléchante… à voir si le projet prend, en particulier au niveau de sa compatibilité !
Par ici pour le GitHub de la recompilation de Zelda 64
Et par là pour N64 : Recompiled
Ca marche bien.
Je joue à Perfect Dark N64 au clavier / souris sans aucun problème sans installation, juste à lancer le .exe
Dans le petit fichier ini on peut même régler la résolution etc. Aucun bug, aucune latence et l'écran divisé fonctionne (donc sur un même ordinateur on peut avoir 1 clavier/souris + 3 manettes)
Est-ce la méthode utiliser sur la SteamDeck via "Proton" ? Quand Valve avait des années avant essayer de lancer ses tours sous Steam-Os, voir le Steam-Os à installer sur sa tour ou en dual-bot avec Windows, ça avait été un échec commerciale car de cette façon, seul les jeux compatible avec Linux pouvait tourner or ils y en avaient très peu.
Avec la SteamDeck, Valve à trouvé le moyen de rendre compatible tout ou presque du catalogue Steam et de jeux pour Windows grace au logiciel open-source : "Proton".
Non, Proton se base sur Wine, DXVK et VKD3D pour traduire à la volée les instructions Windows et DirectX en instructions GNU Linux et OpenGL/Vulkan.
Je me permets de compléter / corriger la reponse de Necro : sur Proton il s'agit d'une couche de compatibilité : les instructions du jeu sont déjà prévues pour l'architecture x86. En revanche, la manière de communoqier avec le système hôte (syscalls) n'est pas pareil, tout comme la pile graphique. Du coup, ces syscalls sont bien émulés, eux (pas le choix, en fait, la recompilation serait trop complexe), alors que les shaders sont traduits ou recompilés de DirectX en Vulkan (je suis moins sûr sur cette partie). De ce fait, la performanxe au niveau CPU est meilleure qu'une émulation, et niveau GPU cela dépend énormément des optimisations effectuées par le compilateur, et des pilotes.
Merci, je n'aurais pas mieux dit 👍
Wine n'est pas un émulateur, et pourtant.... il émule bien Windows 🤪
Wine pour Wine Is Not an Emulator 😝. C'est parce que l'émulation est vue comme l'interprétation / compilation à la volée des instructions, ce que Wine ne fait pas ;)
Nous dirons donc que c'est un émulateur partiel 😅
... qui a mis un peu d'eau dans son vin 🤣