You may want to have a look at the multithreading implementation in GroovyMAME (only for the Windows OSD, I don't fully understand how baseline manages worker threads from the SDL side).
With GroovyMAME implementation, -triplebuffer enables background v-sync (e.g. run 55 Hz game on 60 Hz monitor at 100% with no tearing), while -syncrefresh forces the main and blitting threads to wait for each other.
Obviously the -triplebuffer idea (asynchronous blitting) requires being able to drop frames, which D3D9 doesn't allow natively (apparently D3D9ex does with the D3DPRESENT_FORCEIMMEDIATE flag). What we are doing is, in the window_update function, try to get the lock instead of acquiring it, and if it fails just exit without drawing. The rendering is done in a third thread separated from the window thread and the main thread. It's cumbersome but it's the only way I found to achieve this with D3D.
As it's currently implemented in baseline, you do the draw operations from the window thread, which is detached from the main thread. This is a bad idea, because the window thread also processes input, and if you v-sync you stall the thread so input gets seriously affected. It's even worse if the emulation and the screen are refreshing at different rates, because you may get weird no-input interference patterns, as it's probably the issue reported by OP.
Unfortunately the weakness of GM's implementation is that D3D still forces you to create the device from the window proc thread so the synchronization with the blitting thread is prone to dead-locks if you're not very careful. Besides you can't use this method with multiple windows.
|
Index 
Flat 
Re: MAME input "flickering"
Reply
