Les réglages par jeu : overclock, résolution interne et sauvegardes d'état

Un jeu rame, vous montez l'overclock du processeur émulé, le problème disparaît. Trois jours plus tard, un autre jeu se met à planter au même endroit à chaque fois, et un troisième perd son audio. Le coupable n'est pas la console : c'est le réglage laissé actif pour tout le catalogue. L'émulation ne se règle pas une fois pour toutes. Chaque titre a son moteur, ses habitudes de programmation, ses défauts d'origine. Les frontends prévoient exactement cela : une configuration générale, et des exceptions enregistrées jeu par jeu. Voici comment elles fonctionnent, ce que valent réellement la résolution interne, l'overclock, les états de sauvegarde et le rembobinage, et à quel prix.

Pourquoi un réglage global finit toujours par gêner

Les options d'émulation ne sont presque jamais des améliorations pures. Ce sont des compromis : de la précision contre de la vitesse, de la fidélité contre du confort. Ce qui convient à un jeu ne convient pas au suivant.

L'exemple le plus courant vient des ralentissements d'époque. Beaucoup de jeux Super Nintendo ralentissaient quand l'écran se chargeait, et la difficulté a été calée sur ce ralentissement. Le supprimer partout rend certains titres plus agréables et d'autres injouables.

Même logique côté image. Doubler la résolution interne passe sans mal sur un jeu de course PlayStation 1 et fait décrocher un jeu de combat 3D chargé. Un réglage global vous oblige à retenir le pire cas pour tout le catalogue.

Comment fonctionne un remplacement par jeu

Le principe est une pile de fichiers, du plus général au plus précis : la configuration générale, puis un fichier propre au cœur d'émulation, puis un fichier propre au dossier, puis un fichier propre au jeu, qui a le dernier mot.

La documentation Libretro décrit ces trois niveaux de remplacement dans RetroArch et indique où ils atterrissent : un fichier .cfg rangé dans /config/<nom-du-coeur>/, nommé d'après le cœur, d'après le dossier de contenu ou d'après le jeu. Seuls les réglages qui diffèrent du niveau précédent sont écrits : un fichier de remplacement bien fait tient en quelques lignes.

Deux mécanismes à ne pas confondre

Il y a deux familles de réglages, et elles ne se sauvegardent pas au même endroit.

