And here's the patch!
Thanks!
I think I have it. D3D with Frame Delay 0 in sfiii3 with regular GroovyMAME typically gives me input results on the 5th or 6th frame. With Koopah's changes, I get consistent results on the 3rd frame, which is basically what I get with ddraw and frame_delay 0. So, I think I got at least part of these changes right. Also, I can now use frame_delay 8 in sfiii3 with only 1 overrun in 30 minutes with the same settings that produced over 100 before.
However, frame_delay seems to have no effect now. I get 3rd frame results with frame_delay 8 where I got 1st and 2nd frame results without these changes. I hope I've done something wrong. I think this is far as I can go for now. I'll leave it to the pros from here. I'll share what I've done in case it's helpful in any way, along with the resulting binary.
Thanks vicosku for your work, it's promising that at least d3d with frame_delay disabled works better than regular groovymame with framedelay disabled.
Too bad the framedelay now does not seem to work at all. This would also explain the sudden very low number of overruns on sfiii while using fd 8, i.e. it's actually not invoking framedelay thus being equivalent to fd 0 for sound stability.
Hopefully Calamity will find some time to run through the code and see what possibly may be wrong.
I decided to test with direct draw again. I can run for 30 minutes with zero issues with an ASIO latency of 96 and the following settings in sfiii3:
-video ddraw -asio_holdoff 1152 -frame_delay 1
I also checked the input lag. I counted the first 20 samples in the video, and every single one reflected input on the 2nd frame after it was entered. I still can't produce any evidence that it's possible to get next-frame response with ddraw in Windows 7. However, I think these are the settings I will stick with this game, and most others. Perhaps consistent 2nd-frame response is preferable to getting next-frame response 50% of the time anyway.
Also, with CPS2 games, I can run with the same settings and asio_holdoff 832 for 30 minutes and only get 16 underruns. Very nice. It will be interesting to see how d3d compares with the change that was mentioned. sfa3 was actually the game that prompted me to reduce all the way to fd 1, because severe audio issues occurred with higher values when asio_holdoff was set to 832. Since I get consistent 2nd frame response with FD 1 in both CPS2 and CPS3 games and can't get next-frame ddraw response even at fd9, using a higher setting than 1 seems pointless. Of course, this contrasts with what we've seen with d3d so far, where it seems that using as high of an fd value as possible before issues occur is ideal.
Thanks again for all the testing you've been doing. I'm intrigued by your findings (also posted about previously) that ddraw never seems to provide next frame response, even when using high values for framedelay. For some reason it seems that with ddraw another video buffer is created, or that it somehow blocks the input polling longer than d3d.
Would you be willing to do another test for ddraw (using regular groovymame), involving the radeonpro tool (
http://www.radeonpro.info/download/)? Basicly I would like to force the flipqueuesize to 1 while using ddraw with regular groovymame and fd 7 to 9.
There is however a little trick involved, as the radeon pro tool cannot take hold of a program running in administrator mode (such as groovymame for win 7).
The trick is to use a "dummy" executable that is started before groovymame, and triggers the radeon pro profile. For example you could use
Soft15Khz as it just sits in the windows tray doing nothing. But if you add it to radeon pro it will trigger the radeon pro profile when started.
Could you test it this way, adding soft15khz to a radeonpro profile, and in this profile change flipqueuesize to 1 (found in the
Advanced Tab), and disabling Aero (found in the
Tweaks Tab).
It's important that you also disable aero, as it will give a visual clue that Radeonpro is actually activating the profile when you start the dummy executable (soft15khz in this example). If you're going to do this test, please make double sure it's triggering the profile correctly, as radeon pro itself will give no clue that it's activated. If you include the disabling of Aero, you'll see Windows switching from Aero to non-Aero desktop as soon as the dummy executable is started.
Once you're sure that the dummy executable is triggering the radeonpro profile correctly you can then start regular groovymame with ddraw and a high framedelay value. I'm very curious whether forcing the FlipQueueSize of 1 will cause next frame responses to occur in your test for ddraw. It's a wild guess, but sometimes trying those may be worthwhile...
Of course when you're sure that manually everything is working as it should, you could create a little batch file to simplify things, for example (use your own paths):
Start Q:\Emulators\Soft15Khz\Quickres.exe
Timeout /T 1
start /min /wait mame.exe
taskkill /IM Quickres.exe