Recalbox RGB JAMMA

[Mitchbucannon]

Aje,

Je sors un peu du sujet recalbox mais qu'en est-il des test d'input lag proposés par mister Addon pour le Mister?
C'est fantaisiste aussi? (Si tu sais).
En tout cas merci d'être rentré dans la discussion.

Mitch

[Pierrot]

Le top du top, au delà de la réactivité, c'est le test des cohérences des prises en comptes des inpouts.

SSF2X que j'ai musculairement en moi, par ses rolling de boutons et ses negative edge, me permettent, en testant les true reversals, de voir si c'est bon. Ça plus les vitesses de chaque stage.

[TJMK]

SSF2X que j'ai musculairement en moi, par ses rolling de boutons et ses negative edge, me permettent, en testant les true reversals, de voir si c'est bon. Ça plus les vitesses de chaque stage.

Faut que tu testes chaque solution et que tu nous en fasse un retour, et on mettra un sticker "Pierrot Approuved"

[Pierrot]

Hahaha oui.

Mon coupaing Geronimo, un sacré lascar de la Baston et de 2X, semble dire que c'est bluffant sur la vidéo de Biggy.

Sur mon Groovy avec mon bon proco et FD à 7 (9 je trouve ça trop haut) je ne ressent aucun inpout lag pourtant j'ai bien une sensation différente de mon CPS2. Le reversals encore et toujours. Pareil sur 3.3 et les ralentissement de Yang mantis slash et/ou overhead sur son stage sur CPS3, lissés sur GM.

Y a aussi les glitch MVS de ligne verdâtre et autres, genre les transition de stage de Pulstar ou 8man.

De la méga branlette là, mais bon marrant de voir sur ce nouveau joujou.

[TJMK]

Sur mon Groovy avec mon bon proco et FD à 7 (9 je trouve ça trop haut) je ne ressent aucun inpout lag pourtant j'ai bien une sensation différente de mon CPS2. Le reversals encore et toujours. Pareil sur 3.3 et les ralentissement de Yang mantis slash et/ou overhead sur son stage sur CPS3, lissés sur GM.

J'ai déja lu de la part d'autres personnes. C'est vachement intéressant en vrai car ça voudrait dire qu'il y a soit une part d'inconscient qui nous fait dire que l'on ne joue pas sur le matos d'origine, et donc on "s'invente" des limitations, soit y'a ENCORE autre chose que l'input lag qui rentre en compte et qu'on n'a pas encore compris (une prise en compte "organique" des composants que l'on arrive pas à implémenter).

T'as le même ressenti aussi sur Mister ? (bon on dérive un peu du sujet d'origine, j'avoue )

Mais si avec ta box 15Hz réglée au petit oignon, tu as ce ressenti, tu vas forcément aussi l'avoir avec cette nouvelle interface

[Rom1]

Alors je ne vais pas être très objectif car python ce n'est pas un langage que j'apprécie beaucoup, mais bon, je vais essayer quand même.
C'est un language pour apprendre et découvrir, s'amuser à importer plein de librairies et ne rien savoir coder

C'est pas ma tasse de thé non plus, pour plein d'autres raisons. Par contre c'est très réducteur de dire que c'est un langage pour s'amuser. Ca reste un langage puissant supportant énormément de concepts avancés.
Mais bon on est hors sujet ici et nos préférences n'ont pas trop d'intérêt.

Leur protocole de test c'est de simuler l'appui sur un bouton en activant une des gpios sur le pi puis mesurer le temps que le kernel récupère l'info en provenance du driver de manette.
Dans le meilleur des mondes (celui d'un softeux), ça marcherait.
Sauf que c'est du python et qu'en plus tu fais ça sur la même machine que ce que tu veux tester...
Le python est un language interprété, le plus bas de l'échelle en terme de vitesse d'exécution.
En même temps, c'est un peu normal, l'interpréteur python doit lire ligne par ligne le script, comprendre ce qu'il faut faire et exécuter les différentes actions.

Alors oui, un langage interprété est plus lent qu'un compilé. Indéniable.
Cependant ce n'est pas si lent et ce n'est pas interprété ligne à ligne. Lors du lancement cela parse la syntaxe, construit un AST et ensuite compile du bytecode qui sera exécuté.
Tout ça pour dire que lorsqu'il est en train de tourner, il est très rapide et suffisamment pour la mesure qu'on souhaite effectuer ici.

Par exemple dans le cas d'activer le bouton simulé, il faut remonter toutes les couches de l'OS jusqu'à celle qui gère le bas niveau.
Autant dire que sur un OS temps réel tu ne maitrise absolument pas ce temps, l'OS peut bien faire ce qu'il veut, si il a décidé que ce n'était pas sa priorité, il fait autre chose. Surtout que c'est exécuté côté utilisateur et pas côté kernel.
Si tu regardes le script, il lance la commande d'un appui (comme expliqué, ça remonte toutes les couches,...), lit le temps machine en nano seconde (alors que l'OS a peut être fait autre chose en attendant).
De là ça ouvre le système de fichier (re quelques couches à traverser) pour vérifier l'état du bouton lu par le kernel, part dans une boucle infinie (en saturant le processeur au passage) et dès qu'il a l'info, va relire le temps machine.
Et c'est la comparaison entre temps de début et temps de fin qui est retenu et moyenné.

