VBL sync & OpenGL

[stormbringer]

Hi guys..

I have an issue with VBL sync on some graphic boards. I use the following code to set it:

typedef BOOL (APIENTRY *PFNWGLSWAPINTERVALFARPROC)( int );

PFNWGLSWAPINTERVALEXTPROC wglSwapIntervalEXT = NULL;

void setVSync(int interval)
{
   
   if (!wglSwapIntervalEXT)
   {
      wglSwapIntervalEXT = (PFNWGLSWAPINTERVALFARPROC)wglGetProcAddress( "wglSwapIntervalEXT" );
   }

   if( wglSwapIntervalEXT )
   {
      wglSwapIntervalEXT(interval);
   }
   else
   {
      MessageBox(NULL,"Can't Set Vertical Blanking.","ERROR",MB_OK|MB_ICONEXCLAMATION);
   }
}

To set the sync on, I use setVSync(1), to set it off setVSync(0)


This does not seem to work on some ATI boards. Nvidia is fine.

Any idea?

Thanks

[va!n]

possible an driver issue? the ATI cards where it seems not to work, have you tried here to install latest official AT drivers?

[Rbz]

Hi stormbringer   

You can check if this ogl extension exist using this code:

Code: [Select]

if (strstr((const char *)glGetString(GL_EXTENSIONS), "WGL_EXT_swap_control"))
I had the same problem sometime ago, some gfx drivers don't let you change vsync in window mode but in most of the time it works fine on fullscreen.

Btw, you will need to code a good "delta timer" function to make sure your app will run at same speed on all pc configurations.

[stormbringer]

well, thanks guys, I did all that... and the extension seems to be supported, but I do not have access to ATI cards (I only have NVidia)

Driver's configuration may be an issue as in some drivers you can override the VBL settings..

delta timing should not be a problem to code with high precision timers, but again this is quite CPU dependent and not reliable on any configuration...

Normally the VSync should lead synchronized display..

I'll investigate some more and have a more robust code that would deal with different configurations..

Thanks to all

[Rbz]

Just keep in mind that there are many screen monitor refresh frequencies (60hz,120hz,85hz etc) if you don't have a delta timer you will have troubles even if you can set Vsync.

[Jim]

Just check your ATI users don't have the VSYNC turned off in their driver options.  Lots of games players do this, but it screws up well written programs.

Jim

[Shockwave]

It's a real pain in the ass coding for those people who disable vsync on thier cards. I have never understood why people do it.
A delta timer can really mess up the way that your smooth scroller looks, but as Rbraz says, your program should have this fall back if it needs it.

[taj]

It's a real pain in the ass coding for those people who disable vsync on thier cards. I have never understood why people do it.
A delta timer can really mess up the way that your smooth scroller looks, but as Rbraz says, your program should have this fall back if it needs it.

I believe its because in double buffered mode, turning off vsync means your rendering thread never stalls so you get higher fps at the cost of "tearing" across the screen - acceptable to many people.

You know how obsessed some people get with fps.

[stormbringer]

I guess there is nothing you can really do when people turn off the VSync at the driver level. Drivers overwrite the settings you may set in you app and then you only depend on the specific user settings.

The delta timer is not a great solution either becuase there is very little guarantee (even with high precision timers). If you want things to be on sync with the VBL, then the VBL should lead the dance....

[Shockwave]

You said it better than I could Stormbringer.

[Stonemonkey]

I don't have any preference really, I tend not to write anything to depend an vsync. It varies from pc to pc anyway so there's no point in relying on it for timing and anyone with it switched off can't care too much about tearing.

[Shockwave]

It's just about impossible to write an oldschool pixel scroller for a machine with vsync turned off though. Some things simply must be vsync dependent or some glitches do happen that spoil the experience. It doesn't apply to 3D accelerated stuff but it totally ruins oldschool coded intros.

[stormbringer]

AAAAARRRRGGGHHHH! bloody ADSL connection died while posting the message! here we go again...

Shockwave is totaly right!

Nevertheless, it has nothing to do with old-school coding at all. It is related to the type of visual content.

Try this: turn on you TV and switch to CNN for instance. Look at the bottom of the screen: they have a scroll text with the latest headlines. This scroll is in sync with the VBL of the video signal. Why? simply because if it's not, it would look weird, be unreadable and give strong headaches to viewers.

The reason is that the display technique has to be in harmony of the eye-brain perception mechanisms, otherwise the experience is very bad.

For 3D scenes, it's different because the eye/brain interpred the visuals differently and the VBL sync is not so important. But for 2D tranlational motion (scrolling, 2d starfield, etc), it has to be in sync with the VBL

Best

Stormbringer

[Stonemonkey]

I think it can be dealt with, maybe not perfectly but still pretty smooth. Say it's run on 1 pc with a refresh of 60Hz and another with 120Hz, that's a 2* difference in the speed of the scroller which imo would be pretty bad and that's not mentioning anything with vsync off or timing with anything else/music going on too. Oldschool demos were written to be run on machines with the same spec meaning everything always ran at the same speed regardless of who ran it and afaic that should still be the case.

[Shockwave]

I think it can be dealt with, maybe not perfectly but still pretty smooth.

The perfect solution is for people running the demo to enable Vsync to be controlled by the application. The coder can then set the sync rate in his app. 

It's a fair point you make Stonemonkey, but oldschool intros don't work well if they are delta timed.. The odd glitch spoils the experience.

[Stonemonkey]

The perfect solution is for people running the demo to enable Vsync to be controlled by the application. The coder can then set the sync rate in his app.

It's not always possible for the app to have control over the sync rate, for example I have a fairly old IBM LCD monitor that only displays at 60Hz and attempting to change any of the adapter settings relating to frame rate screws it up.

[Shockwave]

Well in your case then you are limited to 60fps, having non standard hardware to code for is a problem but I am sorry, I have yet to see a real oldschool demo with something like bobs and a sinescroll running perfectly with no glitches if it's delta timed.

The closest I have seen anyone get to that is Keops with his stuff and that's not pixel bashing, it's using hardware accelerated 3D with sub-pixel accuracy.

If anyone can show me delta timing working in a tinyptc environment to smoothly move lots of 2D graphics around with no glitches at all I'd be really impressed.

[Jim]

In my CDI demo remake I use GDI to do the copy to the screen, and I do it every 1/50th of a second (PAL refresh rate) no matter what the refresh of the screen for that extra genuine look

Jim
<edit>50ms -> 1/50th

[Stonemonkey]

Nice solution Jim, one very good thing about that is if you're using any feedback from the previous frame, it'll never look any different from machine to machine.

[stormbringer]

@Jim: yes if you render "manually" in memory and just use GDI tu update the screen buffer, yes it works! But high precision timers are not reliable on old computers (but again who cares )

Then if this is the solution, what's the point in having OpenGL with hardware acceleration and so-called standard extensions if they're not that standard or if the app cannot drive the VBL?

Moreover 60Hz is more than enough for old-school prods and should be enough for almost everything of that kind. 60Hz is supposed to be supported by (almost) all computers now. Working with the VBL should be the solution, but the app should be able to enable it, whatever the driver says... IMHO

Best,

Stormbringer