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