Thanks for testing this, seriously, it's been long since I wanted to know about some real measurement of the flip queue size issue, rather than the typical "I feel it lags" crap.
> 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.
Yes, unfortunately. I even tested creating a DirectDraw dummy device to invoke waitvsync from it while rendering with Direct3D, and it worked, but showed exactly the same static tearing. Considering the DirectDraw waitvsync method works great when combined with blitting or flippling from DirectDraw too, this means that the problem is *inside* the Present method, it just reacts too slow even with the D3D_INTERVAL_IMMEDIATE flag set, so the vblank is missed.
It's just too bad that as soon as D3D_INTERVAL_ONE is activated, an unwanted flip queue seems to be created by ATI drivers. Unfortunately this, again, tips the scales in favour of the -deprecated- DirectDraw interface.
> 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?
Well, this is certainly possible. I admit it's an unexpected result, as it's a well known fact that modern visual features like Aero make windowed mode based emulators laggy, and you have to move to exclusive mode to avoid it. But this wouldn't apply to XP. What I wonder is if you're getting a good quality vsync while in windowed mode. Anyway, what you're suggesting should be possible, but you'd be limited to the desktop resolution, so in order to switch resolutions (to run games on their native video modes) you'd need to use ChangeDisplaySettings instead of relying on DirectX mode switching and exclusive mode, which would be rather messy.
|
Index 
Flat 
Re: Flip Queue Size
Reply
Re: Flip Queue Size
