[EMULATION] Tearing/Stuttering/Inputlag

[Graham]

Je souhaitais partager mes comparaisons sur l'impact de la synchronisation vidéo sur le confort de jeu et la rigueur du rendu par rapport au matériel original.

Avant toute choses quelques définitions à connaitre :
- Tearing : Déchirement de l'écran.
L'image est alors séparée en deux parties. La ligne de déchirement peut être fixe ou mobile, selon la méthode de diffusion.
- Stuttering : Effet de saccade de l'image.
L'image n'est pas fluide et cela peut parfois entrainer des anomalies au niveau du son.
- Inputlag : Latence ressentie dans les commandes.

Pour effectuer ces tests, j'ai utilisé le matériel suivant :
- Panel : Sanwa 2P (relié par IPAC USB)
- Écran : LG 27MP65-C (relié en HDMI, résolution : 1080p, fréquence verticale : 60Hz)
- Carte graphique : GeForce GTX 660M (Résolution : 1920x1080, fréquence verticale : 60Hz)
- Processeur : Intel Core i7 2,40 Ghz
- Mémoire : 6,00 Go

Les versions de MAME ayant servi à ce comparatif :
- GroovyMAME 0.171 (OpenGL)
- MAMEUIFX 0.171 (OpenGL)
- ShmupMAME 4.2 (Direct3D)

Les ROMS ayant servi à la comparaison :
- Dimahoo (59.63Hz)
- Battle Garegga (60.0Hz)
- Battle Bakraid (60.0Hz)
- Mushihimesama Futari Black Label (60.0Hz)

J'ai débuté ces comparaisons lorsque j'ai commencé à utiliser MAME sur un écran LCD.
Le inputlag se ressent d'avantage sur les écrans LCD que sur les CRT, pour autant, j'avais du mal à croire que cela était une fatalité.

La première chose à savoir, est que l'émulation peut difficilement être aussi réactive que l'original, de la nature même de l'émulation. MAME a sur la plupart des jeux, au moins une frame de retard par rapport au matériel d'origine. Vous pouvez déjà mesurer facilement le retard d'émulation, et ainsi comparer différentes versions de MAME, avec un test très simple :
En jeu, vous mettez le jeu sur pause avec la touche P. Vous maintenez une touche directionnelle du clavier, tout en maintenant SHIFT. Et en pressant alors SHIFT+P, ainsi que la touche directionnelle, vous pouvez compter le nombre de frames qui passent avant que le sprite que vous contrôlez se déplace comme vous lui avez indiqué avec la touche directionnelle choisie.
En général, ce retard correspond à une frame, mais selon les émulateurs, il peut varier d'avantage.

Comparatif avec Ghox (joystik) :
- GroovyMAME 0.171 : 1 frame
- MAMEUIFX 0.171 : 1 frame
- ShmupMAME 4.2 : 0 frame

C'est incontestablement ShmupMAME qui est la version la plus optimisé en terme d'inputlag, seul souci, ShmupMAME n'a pas été mis à jour depuis 2013, et ne prend pas en charge l'OpenGL ou encore la compatibilité avec tous les ROMS rendus compatibles depuis 3 ans par l'équipe de MAMEDev.

Vous ne mesurez avec cette technique qu'une partie du inputlag, celle qui concerne l'émulation logicielle. Reste encore le lag matériel dû aux commandes et à l'envoi d'image à l'écran.

