So yesterday I run some tests to see how GroovyMAME performs as compared to the results on the real hardware, here:
http://forums.shoryuken.com/discussion/178437/official-shmupmame-super-turbo-thread/p1First of all, by watching the videos done by papasi, I notice he is counting one frame less than I count (I'm referring to his videos). He says that SSFII Turbo, when played on the supergun, lags 4 frames natively, then I count them on his video and I get 5 frames. I'm guessing it must be due to the counting method: I start to count when the red led turns off, that frame is #1, then 2, 3, 4, and on #5 the character starts moving. Please correct me if you think I'm wrong.
The number of frames on my test videos has been counted following this rule, using Media Player Classic, CTRL+Right to advance frame by frame.
One difference is that I'm recording at 120 fps while papasi recorded his videos at 60 fps. So to get the number of frames on my videos you need to divide by too. I take 5 values and get the average.
The other difference is that the led in papasi's system is directly wired to the button, so in theory it's lag-less, but in my tests I'm using the keyboard leds, mapping the button to the caps-lock key in MAME (as suggested by DaRayu in MAME World). The problem with my setup is that, according to the old-school knowledge, it's the bios the one that turns these leds on/off, so the keypress signal must travel from the keyboard to the computer, be processed by the bios, then travel back to the keyboard where the led is finally lit. Obviously, this involves time, and judging by the slow motion video I took it takes at least 1 full frame of extra lag (5 frames at 240 fps). This means the led turns on/off one frame late, so you need to add 1 frame to the results from my videos.
So, due to this, my setup is suboptimal for this kind of tests. I really need to figure out how to wire a led to the buttons without short-circuiting my jpac, then I'll be able to get more accurate results.
The system that I used:
Pentium 4 3.0 GHz
Windows XP-64
ATI HD 4350
Catalyst 9.3 (CRT Emudriver)
Here are the videos:
http://www.2shared.com/file/jVoGNfgz/d3d_120fps.htmlhttp://www.2shared.com/file/bgDinjGs/ddraw_120fps.htmlhttp://www.2shared.com/video/FdRDSCvk/keyboard_led_lag_240fps.htmlAnd here are the results and how it would compare to the real hardware:
d3d_novsync: 9, 6, 9, 7, 8 -> 7.8 -> 3.9 + 1(led-lag) = 4.9 ≈ 5 (no lag)
d3d_vsync: 16, 16, 15, 17, 17 -> 16.2 -> 8.1 + 1(led-lag) = 9.1 ≈ 9 (4 frames of lag)
d3d_framedelay: 10, 11, 10, 9, 10 -> 10 -> 5.0 + 1(led-lag) = 6.0 ≈ 6 (1 frame of lag)
ddraw_novsync: 8, 9, 9, 5, 8 -> 7.8 -> 3.9 + 1(led-lag) = 4.9 ≈ 5 (no lag)
ddraw_vsync: 11, 10, 12, 9, 8 -> 10 -> 5.0 + 1(led-lag) = 6.0 ≈ 6 (1 frame of lag)
ddraw_framedelay: 11, 9, 9, 10, 10 -> 4.9 + 1(led-lag) = 5.9 ≈ 6 (1 frame of lag)
The huge lag of d3d_vsync (4 frames) confirms DaRayu results and what we've been discussing here about the flip queue. This will need to be tested in W7 too, with newer versions of the drivers. So the only reasonable way of using d3d is by enabling the -frame_delay option: it removes 3 frames of lag, although, ironically, not because of the reason it was conceived for.
So, if these tests are right, we would have 1 frame of lag (as compared to the real hardware) for the properly working vsync cases (d3d_framedelay, ddraw_vsync, ddraw_framedelay). The frame_delay option doesn't seem to be making any fundamental difference here, although probably more accurate tests will be required to confirm this.
I believe the non-vsynced modes just show less lag because the changes are shown immediately without waiting for a full frame to be displayed. This is a little difficult to judge because the videos are not vsynced with the screen, so you get tearing either way.