Quelle que soit la plateforme, il y aura toujours un temps de latence entre le moment où vous appuyez sur un bouton et le moment où l'action correspondante est affichée. Vous ne pouvez pas afficher le résultat sur l'image qui est déjà à l'écran donc au minimum il faut attendre que la prochaine image soit affichée. Le nombre d'images compris entre l'action et la réaction dépend de différents facteurs comprenant le temps nécessaire pour prendre en compte la commande, le temps nécessaire pour rendre une image et (pour les télés modernes) le temps nécessaire pour calculer tous les filtres à la con.

On aurait pu penser que sur les vieilles consoles et les écrans cathodiques ce temps de latence était inexistant mais ce n'est pas le cas. Il est de deux images (soit 33ms pour une console US) pour Super Mario Bros ou Sonic par exemple. "Inacceptable" se sont dits les fous furieux qui programment la plateforme d'émulation RetroArch. La version 1.7.2 comprend donc une option pour réduire à une image cette latence. Cette option s'appelle Run-Ahead car c'est exactement ce que fait l'émulateur : quand vous appuyez sur un bouton, il va rendre l'image en cours mais aussi les deux prochaines images. Quand il est temps de rendre l'image suivante, l'émulateur ne va pas la rendre mais à la place afficher l'image future pré-rendue qui montre le résultat de l'action zappant ainsi l'image "morte".

Lire la suite sur le site : Les émulateurs voient l'avenir.

Sans être spécialiste, je m'étais posé la question de la latence sur Recalbox puis voyant que je m'en sortais toujours aussi bien à Super Ghouls n' ghost, à Super Mario World, j'ai arrêté de m'en faire et d'être un angoissé du temps de réponse Mais je pensais un peu benoîtement qu'effectivement il n'y avait pas de latence sur les consoles d'origine branchés sur la cathodique... je peux continuer à jouer à Probotector avec le regard altier du branleur quand n'a rien à foutre.
il y aura certainement un jour un constructeur de tv qui fera une gamme cathodique pour retro gaming, doit bien rester une chaine de production qui prend la poussière...

Et est-ce que le calcul de frame fais aussi le calcul de la physique/logique du jeu ? Car si oui, on va avoir un saut de frame pour les ennemies qui vont bouger 2x plus vite sur une frame affiché (puisque l'autre sera sauté). Et dans ce cas la la feature semble pas super utile.

Oui l'émulateur rend l'intégralité du jeu est calculé. Quand je parle de rendre une frame, ca sous entend que tout le reste est calculé.

Dans le futur il n'y aura plus besoin d'appuyer sur un bouton car l'IA saura à l'avance sur quoi tu aurais appuyé : 0 latence.

Le futur? Tu as déjà des IA fonctionnant en apprentissage automatique qui jouent à Super Mario World et Super Mario Kart.

Oui mais elle joue toute seule, elle ne joue pas comme si c'était toi qui jouait en sondant ton âme et t'en imitant.

Si, c'est exactement ce qu'elle fait :/

codec-abc a écrit :
Et est-ce que le calcul de frame fais aussi le calcul de la physique/logique du jeu ? Car si oui, on va avoir un saut de frame pour les ennemies qui vont bouger 2x plus vite sur une frame affiché (puisque l'autre sera sauté). Et dans ce cas la la feature semble pas super utile.

En fait non, parce que en gros le pacing (rythme) est toujours à la même vitesse et si l'implémentation est bien faite (ce qu'on espère) ça n'inclut pas de saut de frames (pour les ennemis).

Par contre les choses qui dépendent des inputs (la position de Mario) vont être un peu plus "jerky" que dans la normale, parce que quand le résultat d'une input est jouée en avance, la première frame où un changement d'input est enregistré sera perçue comme "mangée". Peut-être difficile à voir sur Mario mais ce serait intéressant de faire un test avec un truc comme le "mouse look" qui fait bouger tout l'écran. Dans une des discussions ils pensent que ce n'est pas un problème tant que la frame "mangée" ne mange que de la latence existante (Mario ne faisait déjà rien pendant deux frames donc à la place il ne fait rien pendant une frame).

Ils parlent aussi du son qui n'est joué qu'à partir de l'état caché (primary core) qui sera en retard d'une frame sur l'affichage (comparé à la vraie console..). Mais ce n'est apparemment pas grave parce que le cerveau a déjà absorbé plus de latence son/image que cela.

Quand les mecs cherchent à émuler exactement une machine (j'avais vu des comparaisons avec un léger décalage réalité/émulateur par exemple), ça me semble utile pour les joueurs, mais là...

Mais là quoi ? L'un n'empêche pas l'autre. Les mecs de RetroArch bossent sur des features utiles comme celle-ci pendant que les devs des différents émulateurs cherchent à émuler le plus fidèlement possible les différentes machines.

_Kame_ : C'est vrai que ça dénature l'expérience originale mais ça peut être utile pour compenser le lag induit par l'écran moderne et le calcul des filtres à la con.

aeio a écrit :
Mais là quoi ? L'un n'empêche pas l'autre. Les mecs de RetroArch bossent sur des features utiles comme celle-ci pendant que les devs des différents émulateurs cherchent à émuler le plus fidèlement possible les différentes machines.

Utile ? tu t'es gouré non ? C'est un trip de dév, ok, mais me dit pas que ça sert le gameplay.
L'un n'empêche pas l'autre, thx captain.

redtiger a écrit :
_Kame_ : C'est vrai que ça dénature l'expérience originale mais ça peut être utile pour compenser le lag induit par l'écran moderne et le calcul des filtres à la con.

Ah pitéte !

Les mecs de RetroArch doivent avoir une partie de l'équipe qui bosse dans la comm.
Le ratio dev / hype est à peu près de l'ordre d'un Gearbox.
Alors qu'il y a une approche "propre" proposée par des spécialistes ils viennent parader leur méthode bricolée à grands renforts de "mieux qu'en vrai !!!!!"

ça me fait penser à ça :



Quand je vois le taf abattu par les "vrais" dev d'émulateur, qui vont avec de la recherche, de l'investissement et de la pédagogie auprès de leurs publics... et que RetroArch vient pomper, puis font tourner le Patreon !!?
Je veux bien que 90% des utilisateurs veulent juste faire un trip rétro 1 ou 2 soirées entre potes et partent sur un retropie ou autre hack dégueu "clés en main", mais c'est les autres 10% de passionnés qui font avancer le shmilblick.

Mitaine a écrit :
Alors qu'il y a une approche "propre" proposée par des spécialistes ils viennent parader leur méthode bricolée à grands renforts de "mieux qu'en vrai !!!!!"
.

Aucun rapport ? Dans un cas on compense le lag introduit par un vrai hardware (donc pas introduit par un double buffering).

Dans l'autre on présente une solution pour les architectures qui font du rendu dans le front buffer (si je comprends bien).

On peut même combiner les deux !

À noter que dans Windows, il n'y a pas de garanti d'avoir accès au front buffer à cause du compositing qui est potentiellement "always on" (toujours présent). Plus réaliste en VR grâce au mode direct (on contourne Windows) mais comme disent les commentaires, en mode direct il sera peut-être possible de faire du rendu dans le front buffer (mais toujours limite dangereux avec le timing imprécis des PCs).