100% d'accord, mais tout ce temps CPU perdu entre kernel/userland et autre context switching, il concerne toutes les solutions testées. Donc si l'un obtient 0.5ms et un autre 50ms, on peut supposer que les 49.5ms supplémentaire du second ne sont pas liées au protocole de test mais à une différence entre les solutions testées.
C'est d'ailleurs intéressant que tu évoques la capacité du kernel à prendre la main sur l'exécution, il me semble que le recalboxjamma utilise les interruptions générée par les multiplexeurs afin "notifier" le Pi.

Tu satures un processeur en attendant un résultat et tu mesures le temps avec un language absolument pas fait pour.
De plus tu es dépendant de la machine sur lequel ça tourne, des librairies, de l'interpréteur python, etc... Un pi3 est par exemple est plus lent à basculer les gpio qu'un pi4. Certaines versions de python sont plus rapides que d'autres, etc...
Tout ça pour dire qu'on est TREEEES TREEEES loin d'un résultat fiable. Pour moi, il est strictement impossible de mesurer un temps dans ces conditions.
Même en codant ça en C (language compilé), côté user, j'aurais des doutes sur la fiabilité.

D'accord également, ce n'est pas 100% fiable ni ultra optimisé mais le but n'est pas là: il s'agit de lancer plusieurs "click" et de mesurer le temps pour que cela revienne sur le /dev/.
Le Pi4 sera plus rapide, un logiciel optimisé sera plus rapide, etc... Oui, c'est encore une fois le but du test de comparer le tout et de voir quelle solution est la plus efficace (peu importe la raison).

Le seul truc où j'aurais un peu plus confiance c'est un déclenchement externe (GBF ou autre) et une version modifiée du module kernel de gestion des inputs qui par exemple active un gpio (en direct du coup) quand l'info lui est remonté.
Là, tu compares les temps avec du vrai matos (un oscillo, analyseur logique) et tu auras peut être des résultats cohérents.

Pour le coup ça sera ultra pertinent que on mesurera la latence globale allant du bouton jusqu'à la réaction à l'écran; ce qui au final est la vraie valeur utile au joueur.

Quand à Shannon Nyquist, tout à fait d'accord, mais va faire comprendre ça au grand public qu'un polling à la fréquence de rafraichissement / 2 est largement suffisant.
20ms/2 en 50hz et 16ms/2 en 60hz.
Le hard d'origine fait logiquement un polling à chaque frame. Même certaines manettes n'acceptent pas un polling plus rapide (les megadrives 6 boutons par ex)

C'est sûr qu'afficher 0,5ms de temps de réponse c'est plus vendeur
Si c'était réel et qu'on reprend le théorème, on doit être à 250us de polling, soit 64 fois ce qu'on a besoin. Chez moi, on appelle ça du pignolage de mouche.

D'ailleurs, pour le fun, voici le polling d'un adaptateur usb 0 lag :

on est à un peu plus de 9ms de polling.

De toutes façons l'input lag, c'est un éternel débat...

Et oui... Du coup c'est quoi la fréquence sur le rpijamma ?

[Pierrot]

Mais si avec ta box 15Hz réglée au petit oignon, tu as ce ressenti, tu vas forcément aussi l'avoir avec cette nouvelle interface

