Comment fonctionnent les émulateurs pour PlayStation, Xbox, Windows... ?

Qu'est-ce qu'un émulateur ? Un programme qui « traduit » un appareil en un autre, comme on convertirait un fichier .docx en .pdf ? Si c'était aussi simple, on aurait un émulateur le jour de la sortie de chaque console, mais ce n'est pas le cas. On attend des années, voire on n'en a jamais. C'est l'un des défis les plus complexes de la programmation.

Un émulateur n'est pas un simple convertisseur, mais une version logicielle de l'appareil complet. Processeur, carte graphique, mémoire, puce son et système d'exploitation doivent tous fonctionner de concert, en temps réel et avec une précision telle que le jeu ou le programme ne perçoive aucune différence.

Où commence le développement ? D'où les développeurs tirent-ils l'idée de développer ?

Les développeurs d'émulateurs n'ont quasiment jamais accès à la documentation technique officielle des fabricants de consoles. Sony, Microsoft et Nintendo ne communiquent pas leurs spécifications internes. Au contraire, ils protègent ces informations comme un secret commercial. C'est pourquoi chaque projet commence par une étape appelée « rétro-ingénierie » dans le secteur. Concrètement, les développeurs prennent le matériel d'origine, le démontent, analysent les circuits électroniques, interceptent les signaux entre les puces et reconstituent progressivement le fonctionnement du processeur pour chaque commande du code matériel du firmware (c'est-à-dire le logiciel intégré à l'appareil).

Cela implique souvent une approche de « salle blanche ». Une équipe analyse et documente le fonctionnement de l'appareil, tandis qu'une autre utilise cette documentation, sans jamais avoir accès au code source original du fabricant, pour écrire un nouveau programme qui reproduit ce comportement. Cette séparation n'est pas qu'une simple formalité technique, mais une garantie légale, car l'émulation en elle-même n'est pas illégale, contrairement à la copie du code propriétaire d'un fabricant. De plus, les développeurs ont besoin du BIOS ou du firmware d'origine de la console, le programme de démarrage de base qui contrôle le matériel. Les utilisateurs doivent généralement se le procurer eux-mêmes, souvent directement depuis leur console, car sa distribution avec l'émulateur est interdite.

Ce qu'un développeur doit savoir?

Si vous avez déjà lu ou si vous lirez les journaux de développement d'émulateurs comme RPCS3 pour PlayStation 3 ou Eden pour Nintendo Switch, vous comprendrez vite que ce type de développement nécessite une équipe importante, et non une seule personne. Il faut maîtriser un large éventail de compétences.

Cela exige une compréhension approfondie de l'architecture du processeur, qu'il s'agisse de PowerPC (le processeur de la Xbox 360), d'ARM, de MIPS ou de x86, incluant toutes ses instructions, ses registres et ses spécificités de synchronisation. Il est également nécessaire de maîtriser le fonctionnement du GPU et de traduire ses instructions en interfaces graphiques modernes telles que Vulkan ou DirectX. Cela implique l'émulation de la puce son, des manettes, de l'architecture mémoire et du système d'exploitation de la console, qui gère les fichiers, les threads et les droits d'accès.

Le principal défi technique réside souvent dans la recompilation dynamique, également appelée compilation à la volée (JIT). Au lieu d'interpréter chaque commande de la console d'origine une par une, ce qui serait beaucoup trop lent, l'émulateur les traduit en temps réel en code machine pour le processeur hôte, les exécutant à une vitesse quasi native. Cela exige une connaissance extrêmement précise des deux architectures simultanément, et le résultat doit être identique au bit près à l'original, sous peine de voir le jeu se figer, planter ou afficher des graphismes incorrects.

Pourquoi le développement prend-il des années, voire des décennies ?

La réponse se trouve en grande partie dans un seul exemple : la PlayStation 3. Son processeur Cell, développé conjointement par Sony, Toshiba et IBM, n’était pas un processeur multicœur classique, mais une unité de traitement principale (PPU) unique associée à huit unités de traitement auxiliaires (SPU), chacune disposant de sa propre petite mémoire locale et sans accès direct à la mémoire système principale. Les programmeurs de jeux devaient répartir manuellement la charge de travail entre ces unités, car aucun compilateur ne le faisait automatiquement. De ce fait, un émulateur ne pouvait pas simplement compiler le code comme il l’aurait fait pour un processeur plus conventionnel.

