Depuis la sortie du Recalbox RGB DUAL et encore plus depuis le lancement de la campagne du Recalbox RGB JAMMA, vous avez été nombreux à réagir et à vous interroger au sujet de l'input lag.

L'input lag est un sujet sérieux et très technique, qui reste pour certains un éternel débat.

Beaucoup en parlent, mais peu maîtrisent véritablement le sujet. Entre fantasmes et idées préconçues, il nous semblait primordial de vous apporter en toute transparence un éclaircissement et des pistes de réponses factuelles, techniques et rationnelles. C’est ce que nous allons tenter de faire dans ce blog post !

Avant de partir sur la partie technique, un peu de sémantique, pour bien comprendre de quoi on parle.

C'est quoi l'input lag ?

L’input lag, c’est un terme devenu un peu fourre-tout pour définir le temps de réaction d'un jeu après une action de votre part.

On préfère ici utiliser le terme plus adéquat de latence globale.

Pour faire simple : la latence globale correspond au temps que va mettre votre personnage pour réagir, lorsque vous appuyez sur le bouton de votre manette.

Mais, derrière le terme de latence globale, se cache en réalité 3 phases bien distinctes :

• l’input lag, au sens littéral du terme, qui correspond uniquement au temps de prise en compte de la pression d'une touche par l’émulateur. Ce temps peut énormément varier suivant les manettes, les protocoles (filaire, USB, i2c, Bluetooth...), la configuration des émulateurs, ou le système d'exploitation que vous utilisez
• le process lag, qui est le temps de traitement par l'émulateur qui va générer une nouvelle frame en fonction de l’événement reçu
• et enfin le video lag, qui va être le temps qui sépare l’envoi du signal vidéo par votre console de son affichage à l'écran. C’est le temps de traitement de votre télévision. Ce vidéo lag est considéré comme inexistant sur les écrans cathodiques, cependant il est plus ou moins important suivant votre téléviseur HD sa configuration.

Alors, vous allez nous demander : comment va-t-on mesurer tout ça de manière factuelle ? Et bien tout simplement avec des outils et des méthodologies précises !

• les input-lag-tools vont nous permettre de mesurer spécifiquement l’input lag lié aux manettes
• un oscilloscope va nous permettre de mesurer la somme de l’input lag et du process lag
• enfin, le Latency Bro va nous permettre de mesurer la fameuse latence globale dans son ensemble.

1 - Mesure de l’input lag

Nous allons dans un premier temps nous concentrer sur l'input lag. Pour cela, nous allons essayer différentes manettes et kits arcade, et comparer les résultats obtenus en fonction des systèmes utilisés.

Pour se faire, nous avons réalisé une forme de boucle : un bouton de la manette ou du panel arcade est relié à l'un des pins du GPIO du Raspberry Pi.

Le Raspberry Pi sera donc en mesure d'appuyer lui-même sur le bouton, exactement comme le ferait un joueur. Il lui suffit alors de chronométrer le temps qui va s'écouler entre la pression du bouton… et la réception de l'information de la pression de celui-ci par le système.

Bien évidemment, chacune de ces mesures ont étés réalisés des dizaines de fois pour avoir une moyenne précise de l’input lag pour chacun des contrôleurs testés.

Voici le tableau des résultats.

Dans la colonne de gauche, vous retrouvez la manette ou l'arcade stick utilisé, puis son type de connexion, suivi de la carte et du système d'exploitation utilisé pour enfin trouver l'input lag moyen, et le pourcentage de chances de rater une frame (d'avoir une image de retard).

Plusieurs informations intéressantes sont à retenir de ces résultats.

Comme vous pouvez le constater, même filaires, toutes les manettes ne sont pas logées à la même enseigne, certaines générant plus d'input lag que d'autres.

De plus, les tests montrent que le protocole de connexion utilisé n'influence que très peu les résultats. Tout va se jouer essentiellement du côté de la conception de la manette et de l'optimisation du système d'exploitation.

Même si les résultats sont globalement convaincants pour le protocole USB, celui-ci montre toutefois ses limites. Il est en effet très difficile de passer sous la barre des 1ms avec une connexion USB. C’est une limitation directement liée au protocole USB : la communication USB se fait dans le sens PC/RPi vers manette. Le Raspberry envoie une requête à la manette à une fréquence donnée pour récupérer l'état des boutons : c’est ce qu’on appelle le “polling”.

C’est justement pour nous affranchir de cette limitation technique que nous avons fait le choix sur le Recalbox RGB JAMMA d’utiliser un autre procédé : les interruptions.

Lorsque le contrôleur détecte un changement d’état sur un bouton, il notifie instantanément le Raspberry Pi de ce changement.

