Software Support > GroovyMAME
The input lag issue in the context of emulation [about new -frame_delay option]
Dr.Venom:
--- Quote from: Calamity on November 26, 2012, 07:11:33 pm ---Yes that's it. By asynchronous I mean that it can drop frames if required (i.e. the game loop can run as fast as it wants without caring about the video card's duties). This can be achieved either by triple buffering (the real one, not the DirectX crap) or by moving the double buffering code into a separate thread (this is what GM does).
--- End quote ---
Thanks for explaining.
--- Quote ---Well, there's some interesting stuff I found when testing this -frame_delay method. At first I was using the D3D's default method built in MAME: flip + D3DPRESENT_INTERVAL_ONE, for v-syncing. This method seems the most efficient for catching the vblank period. However there's something odd to it.
[...]
I was about to trash the whole thing but then tried by using the GetRasterStatus method within a loop and right after that performing the flip operation with the D3DPRESENT_INTERVAL_IMMEDIATE flag. Surprinsingly this worked like a charm, but only for CRT monitors!!!
--- End quote ---
I'm *really* happy that you didn't thrash the whole thing, as the final implementation is working so well! Also great to see that you could make use of the GetRasterStatus method, and get such a rock solid implementation and performance.
I did some more extensive testing on the frame_delay and for some systems I can reliably run it at a setting of 8, making a *noticable* improvement versus the default! On very close comparison, running MSX2 emulation (which reliably takes a frame_delay of 8 on my system) side by side a real machine, and switching between the two, makes the input response hardly distinguishable from the real thing anymore. It really feels like the holy grail for (frame based) emulation :)
--- Quote ---For some reason when testing this on LCD monitors the GetRasterStatus seems too slow reporting the VBLANK and you can clearly see static tearing usually on the upper part of the screen. I believe it's always equally slow, it's only that CRT monitors tend to have a longer blanking period so this issue gets masked. But the nice thing is that even if delayed, it flags at exact intervals like a swiss clock, as opposite to the v-synced flipping method.
--- End quote ---
LCD's apparently don't need a real blanking anymore (which is understandable from a hardware perspective), but I once read that it got implemented for compatibility reasons. In any case, if it's a sort of artificial value on LCD, then it might be of influence on how long the "blanking" takes for different manufacturers LCD panels. Purely guessing though..
What you could possibly try is to check for the scanline number during active display (which I understand the GetRasterStatus should return when not in vblank) and if that's also as stable as the swiss clock, you could time the flip a few lines before "reported" vblank. That could possibly mask the issue for LCD while possibly also having the flip still in vblank for CRT. On the other hand, since GroovyMAME is meant for CRT, I guess you wouldn't want to fiddle too much with the current implementation..
--- Quote ---
--- Quote ---While doing some first tests with the new frame_delay feature, I also found something interesting that fixes the issue with the <240 line modes running way too fast on my setup (win7+soft15khz), as we spoke about some time ago (see: http://forum.arcadecontrols.com/index.php/topic,120331.msg1313434.html#msg1313434). That speed issue for those specific screenmodes is completely fixed now when I set the frame_delay parameter to 1 (or higher)!
--- End quote ---
My understanding of this is that the DirectDraw's WaitForVerticalBlank method works somewhat differently under Windows 7, so maybe if the emulation is too fast you might end up having a new frame ready *before* the previous vblank actually ended, thus making the new WaitForVerticalBlank call to return immediately. This should be avoided with the DDWAITVB_BLOCKBEGIN flag, but for some reason it might not be working (this could be totally wrong). So adding a delay would give enough time for the VBLANK to end and MAME to catch the next blanking period instead.
--- End quote ---
Ah yes indeed, that could certainly be it. I'm extremely happy though that it's working as good as it does now with the delay.
With regards to the settings, would you performance wise recommend activating hardware stretch when using ddraw, or leave the hwstretch disabled?
Calamity:
Hi Dr.Venom,
Thanks for testing the -frame_delay option. I'm glad to hear that it actually makes a difference. I do notice it feels very responsive but can't honestly say for sure that I feel a difference as compared to the normal GM's -syncrefresh method. But I don't have the best controls to test, my sticks are not the best ones for accurate control.
As a note, while doing tests for the refresh scaling feature, I played ddonpach by rotating my PC CRT monitor and using a 115 Hz mode for real hardware scanlines in combination with -syncrefresh and -frame_delay 5 in order to discard one out of two vblanks. Well this *really* felt like a different game, probably I was influenced by the fact of running tated but as a fact I reached to a level that I had never got before without adding new credits.
And a month ago or so, I visited a friend whose cab was set up by me before GM existed. At the time I believe I was using -triplebuffer -nothrottle to achieve smooth scrolling, combined with 200 different modes to cover the main systems. Well, I was shocked by how unplayable the games felt, as compared to what we have know. But anyway I was under the effects of alcohol so that's not of scientific value.
I think I should split this topic from the GroovyUME's thread into its own "GroovyMAME's lag discussion" so it has more visibility.
Dr.Venom:
Hi krick,
--- Quote from: krick on November 24, 2012, 08:39:32 pm ---Also, I'm not sure about keyboards, but other inputs like mice are handled in MAME using the RawInput API, which may be different than DirectInput from a lag standpoint.
--- End quote ---
Yes, the keyboard should also be using the rawinput API, as suggested by Microsoft here: msdn.microsoft.com/en-us/library/ee418864.aspx. See halfway down: "Overall, using DirectInput offers no advantages when reading data from mouse or keyboard devices, and the use of DirectInput in these scenarios is discouraged."
Interesting in the same link and paragraph is the remark "DirectInput creates a second thread to read WM_INPUT data, and using the DirectInput APIs will add more overhead than simply reading WM_INPUT directly.". Which to me says that RawInput - in theory at least- might have lower latency than DirectInput (because of the increased overhead). I stress the *in theory* at least, as usually there are more factors to take into account. That could be interesting, as RawInput can be used as an API for joysticks and other devices also. If I interpreted it correctly, MAME is using DirectInput 7 for joysticks/pads, which could then possibly be improved by changing to using the RawInput api? Questionmark though.. and from what I know it's not quite that easy to implement the RawInput api in a way that makes it robustly work with the various different joystick/joypad devices out there.
--- Quote ---Check out this info on PS/2 keyboards vs USB keyboards...
http://www.tomshardware.com/reviews/mechanical-switch-keyboard,2955-5.html
--- End quote ---
Thanks for the link, that certainly made for an interesting read.
Dr.Venom:
--- Quote from: Calamity on December 01, 2012, 07:06:16 am ---As a note, while doing tests for the refresh scaling feature, I played ddonpach by rotating my PC CRT monitor and using a 115 Hz mode for real hardware scanlines in combination with -syncrefresh and -frame_delay 5 in order to discard one out of two vblanks. Well this *really* felt like a different game, probably I was influenced by the fact of running tated but as a fact I reached to a level that I had never got before without adding new credits.
--- End quote ---
It could be a coincidence, but I also reached a level on Gradius 2 (MSX version in UME), which I never reached before on emulation...
--- Quote ---And a month ago or so, I visited a friend whose cab was set up by me before GM existed. At the time I believe I was using -triplebuffer -nothrottle to achieve smooth scrolling, combined with 200 different modes to cover the main systems. Well, I was shocked by how unplayable the games felt, as compared to what we have know.
--- End quote ---
That's the interesting part, once your frame of reference changes, you'll start to notice those things. That's why in general I always try to run it comparing directly against real hardware (which admittedly is easier to do for home consoles than Arcade hardware).
--- Quote ---But anyway I was under the effects of alcohol so that's not of scientific value.
--- End quote ---
;D
--- Quote ---I think I should split this topic from the GroovyUME's thread into its own "GroovyMAME's lag discussion" so it has more visibility.
--- End quote ---
Yes, that would be helpful.
Navigation
[0] Message Index
[*] Previous page
Go to full version