Well, the good news are: The patch actually works on my system. Again, I changed the versions back to back:
mame suprmrio -waitvsync
still just reacts after 6-7 frames as always.
mame_patch -suprmario -waitvsync
with your new source code reacts after 3 (and sometimes, but rarely, 4) frames, just like the DirectDraw vsync and the Direct3D window vsync.
The bad news: Yes, I see the tearing. It's only on top of the screen (unlike without vsync where it's all over the screen), but it's there.
What about the following idea? It's rather mundane, but it should serve its purpose:
As I said and as I tested again, in window mode, it works fine.
mame suprmrio -waitvsync -window
doesn't produce any further input lag.
So, wouldn't it be possible to use the window mode, but in the way that the window is a boderless window of the size of the screen resolution? We don't give it borders or a title bar and we put it at position 0,0 of the screen. Its width and height equal the desktop with and height.
In this case, from a technical point of view, MAME would run in window mode and would circumvent the input lag in Direct3D/vsync. But visually, it would look just like fullscreen, so you don't need to see your desktop when playing a game.
Is there any disadvantage to it? Except for the fact that triple buffering can't be used in window mode, is there anything that would be missing with such a solution?
|
Index 
Flat 
Re: Flip Queue Size
Reply
Re: Flip Queue Size