Pour réduire le inputlag matériel, ci-après quelques précautions à prendre :
- Ne pas ajouter de rallonge USB entre le PC et les commandes pour éviter tout retard du signal.
- Ne pas utiliser de paramètres de traitement de l'image dans les menus de l'écran (Utiliser le mode "Jeux-vidéo" de l'écran LCD)
- Ne pas utiliser de matériel de traitement de l'image qui serait installé entre le PC et l'écran, et qui pourrait retarder le signal d'avantage.
- Ne pas utiliser de paramètres d'économies d'énergie impactant le CPU. (Options d'alimentation)
- Ne pas utiliser de paramètres d'économies d'énergie impactant le GPU. (Paramètres de la carte graphique)



Les meilleurs solutions pour réduire le inputlag :

Dans le cadre de l'utilisation d'un CRT avec modeline, jusque là, pour lutter contre le inputlag, le mieux était d'utiliser la version 3.0b de ShmupMAME en mode DirectDraw.
Depuis peu, GroovyMAME a ajouté une option permettant de jouer avec le Frame Delay. Il est alors possible de réduire considérablement le inputlag, sans observer les anomalies graphiques que l'on observait dans ShmupMAME. GroovyMAME devient une alternative sérieuse, sachant qu'il permet de générer un modeline par ROMS, ce que ShmupMAME ne pouvait pas faire, et qu'il prend en charge d'avantage de ROMS. Le développeur du mod préconise d'ajuster le Frame Delay pour chaque ROM individuellement.
Pour cela, créer un fichier ".ini" avec comme nom, celui du rom, dans le dossier "ini". (Exemple : ini\pacman.ini)
Et inscrivez juste à l'intérieur les paramètres que vous voulez ajuster spécifiquement pour ce ROM, en l’occurrence le Frame Delay :

Code : Tout sélectionner

frame_delay               9

La valeur peut varier de 0 à 9.
A noter toutefois que sur certains ROMS, des anomalies graphiques semblables à celles de ShmupMAME peuvent apparaitre si la valeur est trop élevée.

Une autre option intéressante de GroovyMAME est d'avoir un mode vidéo exclusif à ce mod qui est : d3d9ex

Code : Tout sélectionner

video                     d3d9ex

C'est une version de Direct3D qui permet à l'application de mieux gérer le nombre de frames pré-traitées, ce qui a également pour but de réduire l'inputlag.

Pour les écrans LCD, la meilleur solution est d'utiliser un écran compatible avec le système G-Sync (Nvidia) ou FreeSync (ATI).
Ce système permet à l'écran d'envoyer à la carte graphique, son instant exact d'affichage de l'image et donne l'occasion à la carte graphique d'adapté son flux en fonction et d'avoir une synchronisation intelligente entre le PC et l'écran. Le gros inconvénient est le prix d'un tel système, car les écrans compatibles ne sont pas bon marché, et nécessite d'avoir la carte graphique compatible.

J'ai donc cherché d'autres méthodes, d'où mes comparaisons.

Pour mettre un point zéro à mes tests, j'ai désactivé toute synchronisation possible entre le PC et l'écran.
On obtient alors un flux d'image variant de 200 à 400fps.
Inutile de préciser que sur un écran de 60Hz, c'est tout simplement injouable.



Pour garantir une vitesse de jeu identique à l'originale, il faut donc utiliser l'option Throttle de MAME.



On obtient alors un jeu fluide, mais l'on observe un déchirement de l'image.

Deux solutions pour supprimer le tearing : Le V-SYNC Forcé ou le Triple Buffer.

Dans le panneau de configuration Nvidia :


Dans mame.ini :

Code : Tout sélectionner

waitvsync                 1

Le V-SYNC Forcé cumulé au Throttle donne une image sans tearing, mais avec de légères saccades particulièrement gênantes en jeu, surtout avec un tel inputlag.



Le Triple Buffer, s'est avéré lui, inefficace pour le OpenGL, mais à tout de même permis un résultat intéressant avec ShmupMAME.

Dans le panneau de configuration Nvidia :


Dans mame.ini :

Code : Tout sélectionner

triplebuffer              1

A défaut d'avoir une réponse optimale des commandes, j'ai cherché à synchroniser l'écran 60Hz avec un flux d'image limité à 60fps.

Pour ce faire j'ai utilisé RivaTuner Statistics Server. Les autres outils se sont avérés inefficaces dans la lutte contre le inputlag.



Tout comme le Throttle seul, on obtient alors un jeu fluide, mais l'on observe un déchirement de l'image.
On ressent moins l'inputlag que dans les configurations précédentes.

Pour lutter contre le déchirement, j'ai alors utilisé le V-SYNC Adaptatif.

Dans le panneau de configuration Nvidia :


Dans mame.ini :

Code : Tout sélectionner

waitvsync                 0

On ressent encore moins l'inputlag et l'on met fin au déchirement.
C'est avec cette configuration que j'obtiens les meilleurs résultats avec GroovyMAME.

Pour mettre fin à mes tests, j'ai alors testé le V-SYNC Adaptatif seul, et c'est là que j'ai noté les meilleurs résultats avec MAMEUIFX.



Dans le cadre de mon utilisation, la solution choisie a été MAMEUIFX avec le V-SYNC Adaptatif.
Le seul problème, est que la vitesse originale du jeu ne sera pas respectée si sa fréquence d'origine est différente de 60.0Hz.
Il est important de comprendre que même si la vitesse originale n'est pas respectée, le jeu est tout à fait jouable et plus l'écart entre la fréquence originale et les 60Hz est faible, moins ce changement de vitesse est perceptible. Par exemple, avec Dimahoo (59.63Hz), la différence est infime, en revanche sur Raiden Fighter Jet (54.00Hz), la différence est notable.

La meilleur configuration avec un écran LCD, serait de remplacer l'écran par un écran compatible G-Sync, de désactiver le V-Sync, même adaptatif, et de ne limiter le flux à 60fps qu'avec RivaTuner Statistics Server. On devrait obtenir un flux stable, fluide, et sans tearing, ni stuttering. Mais sans avoir le matériel adéquat, impossible de mettre en évidence une telle efficacité.
Et surtout, toujours ce problème de vitesse originale non respectée si sa fréquence d'origine est différente de 60.0Hz.

Pour des jeux à une fréquence différente de 60.0Hz, la seule solution pour avoir la vitesse originale serait d'utiliser un CRT, plus précis sur la fréquence verticale qu'un LCD, avec des modelines sur mesure et GroovyMAME.
Il serait alors possible, avec le Frame Delay d'obtenir un flux précis avec un inputlag minimisé et sans anomalies graphiques.

Pour terminer ce test, il faudrait pouvoir mesurer précisément le inputlag en filmant le panel, l'écran et un chronomètre précis avec une caméra ultrarapide, ce qui permettrait d'observer le mouvement du joueur et le temps exact de latence entre ce mouvement et la réaction à l'écran. Ne disposant pas du matériel nécessaire, je suis incapable d'effectuer ces mesures.
Ce serait alors plus fiable que se baser uniquement sur le ressenti du joueur, qui peut malgré tout être un critère, étant donné que le ressenti a selon moi plus d'importance que l'inputlag effectif.

Quelques discussions annexes sur le sujet :
Discussion autour du Frame Delay : http://forum.arcadecontrols.com/index.p ... c=133194.0
Comparaison entre le DirectInput et le RAWInput : http://forum.arcadecontrols.com/index.p ... c=145174.0
Article complet sur l'Inputlag en général : http://www.displaylag.com/reduce-input- ... ive-guide/




Ajout du 11/09/2016 :


J'ai essayer les paramètres conseillés par UltramanU.
Je n'ai plus du tout d'inputlag.

J'ai donc utilisé GroovyMAME 0.176.
J'ai désactiver le V-Sync dans les paramètres de la carte graphique.

J'ai d'abord tenté d'activer le d3d9ex, mais là, aucune image.

J'ai ensuite configuré MAME comme suggéré, en d3d classique :

Code : Tout sélectionner

autoframeskip             0
frameskip                 0
throttle                  0
syncrefresh               0
autosync                  1
sleep                     0
speed                     1.0
refreshspeed              0

video                     d3d

monitor                   lcd
orientation               vertical
sync_refresh_tolerance    2.5
frame_delay               9
vsync_offset              0

hlsl_enable               0

Et j'ai eu un jeu fluide et sans aucune latence d'aucune sorte.
Plus besoin de limiter le FPS à 60 avec un logiciel tiers grace à l'autosync.
Seul problème, je me suis retrouvé avec du tearing.

Mais GroovyMAME possède une option permettant de déplacer l'emplacement de la déchirure. (vsync_offset)
Vous pouvez alors déplacer la déchirure en dehors du champs de visibilité ou sinon jusqu'où votre carte graphique le permettra. Sachant que plus elle sera performante, plus vous pourrez déplacer cette déchirure.

La contrainte est que pour trouver la bonne valeur, je n'ai pas d'autre solution que d'y aller par approximation successive.

Sur ma configuration, en D3D sans HLSL la valeur est de :

Code : Tout sélectionner

vsync_offset              62

Et là, plus rien.
Parfait.

Seul souci, sur un LCD, le rendu D3D par défaut, c'est juste ignoble.
J'ai donc activé le mode HLSL.
Puis j'ai à nouveau ajusté la déchirure, car en effet, elle ne se situe pas au même endroit que l'on soit avec ou sans le HLSL.

Code : Tout sélectionner

autoframeskip             0
frameskip                 0
throttle                  0
syncrefresh               0
autosync                  1
sleep                     0
speed                     1.0
refreshspeed              0

video                     d3d

monitor                   lcd
orientation               vertical
sync_refresh_tolerance    2.5
frame_delay               9
vsync_offset              140

hlsl_enable               1

Le paramètre qu'il me reste à ajuster ce sont les couleurs qui sont beaucoup moins bien gérées qu'avec le shader Lottes CRT.
Mais question jouabilité, l'autosync de GroovyMAME, rend obsolète mon précédent comparatif.
Il aura au moins le mérite de mettre en évidence que le mode OpenGL de MAME accumule d'avantage de lag que le mode D3D.

Merci UltramanU pour ta suggestion.

[Piafoman]

Respect !

Je ne joue quasiment pas en émulation, mais preuve est de constaté que d'après tes tests on est très proche de l'original en terme d'inputlag.

Merci beaucoup pour ce beau dossier !

[Mug Superstar]

Clair, net, accessible ...
Merci



Mug

[Pierrot]

Respect !

Je ne joue quasiment pas en émulation, mais preuve est de constaté que d'après tes tests on est très proche de l'original en terme d'inputlag.

Merci beaucoup pour ce beau dossier !

Et encore, là c'est pour des dalle plate. Sur un tube catho en couplant GM et CRT emudriver et surtout les bon réglage (.ini) il n'y aucune différence perceptible avec un jeu bien émulé de l'originale (je dis "perceptible" car y a toujours les gens qui adore foutre 400 € dans un jeu et qui te diront "y a une frame incompressible !! Les emuls c'est de la mayrdeuuuu !!)

J'ai fait des test sur SSF2X côte à côte (emul et CPS2) jeu qui est taré niveau clock et inpout, en cause la relativité de l'espace temps avec chaque stage diffère. Bah c'était calé à la frame et tous les true reversal en sorti de tick (just frame les plus chiants) étaient exactement là où ils étaient sur CPS2.

[UltramanU]

Ouais GroovyMAME n'a pas été pensé pour être utilisé avec OpenGL mais bien D3D avec frame_delay ou D3D9ex, où là il règne en maître dans le domaine du lag.

Truc à savoir; les shaders peuvent rajouter du lag (je pense que certains s'en seront rendu compte), ça varie en fonction desquels mais c'est ce qu'avait découvert Filthypants lors de tests, malheureusement son propre crt-geom était l'un d'eux.
Un truc plus light comme crt-easymode devrait pallier à ça dans l'avenir.

Autre truc; GroovyMAME 0.176 est sorti et maintenant pour la réduction du lag et autres avantages propres au build, ça se passe sous BGFX.
D3D a carrément été supprimé de MAME il me semble.
Par contre c'est encore en 'alpha' donc prévoir des bricoles inédites côté CRT.
EDIT: pour la synchro et pas se prendre la tête dans une config LCD par exemple, il faut activer la nouvelle option 'autosync'. Pour déterminer la 'plage' d'utilisation de waitvsync plutôt que triplebuffer (en fait double piur ce dernier) suffit de déterminer son étendue avec l'option 'sync_refresh_tolerance', comme avant quoi, perso je fous 2.5, ce qui veut dire que jusqu'à 2,5Hz d'écart par rapport à la fréquence de mon moniteur - en l'occurrence 60Hz - c'est waitvsync qui sera utilisé, forçant la vitesse pour des scrollings fluides. Au delà de 2,5Hz groovy passe automatiquement au 'double'-buffering de son cru.
Moins de lag qu'avec les autres MAME & API dans les deux cas, sans hacks à la shmupmame.

Franchement faut laisser ShmupMAME reposer en paix...

[fafangus]

Merci pour ce dossier
Je vais m'en servir pour faire mon pc mame pour mon cab !!

[Aaron]

Très intéressant à lire. Même si les émulateurs offrent un panel de paramètres que l'on peut régler, souvent on ne sait pas trop sur quoi cela peut influer. Il faut se plonger souvent dans des tutos rédigés pour des utilisateurs déjà avertis.

Ensuite, tu suggères l'utilisation d'un écran Gsync et je n'y avait jamais pensé. J'espère que ça s'adapte bien et reste donc dans l'attente une confirmation

[Graham]

Très intéressant à lire. Même si les émulateurs offrent un panel de paramètres que l'on peut régler, souvent on ne sait pas trop sur quoi cela peut influer. Il faut se plonger souvent dans des tutos rédigés pour des utilisateurs déjà avertis.

Ensuite, tu suggères l'utilisation d'un écran Gsync et je n'y avait jamais pensé. J'espère que ça s'adapte bien et reste donc dans l'attente une confirmation

Sur le papier s'est effectivement le mieux, mais n'ayant pu le tester je suis incapable de te le confirmer.
Peut-être que certains membres du forum en possèdent et seraient succeptible de nous faire un retour.

[UltramanU]

Bah oui c'est le top G-Sync, de l'avis même de mamedev c'est la seule solution vraiment acceptable si on veut profiter d'une émulation fidèle (en termes de vitesse & lag) sur un écran plat.
Moi j'ai failli plonger mais c'est putain de cher en fin de compte et j'avais autre chose à faire de mon pognon.
FreeSync c'est pas mal non plus, c'est un peu moins cher, mais ça marche qu'en plein écran et les specifications/performances varient selon le modèle donc faut faire attention à ce qu'on achète.

Mais si vous voulez rire, savoir à quel point ces soi-disant technos de synchro variable sont du foutage de gueule marketing, vous aurez peut-être remarqué que certains ordis portables ont le chipset graphique directement relié à l'écran lcd intégré, sans scaler/contrôleur (hardware ou software) propre à celui-ci pour dicter sa loi au signal source, résultat: pas besoin de forcer la fréquence de sortie ni d'utiliser du buffering, et vu que les LCD n'ont pas à proprement parler besoin de vsync, bah le résultat c'est qu'on a la même chose que G-Sync/FreeSync mais 'gratos'.
Le mien est comme ça, je me demande à quel point c'est répandu, on pourrait penser que c'est 'normal' et donc très fréquent mais en fait non, je soupçonne que c'est lié au type de configuration cpu/gpu, OS et drivers (testez le votre!)
Pour ma part c'est un petit i3 avec une petite geforce en config 'optimus' sous Win 8.1, bah quand je joue là dessus pas besoin de vsync ni buffer, tout est fluide et à la bonne vitesse sans rien faire, pas de forçage dans le panneau de configuration non-plus.
J'ai vu Calamity parler de ça il-y-a qqes temps, dommage que ce soit limité aux portables, si on pouvait comprendre la logique et modder des lcd bah on pourrait se passer de G-Sync/FreeSync et économiser un max de fric.

PS: c'est possible aussi avec de vieux moniteurs, d'avant l'ère du HDMI et de la HD où toutes les entrées se sont retrouvées verrouillées aux standards de l'industrie, très orientée ciné/télé/gaming pc. Mais ces moniteurs sont au moins dix ans en arrière côté performances et qualité, le tradeoff est bof.

[Graham]

J'ai essayer les paramètres conseillés par UltramanU.
Je n'ai plus du tout d'inputlag.

J'ai donc utilisé GroovyMAME 0.177.
J'ai désactiver le V-Sync dans les paramètres de la carte graphique.

J'ai d'abord tenté d'activer le d3d9ex, mais là, aucune image.

J'ai ensuite configuré MAME comme suggéré, en d3d classique :

Code : Tout sélectionner

autoframeskip             0
frameskip                 0
throttle                  0
syncrefresh               0
autosync                  1
sleep                     0
speed                     1.0
refreshspeed              0

video                     d3d

monitor                   lcd
orientation               vertical
sync_refresh_tolerance    2.5
frame_delay               9
vsync_offset              0

hlsl_enable               0

Et j'ai eu un jeu fluide et sans aucune latence d'aucune sorte.
Plus besoin de limiter le FPS à 60 avec un logiciel tiers grace à l'autosync.
Seul problème, je me suis retrouvé avec du tearing.

Mais GroovyMAME possède une option permettant de déplacer l'emplacement de la déchirure. (vsync_offset)
Vous pouvez alors déplacer la déchirure en dehors du champs de visibilité ou sinon jusqu'où votre carte graphique le permettra. Sachant que plus elle sera performante, plus vous pourrez déplacer cette déchirure.

La contrainte est que pour trouver la bonne valeur, je n'ai pas d'autre solution que d'y aller par approximation successive.

Sur ma configuration, en D3D sans HLSL la valeur est de :

Code : Tout sélectionner

vsync_offset              62

Et là, plus rien.
Parfait.

Seul souci, sur un LCD, le rendu D3D par défaut, c'est juste ignoble.
J'ai donc activé le mode HLSL.
Puis j'ai à nouveau ajusté la déchirure, car en effet, elle ne se situe pas au même endroit que l'on soit avec ou sans le HLSL.

Code : Tout sélectionner

autoframeskip             0
frameskip                 0
throttle                  0
syncrefresh               0
autosync                  1
sleep                     0
speed                     1.0
refreshspeed              0

video                     d3d

monitor                   lcd
orientation               vertical
sync_refresh_tolerance    2.5
frame_delay               9
vsync_offset              140

hlsl_enable               1

Le paramètre qu'il me reste à ajuster ce sont les couleurs qui sont beaucoup moins bien gérées qu'avec le shader Lottes CRT.
Mais question jouabilité, l'autosync de GroovyMAME, rend obsolète mon précédent comparatif.
Il aura au moins le mérite de mettre en évidence que le mode OpenGL de MAME accumule d'avantage de lag que le mode D3D.

Merci UltramanU pour ta suggestion.

[UltramanU]

Ah. En fait je comprends pas comment ça marche parce que D3D n'est plus censé fonctionner, donc je soupçonne que MAME dans ton cas sélectionne un autre API par défaut, peut-être BGFX ?
(tu peux voir ce qui se trame en observant la console en temps réel quand tu es en fenêtré, ou alors en faisant un log)

De tte façon comme le disait Calamity maintenant on est censé utiliser BGFX, il a optimisé SwitchRes et son système pour celui-ci.

Si autosync est activé normalement c'est pour laisser SwitchRes changer automatiquement entre syncrefresh et triplebuffer en fonction de la limite que tu choisis avec sync_refresh_tolerance.
Dans ce cas là du coup je sais pas si régler manuellement frame_delay et offset fonctionne, ou si c'est le fait de se servir de ces derniers qui a la priorité sur autosync (même s'il est activé).

J'ai pas encore suffisamment exploré le truc (trop pris en ce moment) faut dire que c'est toujours en version alpha et qu'il y aura des changements avec chaque nouveau build.
Perso j'ai encore quelques problèmes de stabilité quand syncrefresh est activé via autosync ou non (et oui bien sûr je suis sous BGFX).

Au fait attention avec les shaders, ils rajoutent du lag.
Moi je fais encore mes .png à la main pour simuler scanlines et effets d'aperture/mask. C'est pas aussi sophistiqué que les shaders bien entendu, pas de réglages du beam, blooming etc, et il faut presque obligatoirement utiliser l'integer scaling avec. Néanmoins c'est toujours très flexible parce qu'on peut inventer les formes qu'on veut et ajuster les couleurs au pixel près, et surtout ... pas le moindre lag ajouté.

[Graham]

Alors effectivement, cela mérite quelques précisions.

Déjà j'avais commencé mes tests avec la version 0.176. Puis j'ai souhaité vérifié que j'avais les mêmes resultats avec la 0.177, et je pensais que c'était le cas.
Sauf qu'en fait non. J'ai à peu prés le même résultat qu'avec MAMEUIFX 0.171. Mais tout ceci est tellement subtile, que la différence est parfois infime.

Donc je suis repassé à la version 0.176, et j'ai retrouvé la fluidité que j'avais annoncée.

Ensuite que ce soit avec la version 0.177 ou la version 0.176, cela ne fonctionne que si :
1) Si autosync est activé
2) Si le sync_refresh_tolerance est supérieur ou égal à 0.85
3) Si le framedelay est supérieur ou égal à 1
4) Si monitor indique lcd (et exclusivement lcd, toutes autres valeurs ne permettent pas la synchro.)
Si l'une de ces quatre conditions n'est pas respectée, je perd la synchro et je me retrouve avec 400fps.

