Box 15khz et lag (retard d'affichage)

[emilealpi]

Un mot clair de Calamity sur le sujet Ddraw Vs D3D :

"D3D has achieved the same results than DirectDraw since day 1 of GroovyMAME history. In fact, when magic resolutions were implemented five years ago, I strongly recommended using D3D all the time in order to avoid issues. This was all for XP, five years ago. The reason people has sticked with DirectDraw must be due to some kind of superstition.

It was much later that it was found out that D3D had added latency with ATI drivers at least. This was an unexpected point in favour of DirectDraw at the time, but very soon D3D became as good as DirectDraw latency-wise thanks to frame_delay."

Conformément à ce que j'ai constaté moi même en test, D3D est plus rapide que Ddraw en émulation et pas plus laggy grâce à frame_delay (il l'est même moins sur ma box). Sans filtre, son rendu est bien crispy comme directDraw qui ne présent plus grand intérêt, je comprends qu'ils le laissent tomber, ça fait tout de même 5 ans que Groovymame utilise de préférence d3d à Ddraw.

[UltramanU]

Oui mais attends, je connais un peu la façon de s'exprimer de Calamity, il part toujours du principe qu'on a compris tout ce qui est implicite dans son discours comme si tout le monde lisait ses posts au quotidien, et tu vas trouver que je suis lourd mais à mon avis ils dit 'D3D' sans préciser 'D3D à l'époque avec ses drivers sous XP' et 'aujourd'hui avec D3D9ex' (implicitement: sous Vista>10).

Moi je l'ai lu plusieurs fois dire qu'il ne faut plus utiliser D3D 'tout court'.
De toute façon quand on joue la différence avec D3D9ex se sent tellement que c'est évident.

[emilealpi]

Oui mais attends, je connais un peu la façon de s'exprimer de Calamity, il part toujours du principe qu'on a compris tout ce qui est implicite dans son discours comme si tout le monde lisait ses posts au quotidien, et tu vas trouver que je suis lourd mais à mon avis ils dit 'D3D' sans préciser 'D3D à l'époque avec ses drivers sous XP' et 'aujourd'hui avec D3D9ex'.

Moi je l'ai lu plusieurs fois dire qu'il ne faut plus utiliser D3D 'tout court'.
De toute façon quand on joue la différence avec D3D9ex se sent tellement que c'est évident.

Merci de ces précisions. Je serais très curieux de faire de l'input-lag checking sous D3D9ex. Je suis néanmoins étonné de constater que j'ai certains titres sans lag, enfin moins d'un frame en tout cas, sous XP (Bubble bobble notamment) alors qu'ils tournent sous "Win XP et D3D tout court" avec syncrefresh et framedelay. La puissance intrinsèque de la machine joue manifestement beaucoup dans le traitement de cette dernière option.

[UltramanU]

Je voudrais pas te dire de bêtises mais perso c'est comme ça que je l'ai compris, les conditions ne sont pas les mêmes sous XP/32, et en tout cas sous Vista et + c'est évident que 9ex est plus rapide.

Quand au lag de chaque jeu/hardware émulé pris individuellement, j'ai jamais reçu de réponse claire là dessus mais comme je le comprends tout ce qu'on fait pour réduire le lag ne concerne que la couche vidéo de MAME.
Le lag du jeu/hardware en question, lui, est lié au driver, donc soit avec un délai fidèle à l'original (pcb) s'il est bien fait, soit potentiellement plus long si les gars qui l'ont codé n'ont pas tout résolu et appliqué une frame ou deux supplémentaires à celui-ci pour faire 'tenir' les choses ensemble.
(ShmupMAME supprimait un buffer de sprites/layer directement dans les driver = mauvaise idée)

Nous quand on utilise GM on doit utiliser les meilleurs paramètres en fonction des situations (version de Windows et type de moniteur) puis pour en revenir à ce que disait Yuko avec un MAME directement compilé dans un OS il est possible de se passer complètement de ces choses (bien que ça ne soit valable en principe que pour une config crt) et donc également d'économiser des ressources.

Quoiqu'il en soit j'attends de voir les prochains développements, parce que je ne suis pas certain que tout aille bien en ce moment, passage définitif à D3D9ex ou non, les changements que MAME subit en ce moment sont nombreux.
Si D3D9ex ne suffit plus à toutes les résolutions pour crt dans ce contexte, j'ai l'impression que GM devra tenter le passage à BGFX pour tous les usages, crt inclus. Mais on n'en est pas encore là.

[CitrikElektrik]

[troll]L'avenir c'est Vulkan. [/troll]

[Yuko]

Nous quand on utilise GM on doit utiliser les meilleurs paramètres en fonction des situations (version de Windows et type de moniteur) puis pour en revenir à ce que disait Yuko avec un MAME directement compilé dans un OS il est possible de se passer complètement de ces choses (bien que ça ne soit valable en principe que pour une config crt) et donc également d'économiser des ressources.

Tu prends des risques, là.