Il est essentiel de comprendre la finalité de ce code extrêmement spécifique et optimisé manuellement. Les développeurs de RPCS3 ont dû concevoir un processeur qui remettait en question la quasi-totalité des principes de l'architecture x86 concernant la mémoire, la cohérence des données et les threads, afin de forcer l'exécution de leurs programmes sur un matériel présentant peu de points communs avec Cell. Le premier prototype public de l'émulateur est apparu en 2011 et, même aujourd'hui, plus de dix ans après, l'équipe annonce encore occasionnellement des avancées majeures en matière d'optimisation, qui permettent désormais d'accélérer significativement des parties de jeux auparavant injouables ou présentant de sérieux problèmes.

La Xbox 360 présente un défi similaire, quoique légèrement différent. Le développement de l'émulateur Xenia a débuté en 2013 et a permis la sortie relativement rapide de son premier jeu commercial. Cependant, dès 2018, les développeurs étaient confrontés à la difficulté d'émuler fidèlement le GPU Xenos, ce qui a nécessité près de trois ans de réécriture complète du code graphique avant d'obtenir une amélioration significative des performances. Ces longs cycles de développement ne s'expliquent ni par la paresse ni par un manque de compétences, mais par la complexité de l'émulateur, qui doit gérer des milliers de cas particuliers, de commandes spécifiques, de bugs du matériel d'origine exploités, sciemment ou non, par les développeurs, ainsi que des particularités de synchronisation non documentées, faute de documentation officielle.

Un autre facteur est la pression juridique. Nintendo est particulièrement connu pour son recours aux tribunaux. En février 2024, l'entreprise a intenté un procès aux développeurs du célèbre émulateur Yuzu, les accusant d'avoir contourné illégalement le système de cryptage de la Switch, comme en témoigne le million de téléchargements de Zelda : Tears of the Kingdom avant sa sortie officielle.

Tropic Haze, la société à l'origine de Yuzu, a accepté un accord à l'amiable de 2,4 millions de dollars et a définitivement fermé l'émulateur. Peu après, Nintendo a également contacté personnellement le développeur principal du projet concurrent Ryujinx pour lui ordonner d'arrêter le développement, de dissoudre l'organisation et de saisir tous les actifs associés. Ces cas illustrent clairement pourquoi de nombreux développeurs talentueux préfèrent se concentrer sur les consoles plus anciennes, considérées comme plus « sûres », tandis que les nouveaux projets restent souvent anonymes ou dispersés entre plusieurs branches parallèles du même projet original.

Pourquoi certaines consoles sont-elles plus difficiles à pirater que d'autres ?

En règle générale, plus l'architecture interne d'une console ressemble à celle d'un PC standard, plus son émulation est aisée. Les PlayStation 1 et 2 utilisent des processeurs relativement classiques ; elles ont donc été émulées assez tôt et fonctionnent aujourd'hui sans problème même sur du matériel plus modeste. En revanche, lorsque les constructeurs intègrent leurs propres solutions non standard, comme Cell sur la PS3, la complexité augmente de façon exponentielle. De même, la Nintendo Switch, basée sur une puce Tegra personnalisée de Nvidia, présente des particularités en matière de gestion de la mémoire et des graphismes.

La situation est encore plus complexe avec la dernière génération, la PlayStation 5 et les Xbox Series X/S, car ces systèmes, bien que plus proches architecturalement des ordinateurs modernes (processeurs AMD Zen et cartes graphiques RDNA), sont protégés par des mécanismes de sécurité bien plus avancés que ceux des générations précédentes. Actuellement, il n'existe pratiquement aucun émulateur fonctionnel pour ces deux consoles, les développeurs s'efforçant encore de contourner leurs systèmes de sécurité de base, un défi bien différent et beaucoup plus long que l'émulation matérielle classique.

L'émulation sur téléphone et sur ordinateur, y a-t-il des différences ?

L'émulation sur appareils mobiles présente une difficulté supplémentaire souvent invisible pour les utilisateurs : la différence entre l'architecture du processeur ARM, qui équipe la quasi-totalité des téléphones, et l'architecture x86, standard sur les PC. Ainsi, lorsqu'on exécute un émulateur de console x86 ou PowerPC sur un téléphone, le programme doit simultanément traduire les instructions de l'architecture d'origine vers ARM, ce qui représente une charge de calcul supplémentaire inutile sur PC, où le processeur hôte est généralement déjà x86.

De plus, Apple a pratiquement interdit les émulateurs sur iPhone jusqu'à récemment. Ce n'est qu'en avril 2024 qu'Apple a explicitement autorisé les émulateurs de consoles de jeux rétro dans les règles de l'App Store, qui peuvent désormais proposer des téléchargements de jeux. Auparavant, la seule façon d'obtenir de l'émulation sur iPhone était soit de jailbreaker l'appareil, soit de contourner la restriction via des applications web.