Non c'est réél pas placebo. J'ai "99"% de réussite sur les reversals à la relève en pianotant, si en plus tu incorpores les relâches de boutons (les "negative edge"), je foire pas sur cps2.
Sur GM les 6 inpouts (3 rollings double validés par les NE) semblent déconer sur leur prisent en charge par l'émulation, je dois décaler mon éxé (plus tôt). Pour 3.3 pareil c'est réel, pas placebo.

Jamais testé le Mister. Mais que y a que 2X qui est taré à ce stade. Sur Garou MOTW "Noix de pudge", un prodige qui dosait 2 ans non stop au Japon avec Wata passait TOUT ses JD cancel et faisait tourner tout Morlaix avec une main Il m'a confirmé ne voir aucune différence avec le MVS.

Et Garou a de sacrés gimmicks de buffers et autres boutons tricks...donc pas de souci !

[njz3]

Pour ce qui est de l'input lag, comme j'ai le projet de faire une carte de gestion d'input format jamma vers USB, j'aimerai comprendre quelque chose et j'ai besoin de vos lumières.

Les jeux d'arcade ou de console qui fonctionnent le plus vite, c'est à dire environ 60Hz, soit une image toutes les 16,6ms, ont probablement tous la même boucle interne de gestion du moteur de jeu.
Souvent, en jeu, il y a une boucle principale exécutant le code selon une succession de procédures qui s'éxécute sur une interruption matérielle (synchro vidéo ou timer interne):
- lire les entrées matérielles et gestions des actions du joueur
- faire bouger les éléments, tester les collisions, gérer les scriptes des IA (joueurs CPUs ou énemis), gérer les animations
- faire le rendu des images dans un buffer pour affichage par le moniteur.
puis cela recommence ainsi de suite...
Les jeux ont chacun un ordre peut être un peu différent de l'appel aux procédures, mais reste que la lecture des entrées et probablement fait à un instant donné par rapport à l'interruption matérielle qui donne le tempo.
En mode émulation, c'est plus ou moins pareil, sauf que c'est l'émulateur qui se charge de lire les entrées matérielles et de synchroniser le tempo sur la vidéo vsync.
Si l'émulateur est bien fait, il n'introduit pas trop de retard (1 frame de buffer). S'il est mal fait, il génère les images avec 2 à plusieurs frames de retard.

Etant donné que l'utilisation des entrées se fait dans une boucle, et qu'à priori la lecture des entrées se fait tout le temps au même moment dans le jeu, j'aimerai comprendre quel est l'intérêt d'avoir un input lag à 0,5ms ou à 3ms ou même à 15ms, du moment qu'on reste sous les 16ms ?

[raik]

les jeux [...]ont probablement tous la même boucle interne de gestion du moteur de jeu.

Non, il n'y a pas une seule boucle qui gére tout le jeu.

Souvent, en jeu, il y a une boucle principale exécutant le code selon une succession de procédures qui s'éxécute sur une interruption matérielle (synchro vidéo ou timer interne):
- lire les entrées matérielles et gestions des actions du joueur
- faire bouger les éléments, tester les collisions, gérer les scriptes des IA (joueurs CPUs ou énemis), gérer les animations
- faire le rendu des images dans un buffer pour affichage par le moniteur.
puis cela recommence ainsi de suite...

Pareil, c'est plusieurs processus qui tournent de manière simultanées et indépendantes, entre ce que tu vois et ce qu'il se passe réellement il y a une grosse différence.
En gros tu peux jouer un jeu entiérement sans n'avoir aucun affichage, tu peux avoir un affichage sans avoir de contrôle et tu peux avoir un rendu sans qu'il n'y ait d'interactions.
On a l'illusion que c'est un seul gros truc mais c'est pas le cas. La gestion des inputs est indépendante de l'affichage qui est indépendant des animations qui est indépendant des collisions.

Les jeux ont chacun un ordre peut être un peu différent de l'appel aux procédures, mais reste que la lecture des entrées et probablement fait à un instant donné par rapport à l'interruption matérielle qui donne le tempo.
En mode émulation, c'est plus ou moins pareil, sauf que c'est l'émulateur qui se charge de lire les entrées matérielles et de synchroniser le tempo sur la vidéo vsync.

La lecture des entrées ne se fait pas à un instant donné mais en continu, c'est ce qu'on appelle le polling.
L'émulation ne fait que "simuler" un hardware lisant des instructions logicielles grossiérement, parler de synchroniser le tempo sur la vidéo vsync euh... pas sûr de comprendre là.