Code : Tout sélectionner

autosync                  1
monitor                   lcd
sync_refresh_tolerance    2.5
frame_delay               9

Ensuite concernant le lag généré par le HLSL.
Ce qui est intéressant dans le cas du réglage du vsync_offset, c'est de pouvoir mesurer finalement le décalage généré par les paramètres.
A titre indicatif j'ai donc quelques valeurs, toujours en D3D (sans BGFX) :

Sans HLSL :
Je dois ajuster le vsync_offset à 62 pour faire disparaitre la déchirure.

Avec le HLSL, sans bloom, et sans defocus :
Je dois ajuster le vsync_offset à 140 pour faire disparaitre la déchirure.

Avec le HLSL, avec bloom, mais sans defocus :
Je dois ajuster le vsync_offset à 200 pour faire disparaitre la déchirure.

Avec le HLSL, sans bloom, mais avec defocus :
Je dois ajuster le vsync_offset à 200 pour faire disparaitre la déchirure.

Avec le HLSL, avec bloom et defocus :
Je dois ajuster le vsync_offset à 280 pour faire disparaitre la déchirure.

Avec le HLSL, avec yiq (NTSC POST PROCESSING), sans bloom, ni defocus :
Je dois ajuster le vsync_offset à 340 pour faire disparaitre la déchirure.

