Dans le précédent thread j'ai évoqué l'input lag lié à la fréquence de polling du moteur du jeu. Je vais maintenant parler des contrôleurs, mais ceux d'aujourd'hui. A l'inverse du précédent thread ca va donc plutôt concerner le retrogaming en émulation.
#Retrogaming #Inputlag
En effet, les vieilles manettes de l'ère 8/16 bit ne sont pas un sujet puisqu'elles n'ont aucune latence. Ce pose donc la question d'où vient celui des contrôleurs modernes? On a souvent associé ça au wireless mais ce n'est pas la présence ou l'absence de câble qui explique cela.
La distinction se fait sur leur nature profonde. Une manette moderne c'est une machine qui communique avec une autre machine alors qu'une vieille manette est une excroissance de la console. Appuyer sur un bouton de celle-ci c'est comme appuyer sur un bouton de la console.
Cette communication entre la manette moderne et la machine de jeu est donc assujettie à un protocole.
Un contrôleur USB (ou Bluetooth et autre) à plusieurs modes de communication. Celui utilisé par les manettes est un mode de communication par "interruption".
Dans cette situation c'est le contrôleur USB hôte (celui du PC, console...) qui va prendre l'initiative d'interroger celui de la manette à une certaine fréquence qu'on appelle le polling rate et qui est la première source de latence.
Dans la manette, le microcontrôleur doit préparer le paquet de données à transmettre. Une tâche qui consiste entre autres à scanner les divers inputs et qui est exécuté et répété à une certaine fréquence. Cette fréquence d'échantillonnage interne est une autre source de latence.
Le polling rate du contrôleur USB hôte ou la fréquence d'échantillonnage interne de la manette ne sont pas synchronisés entre eux, pas plus qu'ils ne le sont avec le polling rate du moteur du jeu ou les doigts du joueurs.
Le moment où vous appuyez tombe peut être malheureusement juste après celui où le microcontrôleur de la manette à scanné le bouton. Et le moment où ce dernier scan les inputs tombe peut être juste après celui où le contrôleur USB hôte à interrogé celui de la manette etc…
Donc tout ça produit des latences aléatoires (jitter), pour les même raison que j'ai expliqué sur le thread précèdent, et ces 3 sources de latence se cumulent.
Ce sont donc les fréquences en question qui vont définir le niveau de latence comme pour celle du moteur du jeu.
On a déjà vu qu'avec un jeu à 60fps on obtient un polling des inputs par le moteur du jeu à 60Hz qui va produire entre 0 et 16ms de latence.
Les polling rate du contrôleur USB hôte lui utilise en général des valeurs plus élevées de type: 125Hz, 250Hz, 500Hz ou 1000Hz.
Ca a l'air d'être à peu près le standard d'une manette basique d'aujourd'hui. Ce qui veut dire une latence variable entre 0 et 12ms qui s'ajoute au 16ms de variabilité d'un jeu 60fps. Ce qui commence à faire un jitter élevé (entre 0 et 28ms).
Nov 6, 2025 · 11:18 AM UTC
Ma manette 8bitdo SN30pro+ fait même encore moins bien avec seulement 100Hz d'échantillonnage et 250Hz de polling rate USB ce qui fait un total qui monte jusqu'à 14ms, presque une frame 60fps. Les 2 n'étant même pas des multiples, le jitter est donc encore plus chaotique.
A l'inverse j'ai aussi mon adaptateur Raphnet pour pad Nintendo classic qui me permet d'avoir 1000Hz de fréquence d'échantillonnage interne et 1000Hz de polling rate USB soit entre 0 et 2ms de latence.
Je crois que la 8bitdo Ultimate 2 propose aussi ce type de performance.
Personnellement j'utilise Wireshark, qui est un soft de capture des I/O sur PC, pour identifier le polling rate et la fréquence d'échantillonnage de la manette (si celle ci n'est pas supérieur au polling rate). Si besoin je pourrais peut être faire une petite vidéo tuto.
A savoir que sur un PC il est possible de forcer un polling rate plus élevé sur le contrôleur USB hôte que celui proposer par défaut par la manette afin de réduire un peu plus la latence.
Fréquence d'échantillonnage interne de la manette et polling rate du contrôleur hôte (USB, Bluetooth ou autre) sont donc les principales sources de latence de la manette moderne. A cela peut s'ajouter aussi quelques instabilités dans les communications, surtout en wireless.
Il y a aussi le temps de traitement par le driver de la machine hôte mais qui en toute logique est insignifiant. Par contre c'est un peu plus flou pour le temps de traitement interne à la manette. Combien de temps le microcontrôleur consacre à la préparation du paquet de données?
Logiquement il est censé être peu significatif aussi même avec un microcontrôleur bas de gamme mais difficile de savoir quelle tambouille interne font certaines manettes, notamment pour économiser de l'énergie (pour le wireless). D'autant que c'est très difficile à mesurer.
Voila a peu prêt tout ce que j'ai compris pour l'instant.
Je vous met le lien du thread précèdent sur l'input lag.
J'aimerais évoquer une notion peu connue dans la chaîne d'input lag du jeu vidéo. La composante aléatoire (ou "jitter") qui est quasiment toujours absente dans les définitions ou les mesures.
#Inputlag #Retrogaming