Si l'émulateur est bien fait, il n'introduit pas trop de retard (1 frame de buffer). S'il est mal fait, il génère les images avec 2 à plusieurs frames de retard.

Au-delà de l'émulateur en lui même, c'est la manière dont il est codé et le hardware sur lequel il tourne qui peut influer sur les "retards".

Etant donné que l'utilisation des entrées se fait dans une boucle, et qu'à priori la lecture des entrées se fait tout le temps au même moment dans le jeu, j'aimerai comprendre quel est l'intérêt d'avoir un input lag à 0,5ms ou à 3ms ou même à 15ms, du moment qu'on reste sous les 16ms ?

Pour ta première partie encore une fois, c'est pas vraiment une boucle à proprement parler.

[Rom1]

les jeux [...]ont probablement tous la même boucle interne de gestion du moteur de jeu.

Non, il n'y a pas une seule boucle qui gére tout le jeu.

Ca dépend des jeux.

Souvent, en jeu, il y a une boucle principale exécutant le code selon une succession de procédures qui s'éxécute sur une interruption matérielle (synchro vidéo ou timer interne):
- lire les entrées matérielles et gestions des actions du joueur
- faire bouger les éléments, tester les collisions, gérer les scriptes des IA (joueurs CPUs ou énemis), gérer les animations
- faire le rendu des images dans un buffer pour affichage par le moniteur.
puis cela recommence ainsi de suite...

Pareil, c'est plusieurs processus qui tournent de manière simultanées et indépendantes, entre ce que tu vois et ce qu'il se passe réellement il y a une grosse différence.
En gros tu peux jouer un jeu entiérement sans n'avoir aucun affichage, tu peux avoir un affichage sans avoir de contrôle et tu peux avoir un rendu sans qu'il n'y ait d'interactions.
On a l'illusion que c'est un seul gros truc mais c'est pas le cas. La gestion des inputs est indépendante de l'affichage qui est indépendant des animations qui est indépendant des collisions.

Il faut prendre en compte le fait que sur une machine, et encore plus dans le monde arcade, il se passe des choses en dehors de ton programme. Ca peut être du soft (le noyau qui bricole un truc à coté), du hardware qui interroge des IO pour te présenter un octet sur une adresse connue, voir même un mix des deux (une interruption HW qui déclenche un bout de code).
Donc oui, il y a plusieurs choses qui se passe en parallèle; cependant ce qui est important c'est qu'au moment où ton jeu "regarde" les valeurs des input, il y trouve une donnée la plus récente possible.

Les jeux ont chacun un ordre peut être un peu différent de l'appel aux procédures, mais reste que la lecture des entrées et probablement fait à un instant donné par rapport à l'interruption matérielle qui donne le tempo.
En mode émulation, c'est plus ou moins pareil, sauf que c'est l'émulateur qui se charge de lire les entrées matérielles et de synchroniser le tempo sur la vidéo vsync.

La lecture des entrées ne se fait pas à un instant donné mais en continu, c'est ce qu'on appelle le polling.
L'émulation ne fait que "simuler" un hardware lisant des instructions logicielles grossiérement, parler de synchroniser le tempo sur la vidéo vsync euh... pas sûr de comprendre là.

Le polling n'est ni plus ni moins que le fait de regarder régulièrement. Il faut dissocier le polling du matériel que tu utilises (ton pad USB sur ton PC par exemple) de celui de l'ému et celui fait par le jeu que tu émules.
Ca peut très bien être calé sur le vsync, on revient à la notion de boucle principale.

Si l'émulateur est bien fait, il n'introduit pas trop de retard (1 frame de buffer). S'il est mal fait, il génère les images avec 2 à plusieurs frames de retard.

Au-delà de l'émulateur en lui même, c'est la manière dont il est codé et le hardware sur lequel il tourne qui peut influer sur les "retards".

Etant donné que l'utilisation des entrées se fait dans une boucle, et qu'à priori la lecture des entrées se fait tout le temps au même moment dans le jeu, j'aimerai comprendre quel est l'intérêt d'avoir un input lag à 0,5ms ou à 3ms ou même à 15ms, du moment qu'on reste sous les 16ms ?

Pour ta première partie encore une fois, c'est pas vraiment une boucle à proprement parler.

L'intérêt d'avoir un input lag le plus faible possible sur la partie hard+Linux c'est justement parce que ton émulateur aura lui même besoin de temps pour interroger le "joystick" et traiter tout ça. Tu lui laisses donc + de marge pour bosser.
Et sinon, il faut être sous les 8ms, pas 16ms.

