Vous appuyez sur saut, le personnage part un instant plus tard, et le jeu que vous connaissiez par cœur devient injouable. La latence d'entrée, c'est le délai entre l'appui sur le bouton et le mouvement à l'écran. Elle ne vient jamais d'une seule cause : c'est une addition de petits retards, entre la manette, le système, l'émulateur et l'écran. Personne ne la ramène à zéro, y compris sur matériel d'origine. En revanche, deux ou trois réglages suppriment des trames entières, et font la différence entre « mou » et « correct ». Le reste relève de la légende de forum.
Ce que vous mesurez vraiment
La latence d'entrée est le temps total entre l'action et le pixel qui change. À 60 images par seconde, une trame dure 16,7 ms : c'est l'unité de compte utile, les gains se raisonnent en trames.
Premier point : le jeu d'origine était déjà en retard sur vous. La plupart des titres lisent la manette, calculent, puis affichent le résultat une ou plusieurs trames plus tard. Pour compter ce retard interne, la documentation de RetroArch donne une méthode : mettez le jeu en pause, maintenez une direction, avancez image par image jusqu'à ce que le personnage bouge ; le nombre d'avances moins un donne les trames propres au jeu. Ce chiffre plafonne les gains possibles. RetroArch revendique par ailleurs une réponse à la trame suivante, soit 16 ms ou moins, quand la chaîne est bien réglée.
Le seuil de gêne dépend du jeu et de l'habitude : la tolérance n'est pas la même au tour par tour, en plateforme au pixel près et en jeu de combat.
La chaîne, maillon par maillon
| Maillon | Ce qui s'y passe | Marge de manœuvre |
|---|---|---|
| Manette | Lecture des boutons, transmission filaire ou radio | Faible, sauf sans-fil médiocre |
| Système | Pilote d'entrée, couche Android ou Linux | Moyenne, via le firmware |
| Émulateur | Lecture des entrées, tampons vidéo et audio, exécution différée | Forte : tout se gagne ici |
| Retard interne du jeu | Trames que le jeu original prend pour réagir | Nulle, sauf compensation par run-ahead |
| Écran | Traitement de la dalle et affichage | Nulle sur une portable, l'écran est soudé |
La hiérarchie est claire : l'émulateur d'abord, le système ensuite, la manette enfin. Beaucoup font l'inverse et changent de manette pour un problème de tampon vidéo.
Les réglages qui comptent, classés par gain réel
Tout se passe dans le menu Latence de RetroArch et dans les réglages audio et vidéo, dont la navigation est détaillée dans notre guide des réglages essentiels.
1. L'exécution différée, ou run-ahead
Seul réglage capable de supprimer des trames imposées par le jeu d'origine. L'émulateur exécute la logique une ou plusieurs trames en avance, puis recharge l'état antérieur, ce qui rapproche votre appui du moment où le jeu lit l'entrée. Valeur par défaut : 1 trame.
Trois modes. Instance unique avance puis recharge l'état courant. Seconde instance garde un second cœur, vidéo seulement, à une trame future, ce qui évite les artefacts sonores des chargements d'état ; c'est le mode par défaut. Trames préemptives rejoue les trames passées avec la nouvelle entrée quand c'est nécessaire, variante que la documentation présente comme la plus économe.
Le coût est franc : plus vous montez en trames, plus la charge processeur grimpe, puisque la logique tourne plusieurs fois par image, et seconde instance ajoute un cœur en mémoire. Le tout exige des sauvegardes d'état : sans elles la fonction est indisponible, et les trames préemptives se désactivent faute de sauvegarde déterministe.
Une console Linux modeste comme une Anbernic RG35XX Pro encaisse le run-ahead sur les systèmes légers, pas sur ce qui tourne déjà à la limite ; une Retroid Pocket 5 a plus de marge. Activez, vérifiez la vitesse, redescendez dès que le son hoquette.
2. Le tampon audio
Souvent ignoré, c'est le plus gros retard affiché en clair. La latence audio par défaut de RetroArch est de 64 ms, le pilote visant la moitié de cette valeur. Sur Android et Miyoo, le défaut passe à 128 ms, parce que 64 ms y provoque trop de coupures.
Baisser ce tampon rapproche le son de l'image, au prix de craquements. Descendez par paliers, remontez au premier crachotement. Le réglage n'agit pas sur les boutons, mais il change beaucoup la sensation.
3. Synchronisation verticale et tampons d'image
La synchronisation verticale supprime le déchirement mais impose d'attendre le rafraîchissement de l'écran. Activée par défaut, c'est le bon choix ; ses voisines comptent davantage :
- Nombre maximal d'images en file d'attente : 3 par défaut, réglable de 2 à 4. Descendre à 2 raccourcit la file, au prix d'un risque de saccade.
- Synchronisation matérielle du processeur graphique : désactivée par défaut, 0 trame d'avance quand on l'active. Elle réduit le retard et coûte des performances.
- Délai de trame : 0 par défaut, jusqu'à 99 ms. Il retarde le calcul après le rafraîchissement, pour lire l'entrée plus tard, donc plus fraîche. Trop élevé, il fait tomber des images ; le mode automatique part des trois quarts du temps d'une trame.
- Synchronisation à la ligne de balayage : réduit le retard, mais exige de couper la verticale et augmente le risque de déchirement.
Sur une portable, commencez par le délai de trame automatique : meilleur rapport gain sur risque.
4. Interrogation de la manette
Le comportement d'interrogation de RetroArch décide si les entrées sont lues tôt, normalement ou tard dans la trame : le défaut est déjà « tard », le plus favorable, rien à y gagner. Reste la fréquence électronique de la manette : à 125 Hz elle transmet toutes les 8 ms, à 1 000 Hz toutes les 1 ms. Rapporté à une trame de 16,7 ms, l'écart pèse peu. Dernier maillon à optimiser.
Sans fil contre filaire : moins tranché qu'on ne le dit
La base de tests Gamepadla, qui compare les manettes en filaire, en dongle 2,4 GHz et en Bluetooth, donne des écarts plus faibles qu'attendu. Une DualSense y est relevée à 7,81 ms en filaire, 6,56 ms en dongle et 9,03 ms en Bluetooth ; une GameSir Tarantula 8K à 1,04 ms en filaire, contre environ 3,5 ms en dongle comme en Bluetooth.
Le filaire reste le plus régulier, un bon dongle 2,4 GHz s'en approche, et le Bluetooth ajoute quelques millisecondes sans être une catastrophe. Son défaut est la sensibilité aux interférences : c'est l'irrégularité, plus que la moyenne, qui gâche la sensation. Sur une portable, la question ne se pose que branché sur téléviseur ou avec une manette externe : voyez le rayon manettes rétro.
Ce qui ne sert à rien, malgré ce qu'on lit
- Une carte microSD plus rapide. Elle change les chargements, pas la latence.
- L'overclocking, si le jeu tourne déjà à pleine vitesse. Il ne sert qu'à financer le run-ahead ou rattraper des chutes d'images.
- Une manette à 1 000 Hz face à un émulateur à 60 images par seconde. Le gain se compte en fractions de trame.
- Empiler les options « anti-latence ». Certaines se contredisent : la documentation déconseille de combiner l'insertion d'images noires avec le délai de trame.
- Changer de firmware pour la seule latence. Un firmware personnalisé apporte surtout de l'ergonomie et des cœurs à jour, comme l'explique notre comparatif des firmwares alternatifs.
Mesurer soi-même, sans matériel de laboratoire
Filmez votre pouce et l'écran dans le même cadre, en 240 images par seconde, puis comptez les images entre l'appui et le premier mouvement : une image vaut 4,17 ms. Faites cinq essais et prenez la moyenne, la mesure est bruitée mais la tendance est fiable. Complétez par le comptage du retard interne, qui donne le plafond de run-ahead.
Testez un réglage à la fois, sur le même passage, à l'aveugle si possible : c'est le domaine où l'on croit sentir des gains qui n'existent pas. Si le jeu saccade ensuite, notre article sur les causes de plantage et de ralentissement donne la démarche.
Jeux de combat et jeux de rythme
En jeu de combat, tout se joue à la trame. Le run-ahead réglé juste sous le retard interne du jeu est la seule mesure qui change la donne, avec du filaire ou les commandes intégrées. N'espérez pas la sensation d'une borne : la chaîne d'affichage moderne n'est pas celle d'un tube cathodique.
En jeu de rythme, le problème n'est pas le bouton mais l'écart entre le son et l'image : le tampon audio par défaut suffit à décaler la sensation. Baissez-le autant que le matériel l'accepte, puis servez-vous du calibrage interne du jeu.
Le run-ahead fonctionne-t-il sur toutes les consoles rétro portables ?
Non. Il exige un cœur qui gère les sauvegardes d'état et de la puissance en réserve, puisque la logique tourne plusieurs fois par image. Sur les machines Linux modestes, il passe sur les systèmes légers, jamais sur ce qui sature déjà.
Combien de trames de run-ahead faut-il régler ?
Jamais plus que le retard interne du jeu, mesuré par l'avance image par image : au-delà, saccades et retours en arrière. La valeur par défaut de 1 trame reste le bon point de départ.
Faut-il désactiver la synchronisation verticale pour gagner en réactivité ?
Ce n'est pas le premier levier : la couper vous expose au déchirement pour un gain limité. La synchronisation à la ligne de balayage, qui impose de la désactiver, réduit le retard mais augmente ce risque. Préférez le délai de trame.
Une manette Bluetooth rend-elle un jeu injouable ?
Non, dans la majorité des cas : les mesures publiques le placent quelques millisecondes derrière le filaire, pas une trame entière. Son défaut est l'irrégularité en milieu radio encombré. Pour le jeu de combat, restez en filaire.
Pourquoi le son semble-t-il en retard sur l'image ?
Parce que le tampon audio est dimensionné pour éviter les coupures, pas pour la réactivité : 64 ms par défaut, 128 ms sur Android et Miyoo, le pilote visant la moitié de cette valeur. Baissez par paliers, arrêtez-vous au premier craquement.
Pour comparer les modèles selon leur puissance réelle, donc leur aptitude au run-ahead, passez par le comparateur, puis le rayon consoles portables.