Help with d3d9ex not launching correctly

[markmsx2]

Hey everyone,

I've recently put together a GM setup to do some lag testing. Initially I found that the lag in my tests were about 2-3 frames higher than I was hoping. So I did some research and, from what I understand, these frames can be removed by using d3d9ex video driver, instead of d3d.

However, when I change the setting in the .ini file, my CRT video goes blank. I did try and launch a game and I am able to hear ketsui running, despite the black screen, but the sound is all sped up and it sounds glitchy.

I am playing on a NTSC 31 hz VGA monitor, OS is windows 7,  and the GPU I am using is the AMD Radeon HD 7570 1GB 128-Bit GDDR5. I've actually tried this on a computer with a modest CPU and my main rig with a fairly powerful CPU, both have the same issue.

Any idea how to resolve this issue? To me getting d3d9ex running and removing this input lag is very important.

Any advice would be greatly appreciated.

--Mark MSX

[schmerzkaufen]

If you're using the 'win 7 8 10' build, it's set on d3d9ex by default, you just leave video on 'auto' in the ini. Blank screen is expected if you change that to something else.

d3d9ex reduces the sync frame queue which is usually of 3 frames, to just 1 (the games have therefore only one additional frame of lag vs. pcb), this has no CPU cost.

Then if you're going to use frame delay I would advise sticking to 0.207 for now because there's a problem in 0.208 that breaks the feature somehow.

frame delay is used to chew out some more miliseconds from that last frame if you want, but at some CPU cost, to reach frame delay 8 or 9 with some games you need a fairly powerful one.

Funny you're talking about testing lag, I was just looking for a member's lag tests he's done some time ago with groovy but using freesync. the spreadsheet he posted is gone unfortunately.


PS: forgot to tell you at default settings the games that are less than 58Hz will use triple buffering instead of vsync, it doesn't work with frame delay and might produce different lag am not sure. if you want more games to sync you should increase 'sync refresh tolerance'
otherwise it would be better and more accurate to install CRT Emudriver anyway if you haven't yet (not sure but I think VMmaker has modeline presets for vga crt monitors)

[markmsx2]

Thanks man! Got is sorted. Yep my findings reflect what you talked about, at least with DOJ. PCB is 2 frames and GrooveyMame delivered 3. :-)

[schmerzkaufen]

You could test twice, once for the default (i.e def d3d9ex lag is 2+1 frames) vs. same game but with framedelay activated as high as your PC can afford there (2+?) 

That would be a result in 2 + some miliseconds though. If you round the results in frames instead of miliseconds it'll be unpractical in a chart.

But maybe you're not interested in frame delay performance, like I said earlier I was sniffing around for oomek's freesync lag results because they're basically the pure lag of the games as it is supposed to be (well, AFAIK, dunno if freesync has drawbacks I wouldn't be aware of delay-wise) without a need for a strong CPU nor precise individual settings. Convenient.

EDIT: hey I've seen this; http://electricunderground.io/shmup-input-lag-database/

Dodonpachi DiaOuJou (Black Label)
(6 Frame Delay ON)   3      100%   OFF!   CRT VGA   Hori VX-SA (360)

That doesn't feel too right, have you touched the sync settings ? you're not supposed to, frame delay works with groovymame's sync to begin, not without, it's mandatory.
autosync 1 -> you leave that on, you don't touch any other sync-related settings in the ini.
The only thing you should touch in your case since afaik you don't seem to have installed CRT Emudriver, is sync_refresh_tolerance if you want to experiment with games that have an original refresh lower than 58Hz (for instance increase it to 2.5 - it's Hz - and the Cave 1st gen games will be included in the sync)
Your result with frame delay can only be below 3 frames (it should be around 2.5 or something) but since you're not measuring in miliseconds it's hard to guess what's actually the result)
. DaiOuJou's lag is 2 frames, the pcb - and MAME/groovymame - are theoritically the same, you should get that result with autosync 0 (off), not 3.
. then d3d9ex default (autosync 1) is 2+1 = 3
. then d3d9ex + frame_delay (autosync 1) is 2 + an amount of miliseconds determined by your frame delay level (which is necessarily less than 16ms) = 2.? frames (less than 3 is you measure in miliseconds)
Those are the three states, from which you should get these results, if you get anything different, like 1 frame or more than what's expected with each state, then you have something wrong somewhere.
EDIT: the way you write (X frame delay ON) I think you're confusing this with retroarch's feature whateveritscallediforgot, but frame delay is not the same at all, again you cannot use it if you turn sync off, it simply won't work. whatever you get from what you seem to be doing currently with groovymame is undocumented.

PS: another thing; I don't understand the category below with shmupmame, it doesn't benefit from CRT emudriver at all, (crt emudriver works with modelines installed from VMmaker or similar method on a targeted gpu+monitor, and usually requires an emulator with proper internal syncrefresh to make use of that, which is the main feature of GroovyMAME) and generally the purpose is to run the games at their original refresh, the effect on lag is not directly related. So it's bizarre.