Avec le HLSL, avec yiq (NTSC POST PROCESSING), et avec defocus, mais sans bloom :
Je dois ajuster le vsync_offset à 440 pour faire disparaitre la déchirure.

Avec le HLSL, avec yiq (NTSC POST PROCESSING), et avec bloom, mais sans defocus :
Je dois ajuster le vsync_offset à 440 pour faire disparaitre la déchirure.

Avec le HLSL, avec yiq (NTSC POST PROCESSING), avec bloom et defocus :
Je dois ajuster le vsync_offset à 540 pour faire disparaitre la déchirure.

Donc le mieux pour optimiser la jouabilité, est de ne pas activer ces trois paramètres.

Code : Tout sélectionner

yiq_enable 			0
bloom_scale 		  0
defocus 			   0,0

L'activation du HLSL seul me semble un bon compromis.
Il y a pas mal de paramètres sur lesquels l'on peut jouer, sans pour autant activer les 3 paramètres gourmands en ressources.
Il y a peut-être d'autres paramètres générant du lag, mais je ne les ai pas tous testés.

[Graham]

Je viens me rendre compte que si j'activais le syncrefresh, que je mettais 0 à sync_refresh_tolerance et que désactivais le autosync, j'arrivais exactement au même résultat.
Je m'en suis rendu compte parce que lorsque je mettais 2.5 à sync_refresh_tolerance, Raiden Fighter ne se synchronisait pas, mais si je lui mettais 6.1 (soit 60hz la fréquence de mon écran moins 53.98hz la fréquence du ROM), le jeu se synchronisait.