Même après cette modification, des limitations persistent. Pour des raisons de sécurité, iOS restreint strictement la compilation JIT (à la volée), c'est-à-dire la génération dynamique de code machine pendant l'exécution du programme, principale technique permettant d'atteindre une vitesse acceptable pour les émulateurs les plus exigeants. De ce fait, de nombreux émulateurs sur iPhone sont nettement plus lents que leurs équivalents sur Android, où ces restrictions sont largement inexistantes et où les développeurs bénéficient d'un accès plus libre aux ressources système depuis de nombreuses années.

Existe-t-il un émulateur Windows ? Winlator, GameHub, GameNative…

Si vous lisez mes tests de téléphones, vous remarquerez que j'y inclus souvent des tests de divers jeux Windows, en plus des jeux Android et Nintendo Switch. Dans ce cas précis, le terme « émulateur » n'est pas tout à fait exact d'un point de vue technique. Il s'agit plutôt d'un ensemble de couches de compatibilité superposées.

Winlator est une application libre et open source développée par BrunoSX (brunodev85) qui permet d'exécuter des applications et des jeux Windows (x86_64) directement sur les appareils Android basés sur ARM, sans BIOS, sans installation de Windows et sans image disque. Winlator combine deux technologies distinctes, chacune répondant à un besoin spécifique. La première est Wine, un projet bien connu qui traduit depuis des décennies les appels d'API Windows (commandes pour ouvrir des fichiers, accéder au registre, afficher des graphismes via Direct3D ou lire du son) en commandes compréhensibles par le noyau Linux sur lequel Android s'exécute.

La seconde technologie, Box86 ou Box64, remplit une fonction encore plus fondamentale : la traduction en temps réel des instructions du processeur de l’architecture x86 vers l’architecture ARM, puisqu’aucun téléphone ne possède physiquement de processeur x86. À cela s’ajoute une couche graphique. Winlator utilise le pilote Mesin Turnip pour les GPU Adreno ainsi que les outils DXVK et VKD3D, qui traduisent les appels DirectX en Vulkan, à l’instar de Proton sous Linux.

L'utilisateur crée au sein de l'application ce qu'on appelle un conteneur, une sorte d'environnement virtuel isolé dans lequel il définit séparément la résolution, la quantité virtuelle de VRAM, le nombre de cœurs de processeur et les pilotes pour chaque jeu ou programme.