Mais c'est valable aussi en LCD (tout dépend de l'écran et surtout des pilotes que tu utilises ; indice : les standards valent mieux que les marques. ).

[lorenzo33]

Calamity fait bien le distinguo entre D3D et D3D9ex. Et dans son post il parlait bien de D3D qui avec du frame_delay et équivalent au DirectDraw. Mais bon plus chiant à mettre en oeuvre.
Et comme tu le dis l'avenir c'est D3D9ex déjà fonctionnel et le BGFX qui a fait son entrée dans GroovyMAME.

GroovyMAME 0.171 is out.

What's new in SwitchRes v0.015m
- (Windows 7+) Preliminar support for the new BGFX renderer (currently only DirectX 11). Mode setting is implemented. Dynamic resolution switching may be buggy yet. Frame delay not implemented yet

[stickcross]

Nous quand on utilise GM on doit utiliser les meilleurs paramètres en fonction des situations (version de Windows et type de moniteur) puis pour en revenir à ce que disait Yuko avec un MAME directement compilé dans un OS il est possible de se passer complètement de ces choses (bien que ça ne soit valable en principe que pour une config crt) et donc également d'économiser des ressources.

Tu prends des risques, là.

Mais c'est valable aussi en LCD (tout dépend de l'écran et surtout des pilotes que tu utilises ; indice : les standards valent mieux que les marques. ).

Comme quoi Yuko ne dis pas que de la merde, c'est juste ta façon de le dire qui le fais pas. C'est un truc que j'ai oublié de spécifier pour la CrossBox mais je compile toujours mes Groovy moi même par rapport à mon Hard et en 64bits. La base de l'émulation reste quand même au niveau du processeur, si c'est déja pas bon la le reste sert à rien.

Au passage je rêve plus à un MAME qui gère vraiment le multithreading pas juste sur une poignée de jeux, la je pense qu'il y aurait vraiment un gros plus. Car au final la CG sert pas à grand chose dans tout ça, une de mes incompréhensions sur la hype de la HD4890 qui ne sert à rien à part faire du bruit.



