Recalbox RGB JAMMA

[cazeysan]

Ah bein si, leur outil input-lag-tools mesure bien sur le GPIO (cf https://gitlab.com/recalbox/recalbox-in ... 68de3d6e9a ). Désolé @Mitchbucannon



L'idéal serait que quelqu'un d'équipé fasse des tests contradictoires.

[TJMK]

Mais du coup c'est du flan ou pas ? Parce que si c'est vrai c'est plutôt impressionnant, mais faut voir après en jeu après des heures d'utilisations, si ça rame pas à un moment donné, si y'a pas de micro freeze, si y'a pas de pertes d'input, etc, etc ...

Et AJE il en pense quoi de ces tests ?

[psykotine]

L’input lag du RPI2JAMMA me semble démesuré

[Lorenzo2mars]

L’input lag du RPI2JAMMA me semble démesuré

Non y en a dessus
C'est flagrant sur les shmups

[psykotine]

Démesuré ne veut pas dire qu’il y en a pas

[FrédoVOOT]

Et pour moi qui suit des repères comme Bigkam gaming, squall RS etc..... Biggy a complètement validé la solution en version Béta, et a effacer ma crainte de l'input lag

Ha? Il a 1cc quel shmup ?

[fredo34]

Moi j’aime bien. Par contre vous croyez que c’est mieux qu’un i5 2400 avec la distrib de Landonien via un jammasd ?

[aje_fr]

Mais du coup c'est du flan ou pas ? Parce que si c'est vrai c'est plutôt impressionnant, mais faut voir après en jeu après des heures d'utilisations, si ça rame pas à un moment donné, si y'a pas de micro freeze, si y'a pas de pertes d'input, etc, etc ...

Et AJE il en pense quoi de ces tests ?

Je m'étais promis de ne pas intervenir sur un topic de la "concurrence" mais là c'est trop tentant.
Mesurer des temps de l'ordre du nano seconde avec un script en python et des libraires toutes faites.... Merci pour le fou rire.
C'est là qu'on voit le gap entre les gens qui font du hard et ceux qui font du soft.
Qu'ils fassent des tests avec des vrais moyens fiables, reproductibles et non invasif et on en reparle.

[TJMK]

Impeccable, merci pour la réponse aje ! On sait désormais à quoi s'en tenir.

Je vais quand même en prendre un pour tester, on va bien voir (j'ai le droit, j'ai déjà un RPI2SCART de chez aje )

Moi j’aime bien. Par contre vous croyez que c’est mieux qu’un i5 2400 avec la distrib de Landonien via un jammasd ?

Je ne pense absolument pas ... Surtout avec un GroovyMAME auquel tu claques un frame delay de 9

[cazeysan]

Je m'étais promis de ne pas intervenir sur un topic de la "concurrence" mais là c'est trop tentant.

Eh bien si, c'est important que tu donnes des éléments de compréhension.
La majeure partie des usagers du forum ne sont pas techniciens ou ingénieurs en électro-technique.
Je préfère ta réponse (qui reste tout de même encore un peu obscure pour le béotien) à juste un "lol".

[jotakun]

Salut.
Il faudra voir aussi ce que ça donne dans le temps. Ne serait-ce que leur campagne de financement. Il me semble qu'un de leur stretch goal est l'adoption d'un kick harness CPS2 pour permettre le jeu à 4. Amélioration au fil des retours utilisateurs, future compatiblité pi5. Le temps et les tests nous le diront.

[TJMK]

Qu'ils fassent des tests avec des vrais moyens fiables, reproductibles et non invasif et on en reparle.

Pour ma (notre) culture, tu avais fait des tests d'input lag sur tes solutions JAMMA et SCART ? Et si oui quels étaient les résultats ? Ca pourrait être sympa de comparer avec ce qu'ils avancent sur leur tableau !

[red77290]

Mais du coup c'est du flan ou pas ? Parce que si c'est vrai c'est plutôt impressionnant, mais faut voir après en jeu après des heures d'utilisations, si ça rame pas à un moment donné, si y'a pas de micro freeze, si y'a pas de pertes d'input, etc, etc ...

Et AJE il en pense quoi de ces tests ?

Je m'étais promis de ne pas intervenir sur un topic de la "concurrence" mais là c'est trop tentant.
Mesurer des temps de l'ordre du nano seconde avec un script en python et des libraires toutes faites.... Merci pour le fou rire.
C'est là qu'on voit le gap entre les gens qui font du hard et ceux qui font du soft.
Qu'ils fassent des tests avec des vrais moyens fiables, reproductibles et non invasif et on en reparle.

Peut-être que la mesure n'est pas forcément exacte car les moyens utilisés peuvent eux aussi introduire de la latence.

En revanche en admettant qu'on est capable de reproduire le même résultat à chaque fois, la différence/comparaison entre les différentes PCB en utilisant le même moyen de test doit être plus ou moins correct.

[Rom1]

Mesurer des temps de l'ordre du nano seconde avec un script en python et des libraires toutes faites.... Merci pour le fou rire.

Pour le coup pourrais-tu détailler le problème ?
Le script python ne fait que mesurer de manière assez simple le temps entre un output sur le GPIO (ce qui déclenche le bouton) et une entrée sur le "/dev/input/js". Ca ne couvre que l'input lag du rpi+hardware externe, excluant toute la partie emulation et affichage (ce qu'ils expliquent).