Du fait des deux traductions consécutives (d'abord les appels API, puis les commandes du processeur), la charge sur le matériel du téléphone est bien plus importante qu'avec l'émulation de consoles classiques. C'est aussi pourquoi Winlator fonctionne relativement bien avec les jeux anciens ou peu gourmands en ressources, mais qu'avec les jeux AAA modernes dotés de moteurs graphiques exigeants comme Unreal Engine, des saccades lors de la compilation des shaders et une surchauffe importante de l'appareil sont fréquentes. Jusqu'à présent, le RedMagic 11S Pro est celui qui a le mieux géré la chaleur, mais il a dû recourir à un ventilateur et à un système de refroidissement liquide.

GameHub et GameNative sont-ils différents ?

Lorsque Winlator a acquis une certaine popularité, des concurrents ont commencé à émerger, utilisant fondamentalement la même recette technologique (Wine, Box64, Vulkan), mais différant par le degré de convivialité de leur interface.

GameNative est issu du projet Pluvia, un client Steam non officiel qui permettait aux utilisateurs de se connecter à leur compte Steam via Winlator et de lancer directement des jeux depuis leur bibliothèque, sans avoir à rechercher manuellement les fichiers d'installation en ligne. Créé comme un projet dérivé de Pluvia, GameNative est actuellement développé plus rapidement et plus activement que le projet original.

GameHub a une origine légèrement différente. L'application, anciennement connue sous le nom de GameFusion, est développée par Gamesir, fabricant chinois de manettes de jeu, et son principal atout réside dans sa simplicité d'utilisation. Elle prend en charge la connexion Steam, contrairement à Winlator (la version officielle), ainsi que les vibrations des manettes. Étant donné qu'il s'agit d'un produit d'un fabricant chinois de matériel, des inquiétudes concernant la protection de la vie privée ont émergé au sein de la communauté. Une version appelée GameHub Lite, sans système de suivi intégré, a donc été créée.

Vaut-il mieux émuler le résultat ou l'appareil entier ?

Les émulateurs n'ont pas toujours besoin de recréer chaque transistor du système d'origine. Ils utilisent souvent une approche d'émulation de haut niveau (HLE). Au lieu d'émuler en détail un composant matériel ou un logiciel système complet, l'émulateur identifie le comportement attendu du jeu et le reproduit à l'aide de sa propre implémentation.

L'inverse est l'émulation de bas niveau (LLE), où le développeur tente de se rapprocher au plus près du comportement réel du matériel ou du micrologiciel d'origine.

L'implémentation HLE peut être considérablement plus rapide. Le problème survient lorsque le jeu n'utilise pas une fonctionnalité comme prévu. Si un développeur découvre une particularité non documentée du système d'origine et l'exploite intentionnellement, une implémentation HLE élégante pourrait se comporter de manière « logique », tandis que la console d'origine aurait un comportement totalement différent.

Pourquoi un jeu fonctionne-t-il parfaitement alors qu'un autre ne se lance même pas ?

Si un émulateur peut émuler une PlayStation 2, pourquoi le choix du jeu PS2 lancé devrait-il importer ? Parce qu’aucun jeu n’utilise la console exactement de la même manière.

Un jeu peut se contenter des fonctionnalités graphiques les plus courantes, tandis qu'un autre utilise des techniques de fusion inhabituelles. L'un emploie des calculs en virgule flottante standard, l'autre un système d'arrondi très spécifique. L'un utilise une manette standard, l'autre un microphone ou un accessoire spécial. Un troisième peut contenir un moteur de jeu dont le fonctionnement dépend involontairement de la synchronisation précise d'une opération du processeur.

Par conséquent, tester un émulateur ne revient pas à tester une application classique. Un test de régression vraiment efficace consiste à utiliser une bibliothèque de centaines, voire de milliers de jeux.

Puis arrive un correctif qui, enfin, permet à un jeu de fonctionner correctement, mais en rend trois autres inutilisables.

Paradoxalement, la « contrefaçon » est souvent meilleure que l'original.

Lorsqu'un émulateur est suffisamment précis, il peut arriver que le jeu émulé soit plus beau et plus performant que l'original.

Un jeu conçu pour la résolution 480p peut être affiché en 1440p ou en 4K grâce à un émulateur. Ce dernier peut rendre la géométrie à une résolution native supérieure, améliorer le filtrage des textures, utiliser un anticrénelage moderne, corriger le format d'image et, dans certains cas, supprimer la limite de fréquence d'images d'origine. L'émulateur propose des sauvegardes rapides, le retour en arrière dans le temps, des textures alternatives, des correctifs et des modifications inédites par rapport à la console originale.

Parfois, l'émulateur fonctionne mieux sous Linux que sous Windows.

De nombreux émulateurs et couches de traduction, comme Proton, fonctionnent mieux sous Linux. Cela s'explique principalement par la manière dont le système d'exploitation communique avec le matériel. Vulkan, une interface graphique moderne et ouverte, offre une utilisation du processeur réduite et un contrôle plus direct de la carte graphique que les approches plus anciennes, mais encore couramment utilisées, sous Windows. De plus, les pilotes Linux pour Vulkan ont considérablement évolué ces dernières années, au point d'engendrer souvent une charge système inférieure à celle de Windows.

De plus, l'outil DXVK, intégré à Proton, traduit les appels DirectX en Vulkan en temps réel, ce qui est souvent étonnamment plus rapide que si Windows exécutait directement l'appel DirectX natif. En effet, il évite certaines couches du système d'exploitation qui n'existent tout simplement pas sous Linux. Linux permet également une latence plus faible dans la communication interprocessus et une planification des threads plus prévisible au sein du noyau, un atout précieux pour les émulateurs qui doivent coordonner des dizaines de tâches parallèles à chaque image.

Pour se lancer dans le développement d'émulateurs, il faut être à la fois un maître et un fou.

Pendant que vous jonglez avec les commandes du processeur, les appels d'API, les mécanismes de sécurité, et que vous espérez secrètement que Sony et Nintendo ne viendront pas frapper à votre porte, vous devez aussi faire face aux attentes élevées de la communauté pour laquelle vous développez un émulateur sans aucune contrepartie financière. Une minorité, cependant, très bruyante, nourrit souvent des attentes démesurées et infondées, pensant que développer un tel logiciel est relativement facile. S'il existe un émulateur pour la Nintendo Switch, développer un émulateur pour la Nintendo Switch 2 ne devrait pas être si difficile, n'est-ce pas ?

Chaque nouvelle avancée majeure implique en réalité des mois de recherche de bugs, de lecture de dumps hexadécimaux de code machine et de tentatives de compréhension des décisions prises par les ingénieurs d'aujourd'hui et d'hier qui ont écrit du code il y a vingt ans sans imaginer que quelqu'un essaierait un jour de le recréer sur un matériel complètement différent.

C’est cette combinaison d’obstination, de curiosité et d’amour pour la préservation du patrimoine vidéoludique qui est à l’origine de l’émulation et qui explique pourquoi la bataille pour chaque nouvelle génération de consoles recommence presque entièrement à zéro.