J'ai aussi fait des tests avec le Frame Delay à 4, pour moi je ne vois ressent aucune différence. J'ai par contre des jeux qui ne fonctionnent plus correctement (PGM peut etre d'autre pas eu le temps de tout testé) et c'est bien la crainte que j'avais, il faut faire du cas par cas. Donc je confirme c'est bien lourd à mettre en place pour au final surement pas grand chose.
Donc retour à D3D tout court comme à mes débuts c'est ce que j'avais compris, on m'avais convaincu à un moment de passer en ddraw, mais au final je croit que c'est kifkif.


Si quelqu'un a une idée aussi sur le phénomène de l'entrelacé mal géré par seven ce serai top? Car c'est vraiment pas bon de ce coté la (ralentissement ou saccade sur le Type X). J'avais aucun problème avec XP mais passage à seven obligé à cause du harware récent.

[emilealpi]

Comme quoi Yuko ne dis pas que de la merde, c'est juste ta façon de le dire qui le fais pas. C'est un truc que j'ai oublié de spécifier pour la CrossBox mais je compile toujours mes Groovy moi même par rapport à mon Hard et en 64bits. La base de l'émulation reste quand même au niveau du processeur, si c'est déja pas bon la le reste sert à rien.

Au passage je rêve plus à un MAME qui gère vraiment le multithreading pas juste sur une poignée de jeux, la je pense qu'il y aurait vraiment un gros plus. Car au final la CG sert pas à grand chose dans tout ça, une de mes incompréhensions sur la hype de la HD4890 qui ne sert à rien à part faire du bruit.



J'ai aussi fait des tests avec le Frame Delay à 4, pour moi je ne vois ressent aucune différence. J'ai par contre des jeux qui ne fonctionnent plus correctement (PGM peut etre d'autre pas eu le temps de tout testé) et c'est bien la crainte que j'avais, il faut faire du cas par cas. Donc je confirme c'est bien lourd à mettre en place pour au final surement pas grand chose.
Donc retour à D3D tout court comme à mes débuts c'est ce que j'avais compris, on m'avais convaincu à un moment de passer en ddraw, mais au final je croit que c'est kifkif.


Si quelqu'un a une idée aussi sur le phénomène de l'entrelacé mal géré par seven ce serai top? Car c'est vraiment pas bon de ce coté la (ralentissement ou saccade sur le Type X). J'avais aucun problème avec XP mais passage à seven obligé à cause du harware récent.

Le pire c'est que je compile également moi même mes versions de MAME, vaut mieux sous linux .

La carte graphique ne sert à rien avec Ddraw, mais il semble que ses ressources soient sollicitées en D3D pour la couche video de mame.

Concernant le frame_delay, tu pourrais le mettre par défaut à 1 dans ton mame.ini, cela permettrait au moins d'éradiquer les 3 frames de queues de D3D sans perturber ton framerate

Les résos entrelacées sous 7 posent toujours des problèmes, il me semble que Calamity travaille justement dessus.

[lorenzo33]

Si quelqu'un a une idée aussi sur le phénomène de l'entrelacé mal géré par seven ce serai top? Car c'est vraiment pas bon de ce coté la (ralentissement ou saccade sur le Type X). J'avais aucun problème avec XP mais passage à seven obligé à cause du harware récent.

Certains modèles de cartes graphiques sont plus touchés que d'autres apparemment notamment dans les HD5xxx, HD6xxx.
Après je ne pense pas que Calamity travaille particulièrement dessus.

http://forum.arcadecontrols.com/index.p ... msg1562328

[stickcross]

Le pire c'est que je compile également moi même mes versions de MAME, vaut mieux sous linux .

La carte graphique ne sert à rien avec Ddraw, mais il semble que ses ressources soient sollicitées en D3D pour la couche video de mame.

Concernant le frame_delay, tu pourrais le mettre par défaut à 1 dans ton mame.ini, cela permettrait au moins d'éradiquer les 3 frames de queues de D3D sans perturber ton framerate

Les résos entrelacées sous 7 posent toujours des problèmes, il me semble que Calamity travaille justement dessus.

Je suis ok avec toi en D3D, mais ça doit pas trop la chatouiller non plus, j'avais à un moment une petite 4350 et elle ce démerde aussi bien qu'une 4890, en tout cas sur MAME.

Je testerais un peut plus avec la valeur à 1.

Pour l'entrelacé c'est ce que j'ai compris avec son dernier driver, mais toujours pas testé.

Si quelqu'un a une idée aussi sur le phénomène de l'entrelacé mal géré par seven ce serai top? Car c'est vraiment pas bon de ce coté la (ralentissement ou saccade sur le Type X). J'avais aucun problème avec XP mais passage à seven obligé à cause du harware récent.

Certains modèles de cartes graphiques sont plus touchés que d'autres apparemment notamment dans les HD5xxx, HD6xxx.
Après je ne pense pas que Calamity travaille particulièrement dessus.

http://forum.arcadecontrols.com/index.p ... msg1562328

Je suis que sur des HD4XXX, sur les autres plus récente je comprend plus rien à ce qu'il dit, car il disait à l'époque que le DOT clock des cartes récente n'étaient pas bon et maintenant il les exploite
C'est clair cette histoire, ce serait top si c'est possible d'avoir la même chose, cela ferait une Box ultime dans tous les cas, alors qu'avec les HD4XXX on est limité par le directX10 caca

[UltramanU]

@lorenzo33: Disons qu'il ne précise pas toujours le contexte/OS, j'ai l'habitude de le voir faire des raccourcis ou donner des réponses laconiques.
Pour des gens qui sont sous Win 7 et plus il dit "quoi vous n'êtes pas encore passés à D3D?" alors qu'il sous-entend D3D9ex.
GM n'est pas ce que j'appellerais le build le mieux documenté ni le plus pédago au niveau du support, rien que le guide officiel ne mentionne pas la distinction D3D9ex parce qu'il n'a pas été mis à jour depuis longtemps.

@Yuko: là pour les moniteurs tu t'avances, si tu veux parler des rares modèles qui ne sont pas bridés au niveau de l'EDID; on ne peut quand-même pas leur envoyer ce qu'on veut comme résolutions à n'importe quelle fréquence. En plus c'est souvent des moniteurs pro/industriels soit avec un panel de merde, du lag, ou les deux.

@stickcross: moi j'ai pas dit qu'il racontait des conneries en ce qui concerne MAME, au contraire, non c'est la démarche "votre Groovy c'est de la merde, je vais vous faire la morale" + "mais pour que je partage ma science avec vous faudra me payer" qui est pas passée.
Un cas Bordeau Chesnel quoi.

[CitrikElektrik]

Je suis que sur des HD4XXX, sur les autres plus récente je comprend plus rien à ce qu'il dit, car il disait à l'époque que le DOT clock des cartes récente n'étaient pas bon et maintenant il les exploite
C'est clair cette histoire, ce serait top si c'est possible d'avoir la même chose, cela ferait une Box ultime dans tous les cas, alors qu'avec les HD4XXX on est limité par le directX10 caca

J'ai fait le choix d'une hd5450 sur la dernière box. Et bah je pleure du sang. Tu te souviens de mon problème de câble vga/peritel ? En fait c'était lié à de mauvais timming sous vmmaker 2.0. Workaround : installer les modelines avec vmmaker 1.4.

Et là, je ne trouve pas les super resolutions. J'ai du me payer un thread d'Arcade control en espagnol pour comprendre que plein de monde rencontre le problème. Workaround : définir des super resolutions en 1280 en progressif. Calamity dit que l'écran ne risque rien parce switchres sait que ce n'est pas la vrai res à appliquer.
Workaround 2 : foutre une résistance sur le câble vga...

Bref, les hd5xxx c'est sport. Et encore je ne te parle pas de l'émulation EDID...