[Lorenzo2mars]

Putain il a level up ce topic, on a des bons qui sont sortis du bois, ça fait plaiz

[raik]

Ca dépend des jeux.

Certes mais l'input lag ça concerne pas trop les joueurs de Tetris

Sans parler de multithreading, l'affaire du lag comme on l'entend ça concerne principalement des PCBs avec plusieurs puces qui ont chacune leur responsabilité.
Ou alors tu peux avoir une puce qui fasse goulot d'étranglement à devoir gérer plus de données qu'elle peut en étant sous dimensionnée? ça me parait un peu gros non?

[Lorenzo2mars]

Ca dépend des jeux.

Certes mais l'input lag ça concerne pas trop les joueurs de Tetris

Sans parler de multithreading, l'affaire du lag comme on l'entend ça concerne principalement des PCBs avec plusieurs puces qui ont chacune leur responsabilité.
Ou alors tu peux avoir une puce qui fasse goulot d'étranglement à devoir gérer plus de données qu'elle peut en étant sous dimensionnée? ça me parait un peu gros non?

C'est une blague j'espère... va voir des superplay de Tetris grand master tu vas comprendre

[raik]

C'est une blague j'espère... va voir des superplay de Tetris grand master tu vas comprendre

on parle de construction là pas de gameplay, la diff se fait au niveau de la manière dont le jeu est interprété pas au niveau de la manière dont il est joué. Je sais ça paraît un peu contre-intuitif comme ça mais y a une diff énorme entre ce qui écrit et ce qui est perçu. Et je parlais de Tetris premier du nom pas Grand master parceque c'est écrit en Pascal à l'origine et c'était pour faire vulgairement codé comme si c'était une seule boucle (avec des gros guillements pour schématiser).

[njz3]

@raik: Il me semble que le polling en terme logiciel, c'est le fait de lire des infos de manière périodique sans contrainte de temps de réponse, c'est à dire que c'est le code qui choisit quand il va lire une valeur en mémoire ou sur une mémoire d'un périphérique via un bus. L'inverse s'appelle le modèle par évènement (ou par "interruption") qui veut dire qu'on interrompt la CPU pour aller traiter une demande hardware qui est prioritaire.

Niveau jeux d'arcade, la plupart des PCB fonctionnent avec un CPU principal pour le jeu, et des CPUs annexes pour gérer l'affichage ou le réseau, ou n'importe quoi d'autre niveau matériel (retour de force, son, etc...). Il me semble également que la programmation multi-thread (exécution concurrente de code en donnant à tour de rôle un petit temps d'exécution, et ayant une pile par thread) n'était pas courante car complexe de mise en œuvre, et ne l'est d'ailleurs toujours probablement pas aujourd'hui. Rare sont les jeux utilisant 16 coeurs pour faire tourner le moteur de jeu seul. En général un coeur est alloué par tâche principale, et tout le monde se synchronise sur une "barrière" temporelle. Le fait de paralléliser des procédures sur des coeurs différents d'un PCB ne change pas la donne : tout est synchronisé par des interruptions périodiques ou non, et le moteur du jeu cherchera à un moment unique dans les "16ms" d'une frame, les infos des contrôles dont il a besoin pour ensuite réaliser des actions, gérer des scripts et enfin tout ca donneront les informations graphiques qui seront ensuite afficher sur un écran.

Niveau émulateurs, je me permettrai uniquement de parler de ce que je connais (pour avoir jouer avec ou contribuer à leur code à titre de "loisir") : MAME, flycast et supermodel.
Dans le cas de supermodel, il s'agit d'une lecture dans une boucle principale faite avant la partie émulation du code machine, qui lui même va placer des infos pour le rendu qui est fait au début de la boucle. Le rafraichissement est donc d'environ 16ms. Tu as la boucle principale de supermodel ici (avec la ligne ou le polling est fait, une seule fois à chaque frame) :
https://github.com/trzy/Supermodel/blob ... .cpp#L1003

Sur MAME, le timeslice d'émulation est de 1ms, c'est à dire que MAME va émuler chaque sous-élément hardware avec 1ms de temps d'éxécution, afin de pouvoir gérer le cas de signaux d'interruption qui sont échangés entre les composants émulés. Ca prends beaucoup de ressources, et surtout ca veut dire qu'on a parfois du délais de plusieurs frames de retards et que si un appui de touche se déroule pendant les 16ms, l'émulateur risque de le rater. Néanmoins le moment où MAME cherche les infos des contrôles (qui sont rafraichi par polling une fois à chaque frame) est fait au moment où le rendu d'une frame vidéo se fait :
https://github.com/mamedev/mame/blob/ae ... o.cpp#L222
Chose très astucieuse pour limiter l'input lag en mode double ou triple buffering (soit jusqu'à 3 frames de retard), sur MAME je crois qu'il est possible d'émuler plusieurs frames d'avance, et l'émulateur va revenir en arrière si jamais il voit qu'une touche a été appuyé pendant la frame en cours d'affichage.