• Les réglages du frontend (image, audio, latence, rembobinage) se figent par le menu rapide, entrée Overrides, puis l'enregistrement pour le jeu en cours. Résultat : un fichier .cfg.
• Les options du cœur (résolution interne, overclock, précision d'émulation) se figent par le menu rapide, Options, puis Manage Core Options et Save Game Options, qui n'enregistre les options que pour le contenu en cours. Résultat : un fichier .opt.

Pour que ces fichiers soient relus automatiquement, deux interrupteurs doivent être actifs dans les réglages de configuration : Load Override Files Automatically et Load Content-Specific Core Options Automatically. C'est la cause numéro un des « j'ai enregistré, mais rien ne se passe ». Les libellés varient selon la version de RetroArch et le firmware, et certains frontends propriétaires fonctionnent autrement, à confirmer selon la version : retenez la logique, pas l'intitulé. Les bases sont dans notre guide des réglages RetroArch.

La résolution interne : ce qu'elle change, ce qu'elle coûte

La résolution interne ne concerne que les systèmes 3D. L'émulateur fait calculer la scène à une définition supérieure à celle de la console d'origine : les arêtes des polygones deviennent nettes, les textures cessent de trembler, l'interface 2D reste en général inchangée.

Sur un jeu 2D, ce réglage n'existe pas. Une image Super Nintendo ou Game Boy Advance est une grille de pixels fixe. Ce qui se règle là, c'est la mise à l'échelle et les filtres d'affichage.

Jusqu'où monter ? Plus bas qu'on ne le croit. Sur les consoles Linux à Allwinner H700, de la RG35XX Pro à la TrimUI Brick, la PlayStation 1 tourne bien en résolution native et la marge pour le double est mince, jeu par jeu. Sur les Android récentes, Retroid Pocket 5 ou 6, la marge existe vraiment, sur PS1 comme sur PSP. Le réflexe reste le même : un cran, dix minutes sur la scène la plus chargée, redescendre si ça décroche. Notre comparatif des émulateurs PS1 détaille les différences entre cœurs, souvent plus décisives que le multiplicateur.

Deux effets secondaires. Une résolution élevée fait ressortir les défauts d'époque : brouillard mal dessiné, textures étirées, interface 2D floue à côté d'une 3D nette. Et elle sollicite la puce graphique en continu, donc elle chauffe et consomme, même quand le jeu ne rame pas.

L'overclock du processeur émulé

Il s'agit d'accélérer le processeur simulé dans l'émulateur, pas la puce de votre console. Vous ne touchez pas au matériel : vous demandez au logiciel de faire comme si la machine d'origine était plus rapide. La charge réelle, elle, augmente, puisqu'il y a plus d'instructions à simuler.

À quoi cela sert : supprimer des ralentissements présents sur la console d'origine, raccourcir certains chargements, tenir la fréquence d'images quand l'écran se charge. Cela ne corrige pas un émulateur trop lent pour votre machine : si le jeu rame parce que le processeur peine, l'overclock émulé aggrave la situation.

Les options sont explicites, y compris sur leurs risques :

• Beetle PSX, CPU Frequency Scaling (Overclock) : de 50 % à 750 %, par pas de 10 %, défaut 100 %. La documentation précise que certains jeux ont un limiteur de fréquence d'images interne et ne gagnent rien, et recommande de garder la valeur par défaut dans la plupart des cas.
• PCSX ReARMed, PSX cpu clock sur les versions à recompilateur dynamique : de 30 à 100, défaut 57. La documentation prévient que ce réglage provoque des problèmes de compatibilité et n'est à modifier que pour les jeux qui en ont besoin.
• Snes9x, Reduce Slowdown (Hack, Unsafe) : désactivé, light, compatible ou max. Le nom dit l'essentiel, et le mode max casse davantage de jeux. L'option SuperFX Frequency, de 50 % à 500 %, ne concerne que les cartouches à puce SuperFX.
• Mupen64Plus-Next, Count Per Op : le nombre de cycles comptés par instruction, donc la vitesse simulée. Certains jeux n'acceptent qu'une valeur précise.

Ne confondez pas cet overclock logiciel avec l'overclock matériel proposé par certains firmwares personnalisés, qui augmente la fréquence réelle de la puce. Celui-là engage la durée de vie de la machine.

Les sauvegardes d'état : utiles, mais fragiles

Une sauvegarde d'état est une photographie de la mémoire du cœur à un instant donné : registres, mémoire vive, état des puces simulées. Rien à voir avec la sauvegarde native, que le jeu écrit lui-même dans sa pile ou sur sa carte mémoire, et qui reste lisible par n'importe quel émulateur correct.

D'où les limites. Un état ne se relit qu'avec le logiciel qui l'a écrit. L'aide de RetroArch est explicite : ces fichiers ne sont généralement pas portables et peuvent ne pas fonctionner avec d'autres versions du même cœur. Changer de cœur, mettre à jour le firmware ou passer d'une console à l'autre suffit à les rendre illisibles. Votre progression ne tient que si elle a été enregistrée dans le jeu.

Tous les cœurs ne se valent pas non plus. RetroArch affiche pour chacun un niveau de prise en charge : aucun, basique (enregistrer et charger), sérialisé (qui ajoute le rembobinage), déterministe (qui ajoute le run-ahead et le jeu en réseau).

Deux options de confort méritent d'être connues : Save State: Auto Save, qui crée un état à la fermeture du jeu, et Save State: Auto Load, qui le recharge au démarrage suivant. Pratique sur une portable qu'on éteint en cours de partie, mais cela ne dispense pas de sauvegarder dans le jeu. Le sujet complet est traité dans notre article sur les sauvegardes sur console rétro portable.

Le rembobinage et son prix

Le rembobinage enregistre des états en continu dans un tampon mémoire : maintenir une touche fait revenir la partie quelques secondes en arrière. C'est confortable sur les plateformes exigeantes et les jeux de course.

Le coût est annoncé sans détour : RetroArch décrit l'option Rewind Support comme provoquant une lourde perte de performance pendant le jeu. Sur une machine Linux qui tenait tout juste sa fréquence d'images, l'activer suffit à faire décrocher le jeu. Deux réglages l'accompagnent : Rewind Frames, le nombre d'images rembobinées par pas, qui règle la vitesse du retour en arrière, et Rewind Buffer Size (MB), la mémoire réservée au tampon, qui détermine la profondeur d'historique.

Deux refus reviennent souvent. RetroArch annonce que le rembobinage est indisponible parce que le cœur ne gère pas les états sérialisés : changez de cœur ou renoncez. Ou qu'il est impossible parce que l'implémentation utilise un audio threadé : c'est le pilote audio qui l'interdit. Dans tous les cas, ce réglage s'active jeu par jeu, jamais globalement.

La méthode : un réglage à la fois, et on note

Les configurations par jeu deviennent ingérables si on les empile au hasard. Un protocole simple suffit.

1. Choisissez une scène de test reproductible : le passage qui rame, atteint en moins d'une minute. Un état de sauvegarde juste avant fait l'affaire pour ce seul usage.
2. Changez un seul réglage, d'un cran.
3. Jouez dix minutes, pas trente secondes : les effets d'un overclock apparaissent tard, et l'échauffement change le comportement.
4. Si c'est concluant, enregistrez pour ce jeu seulement : options de cœur d'un côté, remplacement de configuration de l'autre.
5. Notez-le : un fichier texte sur la carte microSD, une ligne par jeu, titre, cœur, réglages, date.
6. En cas de doute, revenez au propre : Reset Core Options et Unload Override.

Dernier repère : beaucoup de problèmes attribués aux réglages viennent d'ailleurs, fichier incomplet, cœur inadapté, carte microSD fatiguée. Avant d'y passer la soirée, parcourez nos causes fréquentes d'un jeu qui ne se lance pas. Et si vous butez toujours sur la puissance, le problème est dans le palier d'émulation visé, pas dans la configuration : nos consoles portables rétro sont classées par système émulé, avec pour chacune l'état à la livraison, prête à jouer ou à configurer.