C’est en partie ce qui explique les excellents résultats du Recalbox RGB JAMMA à ce test !

2 - Mesure du process lag

Avec la première étape, nous avons déterminé le temps entre la pression d’un bouton et sa prise en compte par le système.

Passons maintenant à la mesure du process lag, c'est-à-dire le temps de traitement de l'événement par le système. Ou pour être plus précis : le temps nécessaire au système pour générer une frame, donc une image, après avoir reçu un événement de pression du bouton, comme un saut par exemple.

A l'aide d'un oscilloscope, nous avons la possibilité de mesurer le temps entre la pression du bouton et l'envoi du signal RGB sur l'écran.

Le protocole de test est le suivant :

• une sonde (ligne jaune) est placée sur le bouton qui va être utilisé pour changer l'image, et va donc capter le front descendant (l'appui sur le bouton)
• une seconde sonde (ligne verte) est placée sur un des signaux RGB. Elle va donc refléter le signal RGB qui est transmis au moniteur. En RGB, le signal d'une frame (image) complètement noire sera transmis par une suite de valeurs à 0v, donc un trait plat. Pour un écran blanc, les pixels étant à leur valeur maximale de luminosité, signal s'affole et monte à 0.7V
• pour une meilleure interprétation des résultats, nous allons utiliser la 240p Test Suite qui va nous permettre de passer d'un écran entièrement noir a un écran entièrement blanc.

Nous allons donc pouvoir mesurer le temps qu'il se passe entre l'appui sur le bouton et le changement d'image.

La mesure en vidéo :

C'est dans cette situation qu'on pourra comprendre l'effort qui a été fait sur Recalbox RGB JAMMA pour réduire l'input lag a moins de 0.5ms.

Il est temps de résoudre un petit problème de math :

Si les 20.6ms de latence ci-dessus contiennent 0.5ms d'input lag sur le Recalbox RGB JAMMA, quelle latence subira, au minimum, un contrôleur JAMMA avec 10ms d'input lag ?

Ces mesures s'avèrent toutefois laborieuses et difficiles à répéter. C'est pourquoi le Latency Bro est né.

3 - Mesure de la latence globale - On passe sur l'arcade et les solutions JAMMA

Mesurer l'input lag et le process lag, c'est bien, mais tout le monde sera d'accord pour dire que ce qui nous intéresse, c'est la latence globale !

Nous allons donc mesurer la latence globale, c'est-à-dire le temps complet qui se déroule entre l'appui sur un bouton et le changement correspondant sur l'image, que ce soit sur écran CRT ou écran LCD.

Pour cela, nous avons conçu le "Latency Bro", un circuit électronique capable d'appuyer lui-même sur un bouton, et de mesurer le temps jusqu'à capter un changement d’image sur votre téléviseur, grâce à une cellule photosensible. Cette cellule est capable de détecter un changement de luminosité créée par le faisceau de l’écran CRT ou par la luminosité des pixels sur un écran LCD.

Il est donc possible de mesurer de façon précise et universelle la latence globale, aussi bien sur du matériel original ou sur des systèmes d’émulations.

Nous avions trois objectifs lorsque nous avons conçu le Latency Bro et mesuré la latence sur le matériel qui va suivre :

• répondre à vos questions sur la latence des produits Recalbox (RGB DUAL et RGB JAMMA)
• faire un état des lieux de la latence sur l'arcade
• configurer et optimiser le système Recalbox à l'aide de mesures précises
• et une fois pour toutes, en finir avec cette notion erronée de "débat" sur un problème qui est clairement mesurable et améliorable.

Voici comment nous avons procédé pour mesurer la latence sur les différents systèmes :

• nous allons commencer par accéder au service menu
• nous allons mettre le curseur sur l’entrée “GRID” du menu
• nous allons appuyer sur le bouton 1 pour afficher la grid
• nous allons mesurer la latence
• puis nous allons appuyer sur le bouton START et le bouton 1.

Disclaimer: Par soucis d'objectivité, toutes les mesures ont étés effectués par @gtranche de HFSPlay, sur sa New Astro City avec platine MS9 29. Un grand merci à lui et à HFSPlay pour leur temps et leur soutien.

Voici un aperçu du latency bro en fonctionnement :

Les boards testées :

Nous avons testé ces boards jamma :

Test numéro 1 : CPS2 + Super Puzzle Fighter 2 X

Nous commençons cette procédure avec le matériel original, ici un multi CPS2 sur lequel nous avons “écrit” la rom Super Puzzle Fighter 2 X (spf2xj.zip). Cette mesure va nous servir à établir un temps de référence, nous permettant de comparer les autres solutions et de mesurer la latence qu’elles ajoutent.