Je ne vois pas ce qu'il y a de choquant dans cette manière de faire.

Pour ce qui est de l'OS et de la lecture de périphérique USB ou autre PS2, etc., tout dépend comment la granularité du scheduler du noyau est configuré.
Sous Windows, de base c'est 15ms mais il est possible de passer à 1ms comme le fait MAME (fonction timeBeginPeriod() de l'API Win32), ce qui permet par exemple de lire les états d'un joystick avec 1ms de périodicité si besoin. D'ailleurs dans mon application de contrôle moteur via carte arduino en USB, c'est ce que je fais, et c'est obligatoire sinon le système étant asservi, ce serait instable...
En USB, le lag de 10ms vient souvent de l'implémentation faite par le firmware embarqué dans les manettes ou les claviers lowcost, car l'USB est tout à fait capable de gérer des délais de 1ms et Windows peut aussi poller les valeurs à 1ms (voir les clavier musicaux en MIDI). Simplement les constructeurs de manettes pensent que 10ms ca suffit, puisque Windows fonctionne de base à 15ms. Dans ma carte, je prévois bien de rafraichir à 1ms les données.

Sous Linux, c'est plus compliqué. En mode desktop, le noyau tourne de base à 10ms. On peut rendre le noyau plus responsive en changeant la granularité du tick d'horloge à la compilation (par exemple à 5ms) mais au final ca ralenti l'exécution de pratiquement tout et n'est pas conseillé. Les versions preempt-rt peuvent même rendre le noyau pré-emptible, c'est à dire que le code utilisateur peut lui même réagir sur interruption matériel très vite, mais ca nécessite de recompiler le noyau aussi.

Pour en revenir à la question initiale, je reste curieux de savoir si un input-lag de 0,5ms ou de 3ms change quelques chose...

[aje_fr]