Code : Tout sélectionner

autosync                  0
syncrefresh               1
monitor                   lcd
frame_delay               9

En fait je ne faisais que forcer le syncrefresh avec l'autosync et une tolérance suffisante pour pas que je vois de différence.

Moralité, l'autosync n'était pas la solution dans mon cas, mais bien ce syncrefresh que je n'avais plus utilisé depuis MAME 0.92.
Parce que le problème du syncrefresh c'est qu'il ne corrigeait pas la problématique du tearing.
Mais effectivement, maintenant que Calamity à intégrer l'option vsync_offset, le syncrefresh devient clairement la solution évidente, puisque l'on peut ajuster manuellement la position de cette déchirure. Cela en combinaison avec le FrameDelay et l'inputlag sur MAME disparait enfin.

Du coup je comprend mal l'intérêt de l'autosync, puisqu'une fois le vsync_offset ajusté, il n'y a plus de raison de basculer sur un autre mode que le syncrefresh.

[UltramanU]

Mais autosync ne sert qu'à switcher automatiquement entre syncrefresh et triplebuffer, c'est juste un truc pratique.
Comme je disais je ne pense pas qu'on puisse l'utiliser en même temps que les options manuelles, mais autrement, tu vas voir plus bas dans mon post.

Un truc à mettre au clair avant d'aller plus loin c'est que l'intérêt du triplebuffer (qui depuis 0.176 sous BGFX est en fait un 'double' multithreadé fait maison pour moins de lag) est de synchroniser les jeux très en dessous de 60Hz, genre les MK ou vieux Irem, tout en conservant la vitesse originale...au prix de saccades, bien entendu.
Bon.
Si tu ne veux pas t'en servir et que tu fous tout contrôlé par syncrefresh, c'est sûr là tu peux ajuster manuellement le delay et l'offset en fonction de ce que ton moniteur permet (en général avec les lcd; pas grand chose) mais c'est au prix de vitesses altérées.