Résultat : 80.7 millisecondes ! Ça parait long pour passer d’un écran à un autre, mais peu importe, car nous avons maintenant notre valeur de référence sur laquelle nous allons nous baser pour la suite des mesures.

Pour chacune des boards Raspberry Pi vers JAMMA, nous avons décidé de prendre la première mesure avec une installation vanilla (sans toucher à aucune configuration), comme beaucoup d'utilisateurs ne se risquent pas à modifier les options avancées sur le lag.

Cependant, si des options permettant de réduire l'input lag sont disponibles dans le système concerné, nous les avons activés pour constater leurs impacts sur la latence.

Et voici le résultat, trié par ordre croissant de latence :

Comme on pouvait s'y attendre, en première position dans les solutions comparées au matériel original, le mister est très proche de la latence originale. Attention cependant aux manettes que vous utilisez, certaines pouvant justement ajouter quelques millisecondes dont vous vous passeriez tout à fait.

En seconde position, le Recalbox RGB JAMMA n'ajoute que 6.70ms soit moins d'une demi frame de retard. La configuration par défaut du Recalbox RGB JAMMA à laquelle nous avons ajouté le run ahead permet donc de se rapprocher à quelques millisecondes de l'expérience CPS2 originale.

En désactivant le Run Ahead, le Recalbox RGB JAMMA se positionne en 3ᵉ position avec un ajout de 20.80ms, soit 1.25 frame de retard en moyenne dans sa configuration Vanilla !

Le RGB Pi Jamma se situe quant à lui a +43.90ms, soit 2.63 frames de retard, ce qui peut commencer à se faire ressentir sur les jeux les plus nerveux.

Pour finir, le RPI2JAMMA, qui a été testé sur un Raspberry Pi 3 (car il ne supporte pas le RPi4) ajoute quant à lui plus de 4 frames de latence. Cela peut sans doute être amélioré avec un effort de configuration des émulateurs, cependant les options concernant l'amélioration du lag étaient inexistantes au moment de ce test.

Note technique : c'est quoi le Run Ahead ?

Le Run Ahead est une option de retroarch qui permet de "précalculer" toutes les frames qui pourraient être générées en fonction des événements manette. Lorsqu'un événement est reçu, la frame précalculée est utilisé directement plutôt que d'avoir à être calculée à la volée.

Il s'avère donc vraiment utile, mais n'est pas compatible avec tous les jeux/systèmes.

En ce qui concerne les Raspberry Pi

Pour mieux vous y retrouver et pour comparer les solutions sur Raspberry Pi, nous avons simplifié les tableaux de résultats.

Le premier tableau compare simplement les frames ajoutés dans la configuration la plus véloce pour chaque solution :

Et le second compare les frames ajoutés par la latence en vanilla:

Test numéro 2 : CPS3 + Street Fighter 3 Third Strike

Ici pas de matériel original, et le mister est hors course comme il ne supporte pas (encore ?) le CPS3.

Nous avons donc mesuré la latence sur les différentes solutions Raspberry Pi.

Première constatation : la latence pour passer d'un écran a un autre est beaucoup plus proche de ce que nous attendions sur un menu aussi simple que le service menu : 20ms pour le Recalbox RGB JAMMA avec Run Ahead, ce qui est très proche du temps d'affichage d'une frame en 60Hz (16.66ms).

Et c'est le Run Ahead couplé à l'input lag très faible du Recalbox RGB JAMMA qui lui permet de prendre la première position du classement. Les mesures seront mises à jour lorsque nous aurons réussi à récupérer un CPS3 original :)

Le manque de configuration en vanilla pour le JAMMA SD ou le RPI2JAMMA les place beaucoup plus loins dans le tableau avec des retards entre 3 et 4 frames par rapport à Recalbox RGB JAMMA en Run Ahead.

Conclusion

Nous sommes très heureux d'avoir pu mettre des chiffres, des méthodologies et des protocoles de tests en place pour ce blog post, mais notre mission consistant à rationaliser l'input lag ne fait que commencer.

Et dans les prochaines étapes, il va nous rester à :

• continuer à améliorer le système Recalbox pour diminuer la latence sur CRT comme sur HDMI
• mesurer d'autres systèmes et consoles, d'autres manettes, et pourquoi pas regrouper toutes ces informations sur un site spécifique
• envoyer quelques prototypes du latency bro à qui veut bien en avoir pour permettre une revérification des résultats.

Si votre lecture est arrivée jusque-là, bravo ! Il ne me reste qu'à vous remercier encore une fois pour votre soutien dans le projet Recalbox, qui ne serait rien sans vous !