Multi threading, multi core, multi processeur....
Euh les gars, on parle de cartes des années 90...
La plupart du temps on a un processeur principal, un secondaire pour le son et de la logique pour les graphismes (composant custom ou en logique câblée).
Et le processeur principal, il tourne souvent à 16Mhz avec à peine 512ko de RAM...
Bref, sortez les oscillos et vérifiez par vous même, un jeu fait un polling de ses inputs à chaque trame (j'ai déjà testé sur pas mal de PCB)
Pas plus car aucun intérêt... Ça servirait à quoi de recalculer des graphismes pour une trame qui n'est pas encore affichée.
Donc en émulation, si tu fais un polling toutes les demis trames, tu es déjà bon, tu ne louperas rien.
Les 3ms, etc.... C'est du blabla commercial, ça fait vendre, c'est tout.

[njz3]

Merci aje.
Les 0,5ms (ou 3ms) me semble effectivement disproportionné par rapport à la manière dont fonctionne un jeu et un émulateur. Le delai d'input lag vient souvent plus de la chaine de traitement vidéo dernière, ou de l'emulateur lui meme qui peut bufferiser.

Ca me rassure pour ma future carte d'io, car je prevoyais entre 2ms et 5ms de refresh (via USB).

[raik]

Multi threading, multi core, multi processeur....
Euh les gars, on parle de cartes des années 90...
La plupart du temps on a un processeur principal, un secondaire pour le son et de la logique pour les graphismes (composant custom ou en logique câblée).
Et le processeur principal, il tourne souvent à 16Mhz avec à peine 512ko de RAM...
Bref, sortez les oscillos et vérifiez par vous même, un jeu fait un polling de ses inputs à chaque trame (j'ai déjà testé sur pas mal de PCB)
Pas plus car aucun intérêt... Ça servirait à quoi de recalculer des graphismes pour une trame qui n'est pas encore affichée.
Donc en émulation, si tu fais un polling toutes les demis trames, tu es déjà bon, tu ne louperas rien.
Les 3ms, etc.... C'est du blabla commercial, ça fait vendre, c'est tout.

J'ai l'impression que y a un gros mix entre tout en fait, le polling c'est à la base même du fonctionnement de n'importe quel circuit électronique en fait c'est juste de la gestion d'I/O rien de plus, ça fait joli comme mot mais c'est plus pour se faire briller en société qu'autre chose. Et le polling est basé sur les deltas, tu peux forcer les calculs (ou les limiter plutôt) pour que ce soit 1 poll = 1 trame, mais sinon il est constant et en moyenne c'est 1/60.

Et je pense qu'on s'emmêle les pinceaux à tous parler de plusieurs trucs à la fois en fait. Comparer du polling sur du matos d'origine à de l'émulation c'est comme comparer ses perfs sur need for speed par rapport à ses perfs IRL.

En tout cas, je continuerais de suivre cette conversation dans l'ombre, amusez vous bien!

[Rom1]

Multi threading, multi core, multi processeur....
Euh les gars, on parle de cartes des années 90...
La plupart du temps on a un processeur principal, un secondaire pour le son et de la logique pour les graphismes (composant custom ou en logique câblée).
Et le processeur principal, il tourne souvent à 16Mhz avec à peine 512ko de RAM...
Bref, sortez les oscillos et vérifiez par vous même, un jeu fait un polling de ses inputs à chaque trame (j'ai déjà testé sur pas mal de PCB)
Pas plus car aucun intérêt... Ça servirait à quoi de recalculer des graphismes pour une trame qui n'est pas encore affichée.
Donc en émulation, si tu fais un polling toutes les demis trames, tu es déjà bon, tu ne louperas rien.
Les 3ms, etc.... C'est du blabla commercial, ça fait vendre, c'est tout.

On est d'accord sur le système original.
Par contre ton système le faisant tourner est bien en multi core, avec un soft (l'émulateur) qui a pour but de proposer les inputs bien réel à une PCB qui n'existe pas en s'appuyant sur un OS qui utilise des threads et autre changement de contextes.
Dis autrement, si ton RPI regarde les input à 60hz, il n'y a aucune chance que l'émulateur et encore moins que la PCB émulée ne récupère des valeurs à chaque frame même si celles-ci avaient changée sur le hard. Tu le reconnais toi même, ce n'est pas inutile que le RPI fasse un polling plus intensif des input afin que la PCB émulée puisse justement continuer à recevoir les input à son rythme original. A défaut d'être totalement synchrone entre RPI et système émulé, il faut que le RPI récupère les inputs à 120hz ce qui nous donne grosso modo toutes les 8 ou 9ms, des "demi trames" comme tu l'évoques.

Après, est-ce vraiment inutile de monter encore plus haut avec du 1000hz ? Bah... pas totalement inutile car encore une fois, le polling du hard par le RPI et le polling logiciel de l'émulateur ne sont pas forcément synchrones.
Si je presse un bouton (physique) juste avant, disons 5ms, que le jeu/émulateur ne regarde les inputs et que mon RPI ne regarde lui que toutes les 8ms, alors il aurait une chance de ne pas avoir vu le changement car 6ms avant la frame le bouton n'était pas encore pressé et que le RPI ne vérifiera peut être la nouvelle valeur que 2ms après la frame.
En maximisant le polling rate sur le hardware, on minimise les chances qu'une frame du jeu/émulateur ne regarde la valeur entre le moment où le bouton est appuyé et celui où le RPI a updaté la valeur sur le /dev/.

L'idéal est d'utiliser une interruption matériel pour que le soft aille tout de suite voir ce qui a changé, sans attendre la prochaine itération. Ca réduit à la fois la latence et la conso CPU. Et ça, un gars qui fait du hard doit le comprendre, pas comme les gars qui font du soft.




Mais sinon, le RPIjamma il regarde comment les input ? Parce que sur le fond, c'est ça qui importe les joueurs, pas le protocole de test ou les 3ms.

[aje_fr]

@Rom1
Sur les RPI2XXXX, le polling est calé sur la frame, et de mémoire c'est toutes les moités de frame, faudrait que je vérifie.

Quand au polling, j'ai pas tout compris à ton message même en le relisant plusieurs fois
Il faudrait coucher ça sur papier, ça serait plus clair

[njz3]

J'ai peut être un élément de réponse quand il s'agit de l'USB sur un PC car je ne connais pas assez le raspberry : l'envoi de la trame se fait à l'initiative du périphérique et au niveau du PC cela déclenche une interruption du controlleur USB, lui même déclenchant un traitement au niveau de l'OS et du driver HID (joystick ou clavier) qui stocke les données en cache pour mise à disposition quand une lecture est demandé par du code utilisateur. Le lag est quasi nul d'un point de vue de l'OS (on parle probablement de l'ordre de micro-secondes). C'est juste mauvais d'un point de vue performance car en USB le processeur se tape plein de boulot à faire, c'est un peu d'ailleurs le côté négatif de l'USB1 ou 2 sur d'autres bus comme le firewire (tout est fait en hardware avec copie par DMA) ou l'USB3 ou on peut faire des transfert isochrones sans déranger le CPU.
Là où cela peut ralentir, c'est la fameuse boucle dans le jeu ou l'émulateur dont je parlais. Sauf à poller les entrées toutes les 1ms au niveau de l'émulateur (ce qui peut imposer d'avoir une granularité suffisante de l'OS pour pouvoir le faire), les chances sont grandes qu'au final ce soit jusqu'à 16ms de délai pour lire la valeur en cache.

Il me semble que même avec un simple arduino qui a un USB natif (32u4), il est possible d'envoyer les statuts HID à 1kHz, et Windows le gère très bien en tout cas.
Simplement à part spammer le noyau d'interruptions, cela n'apporte pas grand chose en temps normal, c'est pourquoi les périphériques USB ont une cadence interne plutôt de l'ordre de 10ms, pour éviter de spammer l'OS d'interruptions inutilement trop fréquentes.

Pour le rpi en USB, c'est probablement pareil que sous Windows. Linux recoit une interruption du controlleur USB et traite probablement immédiatement la demande et mets en cache les données. Ensuite elles sont lus par l'émulateur dans sa boucle de polling.
Pour les gpios du rpi je ne sais pas exactement car il y a certainement aussi un controlleur associé aux GPIO (comme pour un microcontroleur classique) qui fait qu'on peut certainement déclencher une interruption matérielle pour que le noyau Linux viennent faire le boulot lors d'un changement. Mais pas dit qu'un émulateur fonctionne comme cela. Sinon, bin probablement que la lecture des gpio depuis le code de l'émulateur revient à aller lire les valeurs du controlleur de gpio, et là il n'y a pas de lag.

Dans le cas du recalbox ils parlent d'un IO extender en I2C (c'est d'ailleurs ce que je vais aussi utiliser sur ma carte). Le bus I2C est géré en hardware avec des buffers, et je ne pense pas que l'OS travaille beaucoup dans ce cas.
S'ils ont un driver au niveau noyau Linux pour exposer les données lues sur le I2C vers un device de type joystick, c'est effectivement efficace, mais probablement que cela ne changera pas le souci que l'émulateur risque de toute manière d'aller lire les valeurs qu'au bout de 16ms.

[Pierrot]

/passage ninja

Juste pour dire que le virage de ce topic est succulent ! je ne pige pas 1 mots des ces laïusse technique, mais que c'est beau !

[Playcubeman]

Ravi de voir Njz3, sur ce topic . Je connais un peu la personne pour avoir été chez lui et m’avoir livré une racecab . Ce mec est un génie de l’informatique et de la programmation. Heureux de te voir sur le forum .

[njz3]

Faut pas m'envoyer des fleurs, ca fait partie de mon métier et de mon expérience, et je ne cherche pas à étaler une science que d'autres maîtrisent bien mieux que moi.
J'interviens sur ce topic car j'essaie juste de comprendre pourquoi tant de gens pensent que l'input lag de la partie contrôle est importante alors qu'en réalité, si on fait une analyse globale, c'est probablement la plus négligeable par rapport à la chaîne complète (bufferisation et codage de l'emulateur, traitement vidéo de l'emulateur, traitement de l'afficheur, etc.).
A priori, j'ai mon idée sur quoi faire pour ma carte, grâce à nos échanges.
Très content en tout cas que recalbox fasse du hardware maintenant. Ca démocratise l'arcade et le retrogaming pour tous.

[Lorenzo2mars]

Polling c'est pas le beau frère de rocky ?