Tu peux laisser autosync activé avec tolérance à 2 ou 2.5 d'écart dans mame.ini et ne pas toucher au reste (0), ça constituera le comportement par défaut.
Ensuite tu peux créer des .ini spécifiques pour chaque hardware ou même chaque jeu, sachant que les .ini ont un ordre de priorité, qui je crois est
jeu.ini > driver.ini > mame.ini
(on peut faire aussi horizont.ini & vertical.ini, et probablement plusieurs autres qui ont aussi une place dans la hiérarchie)
Pas besoin de recopier mame.ini en entier, il suffit de mettre uniquement les sections qui t'intéressent.

EX; si dans le folder [ini] tu as un fichier cps2.ini, et que dans ce fichier tu as recopié la section 'core switchres options' avec les paramètres exacts que tu désires pour ce hardware, eh bien c'est ceux-ci qui s'appliqueront (et non pas ceux de la même section dans mame.ini)
Et au delà même chose si tu as un fichier sf2ce.ini, c'est ce que tu auras inscrit dedans qui aura le pas sur mame.ini, avant même cps2.ini

L'idéal est d'avoir un .ini pour chaque hardware émulé (ça fait beaucoup mais honnêtement avec 10 ou 20 on couvre déjà un max de jeux) et les valeurs idéales réglées au poil près en fonction de ce que le moniteur et la cg permettent.
Aucun ne va avoir les mêmes valeurs idéales de frame_delay et vsync_offset, et comme je disais pour certains c'est même un peu trop pousser que d'utiliser syncrefresh (vitesse à 110% ou plus, bof bof) on est sur lcd que diable! sans un truc comme G-Sync il n'y a pas de solution viable pour des jeux en 54~55Hz, donc ceux-là autant les laisser aux mains du triplebuffer, sinon faut jouer dopé.

