Hi, finally back in front of a keyboard, it looks like I've missed the party here.
It's a shame that everything is called lag (input lag, display lag), much better if we talked about response times. For me, lag is the difference between system under test and the original system response. eg if your response time is 30ms and the original game was 30ms, that is zero lag.
That's exactly it.
I'd like to quote schmerzkaufen from other thread, since it'll help me illustrate something I wanted to clarify:
Garegga has about 3 frames of natural lag iirc, but that one you can't touch, Groovy can only eliminate the additional lag that's running on top.
i.e
MAME (official) BGFX -> bgaregga 3fr + vsync 5fr = 8 frames
MAME (official) d3d -> bgaregga 3fr + vsync 3fr = 6 frames
Groovy BGFX -> bgaregga 3fr + vsync 3fr = 6 frames
Groovy d3d9ex (default) -> bgaregga 3fr + vsync 2fr = 5 frames
Groovy d3d9ex w/ frame_delay 1 -> bgaregga 3fr + vsync 1fr = 4 frames
Groovy d3d9ex w/ frame_delay 5 -> bgaregga 3fr + vsync 0.5fr = 3.5 frames
Groovy d3d9ex w/ frame_delay 9 -> bgaregga 3fr + vsync 1.6ms = 3 frames + 1.6 miliseconds (1/10th of a frame)
I think it's important to clarify, so we can properly interpret oomek's results in the future.
When schmerzkaufen says fd 9 equals to 1/10th of a frame of lag, it's true but *only* if you consider the average value. In my opinion we shouldn't use average values, or only use them with care, because it leads to confusions.
Actually, fd 9 means that for 9 out of 10 button presses (90%), the lag is zero (matches original hardware, as jimmer says).
It's only for 1 out of 10 button presses (10%), that the lag is 1 frame, since the button press is not catched on time.
If you average the result, then it's when you get that 1/10th of a frame of lag, but that would lead to thinking that there's some lag associated to each button press while this is absolutely false. I.e. even for fd 7, most of the interaction matches the experience with original hardware.
And even so, this would be in a worst case scenario, where the pcb would poll the switches during vblank. On the other hand, if the pcb would read input let's say in the middle of the frame, then fd 5 would be enough to match the pcb responsiveness, this means zero lag.
Unfortunately we don't know where each pcb polled input, so assuming the worst case scenario is the best we can do. We'd need to test GM against a real pcb to know the actual lag (lag, again, by jimmer's sense), but it should be equal or less than the one considered by using this method.
In the same way, the value that oomek provides, e.g. 4.08 ms for fd 9, is telling us the latest button press that GM can catch.