Well, vsync can only be activated in the driver’s settings, right?
By looking at the spec of WGL_swap_control, I thought that this extension could be used to force vsync programmatically even when it’s not activated in the driver.
So I tried it in an application and got something strange:
I tested my app on a Riva TNT with the detonator 3 drivers (r6.31). My app only displays a textured quad with two different textures (one for odd frames, one for even frames).
When vsync is activated in the driver’s settings, WGL_swap_control works fine (I can use whatever value I want for the interval). However, when I don’t specify a swap interval (or set it to 0), The display flickers as if it wasn’t synchronised with the refresh. I thought that with vsync enabled I would have got the same result with a swap interval of 1 and without specifying any interval … but no .
Another problem occurs when I disable vsync in the driver’s settings: in this case when I try to set a swap interval, the program simply crashes #2!
0 means no vsync at all, 1 means wait for the next vsync (max framerate = refresh rate). 2 would mean wait for 2 vsyncs (max framerate = refresh rate/2).
Originally posted by mcraighead: 0 means no vsync at all, 1 means wait for the next vsync (max framerate = refresh rate). 2 would mean wait for 2 vsyncs (max framerate = refresh rate/2).
Alright !
But it seems that when I enable Vsync in the driver’s settings, buffer swaps are not synchronised with the refresh if I don’t use the extension.
Then, when I specify a swap interval of 1, I notice a difference on the screen, it stops flickering and the two images are blended together (looks like it is synchronised now!).
And, the major problem is that if I disable Vsync in the driver’s setting, the application crashes whenever I use the extension (if I call wglSwapIntervalEXT).
Im not sure about the crashing when VSynch is disabled, that sounds like a driver bug but I dont really know. Are you making sure the pointer you get from glGetProcAddr (or whatever the function is called, somehow it has slipped from my mind…) is not NULL? Perhaps the driver returns null when vsynch is disabled. An application should always verify the proc address it gets back.
However, what you need to understand is that the driver setting doesnt FORCE an app to use vsynch, rather it PREVENTS an app from using vsynch. When vsynch is enabled in the driver, an app can use vsynch if it wants to. But with vsynch disabled in the driver, an app can never use vsynch.
It would be nice if the driver actually had 3 settings:
force vsynch
allow vsynch
disable vsynch
Originally posted by mcraighead:
[b]There are three settings. They are force disable vsync, no vsync by default, and vsync by default.
Matt[/b]
Uhhh, hmmmm…OK??? Dont know what I was thinking. You are right. When were those added. Admittedly, I dont play around with those settings much. Last time I tried them was sometime around the release of the original detonator (maybe even earlier), and I dont remember seeing all 3 settings then.
On the bright side, that has to be about the easiest feature request for you to accommodate.
Thinking about this though, If an app tries to explicitly disable vsynch, there is no way to force it into vsynch, is there?
[This message has been edited by LordKronos (edited 02-21-2001).]
Originally posted by mcraighead:
[b]There are three settings. They are force disable vsync, no vsync by default, and vsync by default.
Matt[/b]
OK,
I would therefore imagine that vsync by default means that vsync is enabled (In my case it doesn’t seem to be so) and can be disabled by wgSwapIntervalEXT(0);
And that no vsync by default means that vsync can be enabled by wglSwapIntervalEXT(1);
Is that right?
By the way, I didn’t use the force disable vsync setting.
LordKronos, yes, I check the value of the function pointer before using it. I get a valid pointer, use it and it crashes.
Anyway, I’m gonna try my program on another PC with a TNT2 and other drivers and see what it does … hope it won’t crash this time .
.