Certes. Enfin.

Ce que je voulais dire à la base, c'est que pour tous ceux qui ne veulent pas se prendre la tête à faire plein d'inis et donc n'utiliser que mame.ini (qu'il faut au préalable créer en lignes de commandes pour ceux qui n'ont pas suivi) : il faut simplement mettre lcd et BGFX, activer autosync et choisir la tolérance (2 ou 2.5 Hz max perso je trouve que ça va, en gros ça englobe la plupart des shmups et jeux de pif qui 'comptent' et se retrouvent donc syncrefreshés/fluides)
Ça sert de configuration par défaut, un compromis entre fluidité pour une grande partie des jeux, et vitesse respectée pour l'autre, mais avec toujours moins de lag que les autres builds MAME, y-compris l'original qui n'a encore aucun de ces avantages.

Code : Tout sélectionner

autosync                  1
monitor                   lcd
sync_refresh_tolerance    2  (ou 2.5, ou même 3 etc, pour ceux qui veulent toujours du scrolling fluide et se foutent totalement que les jeux tournent trop vite)
video                     bgfx

Par contre pour ceux qui veulent la même chose mais toujours en Direct3D il faut revenir à GroovyMAME 0.171 et faire:

Code : Tout sélectionner

monitor                   lcd
sync_refresh_tolerance    2  (ou 2.5, ou même 3 etc, pour ceux qui veulent toujours du scrolling fluide et se foutent totalement que les jeux tournent trop vite)
video                     d3d9ex  (oui le 'ex' est essentiel, attention c'est seulement pour Win vista/7/8/10)

EDIT: pardon j'avais oublié il n'y a pas encore d'option autosync dans 0.171, en fait dans cette version il ne faut rien changer du tout à ce niveau, juste s'assurer que switchres est activé peut-être, le reste se fait tout seul, déjà automatiquement, voui.

^ note sur D3D9EX: Je dis ça pour ce dernier parce que - je le répète - il me semble bien que tout ce qui est Direct3D/Direct3D9ex ne marche plus ou plus correctement depuis environ 0.172 ou 0173. MAMEdev ont fait une croix dessus.
Il est possible qu'en croyant utiliser D3D ou D3D9ex vous ne vous rendiez pas compte que MAME force automatiquement OpenGL ou BGFX au lancement de l'émulation, vous étonnez pas si vous voyez alors des bizarreries ou que votre configuration ne marche pas comme vous l'attendiez.

PS: pour les Raiden Fighters honnêtement je trouve que ça vaut pas le coup, si tu les 'syncréfreshe' et que t'appuies sur F11 en cours de jeu tu vois le massacre, c'est fluide certes mais tellement accéléré qu'on est loin des conditions originales.
A la rigueur je comprends qu'on puisse s'en accommoder, ok, mais le son reste à chier, autant utiliser RaidenMAME avec les packs de samples et forcer la synchro avec ta carte graphique, il y aura un peu plus de lag qu'avec un Groovy bien réglé, mais avec un moniteur qui n'a quasiment pas de lag ça compense assez bien.
Enfin question de priorités.
Si on a les sous mieux vaut se payer la compile sur 360 (le top).

[Slud]

Salut!

Déjà merci à l'auteur pour son travail, les posts comme celui-ci sont rares, et cela fait plaisir de voir que je ne suis pas seul à lutter contre l'input lag.

Je joue principalement aux shmups, Cave, Psikyo, Raizings...

Je passe des heures en test pour obtenir le top mais la je sèche.
Ma config : Lcd lag free (ou presque), GTX 970 - I5 2500k.

Ma question. Avec cette config, quel serait le meilleur mame à utiliser pour avoir le moins d'input lag, pouvoir utiliser le bgfx, et éliminer le tearing (la solution de déplacer la déchirure me convient tout à fait mais je ne sais pas comment faire).

Mes test me conduisent à ceci :

Shmupmame est de loin le meilleur question input lag, 1 frame de moins que tous les autres Mame en moyenne, et sur certains encore plus. Bonus appreciable, le tearing est nettement moins visible aussi, je ne sais pas pourquoi.
L'inconvénient c'est qu'il ne propose pas le bgfx ni opengl, que j'aimerais absolument pour mettre le shader crt-geom.

J'aimerais essayer groovy mame, mais il me semble que c'est surtout pour les vrais ecrans crt et en plus il est en ligne de commande sans interface et je suis une quiche.

Bref je suis au pied du mur, testé un paquet de choses, bidouillé les ini en suivant des conseils, paramétré les options de CG, Vsync, Triple buffer, etc...

J'ai quasiment tout éssayé avec une seule conclusion : Tout rajoute toujours de l'input lag, parfois énorme, parfois léger, mais toujours génant. Rien de ce que j'ai éssayé ne rivalise avec Shmupmame question input lag.

Au jour d'aujourd'hui, que faire, quel mame prendre, et que faut-il paramétrer pour avoir le moins d'input lag possible sur lcd (comme shmupmame), pouvoir mettre le bgfx, le tout sans tearing (ou en déplaçant la déchirure)?

[Graham]

Salut Slud !

Tu peux tout à fait utiliser GroovyMame avec un écran LCD.
Il suffit de mettre :

Code : Tout sélectionner

monitor                   lcd

dans le fichier mame.ini