Alors certes le python n'est pas le langage le plus rapide du monde, mais cela semble largement suffisant puisqu'on parle de mesure de l'ordre de la millisecondes (et pas nano) et que l'ensemble des solutions testées sont logées à la même enseigne. Quand bien même la mesure serait faussée par l'outil, alors elle le serait pour tous les devices. De plus une moyenne est réalisée sur plusieurs mesures.

C'est là qu'on voit le gap entre les gens qui font du hard et ceux qui font du soft.
Qu'ils fassent des tests avec des vrais moyens fiables, reproductibles et non invasif et on en reparle.

On pourrait tester en full externe en mesurant le temps via l'écran ou le gpio, cela ne changerait pas grand chose. Quel protocole imagines-tu ?


Pour ma part je pense que toutes les solutions "rpi vers jamma" existantes pourrait se permettre d'avoir un input_lag ultra faible à la simple condition d'avoir un polling de l'interface suffisamment élevé. A partir du moment où tu interroges 2x plus souvent que le jeu ne rafraîchit (je vous laisse regarder du coté de Shannon Nyquist pour la théorie) on ne devrait sentir aucune latence liée à l'input (celle liée aux émulateurs c'est autre chose). En pratique sur nos jeux qui tournent souvent dans les 60hz, on a des frames d'environ 16ms et donc il suffit d'être sous les 8ms pour être à l'aise. Encore une fois, ça suppose que l'émulateur n'introduit aucune latence - ce qui n'est pas le cas - et donc tout ce qui peut être grappillé est appréciable.

@aje_fr Par curiosité, sur le rpi2jamma c'est quelle fréquence le polling des inputs ?

[jerivier]

Hello

Utilisateur lambda assidu du RGB PI, j'ai eu le RPI2JAMMA qqs jours en main

RPI2Jamma
J'ai été particulièrement impressionné par le frontend. C'est beau, convivial.
On sent tout de suite que ça a été pensé pour le Jamma/les bornes
En inconvénient, il y a le prix (probablement lié au fait qu'il y a plus de matos dessus, de comptabilité borne) et la dispo.
Je voulais aussi avoir la possibilité de jouer avec du Pi4 (plus de puissance) et tester le lightgun.
Du coup, je suis resté sur mon RGB PI

RGB PI
c'est dispo, c'est pas cher
Il y a la gestion des fréquences en automatique sur le Pi4 (Dynares), du coup aucun modeline à mettre.
Le Pi4, c'est bien pour certains jeux gourmands (tetris par exemple). J'attendais bcp de l'émulation de la DC. Mais bon, en 15k. Le rendu reste correct, mais ne rend pas hommage aux jeux tout de même. Dans la pratique je n'y joue jamais.
Le lightgun marche pas mal (c'est eux qui ont dev le driver, repris il me semble côté Mister depuis).
Côté inconvénient
Le frontend mériterait tellement mieux. (on est plutôt face à un listing. Possible d'avoir les jaquettes, mais ça prend toute la fenetre, tu sais même pas quel jeu c'est).
Le kickharness est à souder si besoin
On sent quand même que c'est pensé au départ pour du Scart. Exemple : pas possible de régler le son en cours de jeu. Il faut sortir du jeu et revenir au menu principal.

Recalbox Jamma
Côté hard
les devs du RGB PI sont plutôt critques (en mode, ils ont copié notre board en mettant des composants moins bien : IC et ampli)

They use a clone of the microcontroller that we are currently using with a slower I2C bus, so from the hardware perspective it is virtually not possible to get better results with that board.
If you look at the table, they avoided to test our board in their system or their board with ours That leads me to think that they maybe have “overclocked” the driver for a faster polling which based on the Linux and microcontroller documentation could result in erratic behavior and high use of the cpu or they tested while the UI was running via ssh which is not a valid test

Ohhh and also do note that this test is only having into account 50% of the full action. It is only measuring from gpio to linux udev driver response. It is fully missing physical button to gpio

the audio is a class D amp is a piece of sh*t compared with the analog amp from rgb-pi

Côté soft
Le frontend semble assez userfriendly
ça devrait convenir à plus de monde.

perso, si la solution peut s'installer sur un RGB PI, je testerai

[Dante2fr]

salut a tous,
moi j'ai une petit question de l'ordre technique vu qu'ils supporte le 31khz est-il compatible avec les bornes Naomi et une carte jvs to jammma ?
merci

[GyuGyu]

N'hésitez pas à aller voir mon test sur YT du Recalbox rgb Jamma :

https://youtu.be/67Lc1caRLvg

[GyuGyu]

salut a tous,
moi j'ai une petit question de l'ordre technique vu qu'ils supporte le 31khz est-il compatible avec les bornes Naomi et une carte jvs to jammma ?
merci

J'ai pas test mais normalement ça marche.

[cazeysan]

Bonjour @GyuGyu cela aurait été sympa de passer par le sujet ''présentation'' du forum avant de faire poper ta vidéo.

[GyuGyu]

Dsl je n'ai voulu froissé personne,

Mon tag était supergameboyman avant mais je n'ai pas réussi à récup mon MDP.
Je vais le faire dans l'heure .
Merci pour votre compréhension.

[lorenzo33]

[psykotine]

Deathsmiles ça rame et le son aussi quand c'est full boulettes + dans les menus

L’émulation n’est déjà pas parfaite de base alors sur un Pi c’est un peu normal que ça rame

[Enskynet]

HA ok ça explique aussi cela......
Merci

[aje_fr]

Mesurer des temps de l'ordre du nano seconde avec un script en python et des libraires toutes faites.... Merci pour le fou rire.

Pour le coup pourrais-tu détailler le problème ?
Le script python ne fait que mesurer de manière assez simple le temps entre un output sur le GPIO (ce qui déclenche le bouton) et une entrée sur le "/dev/input/js". Ca ne couvre que l'input lag du rpi+hardware externe, excluant toute la partie emulation et affichage (ce qu'ils expliquent).

Alors certes le python n'est pas le langage le plus rapide du monde, mais cela semble largement suffisant puisqu'on parle de mesure de l'ordre de la millisecondes (et pas nano) et que l'ensemble des solutions testées sont logées à la même enseigne. Quand bien même la mesure serait faussée par l'outil, alors elle le serait pour tous les devices. De plus une moyenne est réalisée sur plusieurs mesures.

C'est là qu'on voit le gap entre les gens qui font du hard et ceux qui font du soft.
Qu'ils fassent des tests avec des vrais moyens fiables, reproductibles et non invasif et on en reparle.

On pourrait tester en full externe en mesurant le temps via l'écran ou le gpio, cela ne changerait pas grand chose. Quel protocole imagines-tu ?


Pour ma part je pense que toutes les solutions "rpi vers jamma" existantes pourrait se permettre d'avoir un input_lag ultra faible à la simple condition d'avoir un polling de l'interface suffisamment élevé. A partir du moment où tu interroges 2x plus souvent que le jeu ne rafraîchit (je vous laisse regarder du coté de Shannon Nyquist pour la théorie) on ne devrait sentir aucune latence liée à l'input (celle liée aux émulateurs c'est autre chose). En pratique sur nos jeux qui tournent souvent dans les 60hz, on a des frames d'environ 16ms et donc il suffit d'être sous les 8ms pour être à l'aise. Encore une fois, ça suppose que l'émulateur n'introduit aucune latence - ce qui n'est pas le cas - et donc tout ce qui peut être grappillé est appréciable.

@aje_fr Par curiosité, sur le rpi2jamma c'est quelle fréquence le polling des inputs ?

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

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.
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é.
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é.

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.

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...

[cazeysan]

Merci pour cette appréciation détaillée.