NEO-ARCADIA

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

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.

_________________
John faisant du pixel Art avec ses mots aka MOTW2 en 2D. Jean stage:
"je vois déjà son superbe décor : Paris populaire jour de marché près d'un quai, un clocher en arrière plan, un gamin qui chaparde une pomme, des costauds qui debarque les cagots, petite pluie fine animée"

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

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.

_________________
John faisant du pixel Art avec ses mots aka MOTW2 en 2D. Jean stage:
"je vois déjà son superbe décor : Paris populaire jour de marché près d'un quai, un clocher en arrière plan, un gamin qui chaparde une pomme, des costauds qui debarque les cagots, petite pluie fine animée"

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

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.

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

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

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

_________________
Ventes SEGA Ringedge, Slots/jeux/converts MVS, Adaptateurs MVS/JAMMA/Jeutel/System16, Capkit MTC9000, Bios Naomi, etc.
Achats & Réparations NeoGeo MVS, Namco ES3, Sega RingEdge, Sega ST-V, S16, CPS3, etc. Contactez moi en MP.
DSB Clone - SEGA Digital Sound Board replacement.

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 !

_________________
John faisant du pixel Art avec ses mots aka MOTW2 en 2D. Jean stage:
"je vois déjà son superbe décor : Paris populaire jour de marché près d'un quai, un clocher en arrière plan, un gamin qui chaparde une pomme, des costauds qui debarque les cagots, petite pluie fine animée"

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 ?

Non, il n'y a pas une seule boucle qui gére tout le jeu.
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.
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à.
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".
Pour ta première partie encore une fois, c'est pas vraiment une boucle à proprement parler.

_________________


Tu veux voir comment on crée un jeu? Viens jeter un oeil à ChromWarriors

Ca dépend des jeux.

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.

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.

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.

_________________
Ventes SEGA Ringedge, Slots/jeux/converts MVS, Adaptateurs MVS/JAMMA/Jeutel/System16, Capkit MTC9000, Bios Naomi, etc.
Achats & Réparations NeoGeo MVS, Namco ES3, Sega RingEdge, Sega ST-V, S16, CPS3, etc. Contactez moi en MP.
DSB Clone - SEGA Digital Sound Board replacement.

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

_________________
insta : 15k_arcade

une partie de ma gameroom : https://www.youtube.com/watch?v=P3T4-600WhI&t=4s

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?

_________________


Tu veux voir comment on crée un jeu? Viens jeter un oeil à ChromWarriors

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

_________________
insta : 15k_arcade

une partie de ma gameroom : https://www.youtube.com/watch?v=P3T4-600WhI&t=4s

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

_________________


Tu veux voir comment on crée un jeu? Viens jeter un oeil à ChromWarriors

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

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.

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

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!

_________________


Tu veux voir comment on crée un jeu? Viens jeter un oeil à ChromWarriors

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.

_________________
Ventes SEGA Ringedge, Slots/jeux/converts MVS, Adaptateurs MVS/JAMMA/Jeutel/System16, Capkit MTC9000, Bios Naomi, etc.
Achats & Réparations NeoGeo MVS, Namco ES3, Sega RingEdge, Sega ST-V, S16, CPS3, etc. Contactez moi en MP.
DSB Clone - SEGA Digital Sound Board replacement.

@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

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.

/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 !

_________________
John faisant du pixel Art avec ses mots aka MOTW2 en 2D. Jean stage:
"je vois déjà son superbe décor : Paris populaire jour de marché près d'un quai, un clocher en arrière plan, un gamin qui chaparde une pomme, des costauds qui debarque les cagots, petite pluie fine animée"

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 .

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.

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

_________________
insta : 15k_arcade

une partie de ma gameroom : https://www.youtube.com/watch?v=P3T4-600WhI&t=4s