next »

[mcc]

So, I have been doing stuff with SDL+OpenGL, and a persistent problem I have is that when I test my own stuff I tend to see vertical tearing.

The last time I tried to google information on this, I saw a variety of sort of superstitious-sounding recommendations, including:

1. Call SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
2. Call SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 1);
3. Call glFlush(); and/or glFinish(); before and/or after SDL_GL_SwapBuffers().
4. You have to enable something called "triple-buffering"; it is impossible to do this via OpenGL

However when I temporarily tried doing 1-3 none of these suggestions made any visible difference...

At the time, I assumed all this was because I was developing on a really ancient machine (a PPC mac with a GeForce 3) and maybe my card didn't have the neat new features (like triple-buffering?) needed to address vsync issues. However recently I have switched to using a Mac Mini, which... has [GMA 950] integrated graphics but is at least modern? And when I do something simple like flicker the screen between two colors I still see crazy vertical tearing.

Is there absolutely anything I can do to stop the tearing?

Or is it possible there is no problem with my code to begin with, and I'm only seeing tearing because I'm using integrated graphics and/or an old CRT monitor w/ VGA adapter?-- That is, if I was using a "real" graphics card and/or native-DVI monitor would the tearing just go away?

I am in the dark here. :O

[Guillaume]

Could you send a demo app which presents vertical tearing to you so we can try it on our all mighty graphics cards and see if it's a problem with your hardware or your code?

[mcc]

That's, um, a really good idea. One minute.

[mcc]

So here is a simple app that uses my drawing code, but all it does is fill the screen with a different color every frame:

Macintosh version (intel-only)
Windows version

If there is any tearing it will be very blatant...

...Now that I've made that, testing on my wife's windows machines, I get no apparent tearing on her desktop (which is a very old Dell with a real, but old video card, and a dvi<->vga converter) and super crazy tearing on her laptop (which is a newer Dell with Intel integrated graphics). Hm, I am beginning to sense a pattern here...

[bateleur]

Tried the Windows version on my dev machine, which is a 2.5GHz Dual Core Pentium with 4GB RAM and an ATI Radeon HD 3400 graphics card.

The result, apart from being flickery as expected, was a number of horizontal bands which looked somewhat like the bastard offspring of a glowstick and a pair of 80s legwarmers. 

[Guillaume]

On my work station, [email protected], 512Mb RAM and a nVidia Geforce 4 MX 4000:

Massive eye damage, but no tearing or anything.

[Guillaume]

On the other hand, on my personal desktop (Core2Duo @3ghz, 4 Gb Ram, Radeon 4850 512 Mb) I definitely have massive tearing.

[mewse]

If you have turned on 'doublebuffer' and 'swap control', then you've really done all you can do.

Assuming that those two options are turned on, the tearing should only appear if the computer's 3D driver has been set to disable VSync, and thus ignores your game's request to wait for VSync before swapping the front and back screen buffers. 

(Lots of hardcore PC gamers set their 3D cards to always disable VSync, because they'd rather have tearing than the lower frame rate associated with waiting for the next VSync before displaying the frame which was just drawn)

[Guillaume]

Possibly stupid question incoming: would the type (LCD or CRT) and quality of screen matter in whether tearing appears or not?

[Hima]

It works fine on my laptop. My graphic card is NVIDIA GeForce 8400 GS  :O

[mirosurabu]

Works fine on my laptop (integrated graphics ATI x1200 or something).

I had tearing problems with OGL in the past, but it was because I didn't turn on the VSync.

[mcc]

So actually I do not enable doublebuffer or swap_control in the flickery-colors program I uploaded above.

Is this correct?:

1. Enabling SDL_GL_DOUBLEBUFFER and SDL_GL_SWAP_CONTROL will enable vsync.

2. However, it will not work on some machines, either because the user has disabled vsync or because the card does not support it.

...If this is the case I guess I should be enabling SWAP_CONTROL even if it does not do anything on my machine?

Does SDL document somewhere what the default values for the SDL_GL_SetAttribute attributes are? It does not seem to indicate either way in the manpage.

(Thanks all for the testing help.)

[Reiss]

Also, SDL_GL_SWAP_CONTROL is buggy on macs.

Unfortunately, your only recourse for getting vsync to work on macs is to do this:

Code:

#ifdef __APPLE__
	long swapInterval = 1;
	CGLSetParameter(CGLGetCurrentContext(), kCGLCPSwapInterval, &swapInterval);
#endif

[Hima]

Possibly stupid question incoming: would the type (LCD or CRT) and quality of screen matter in whether tearing appears or not?

I've heard that the type doesn't matter. But I don't know about the screen quality though.

[mcc]

XUE-- Thank you so much! That explains a lot, and it completely solved my problems on the macintosh.

I will test on the win laptop with SWAP_CONTROL and see if it fixes anything.

Hima: I am 99% certain I have seen tearing occur as the result of cheap VGA<->DVI converters. But that isn't a fault of the monitor really.

[Reiss]

No problem, I remember spending hours trying to figure out why I had so much tearing on my mac a while back, very frustrating.  Glad it helped.   

[mcc]

So... I played with this a bit more.

Something I hadn't realized was that kCGLCPSwapInterval and [if I'm reading the docs right, SDL_GL_SWAP_CONTROL] perform their syncing by delaying until the screen is ready to refresh.

However this creates a new problem-- it slows things down! If the refresh rate is less than the framerate I'm using to calculate motion, things move in slow-mo. So what I wonder is:

1. Is there an equivalent of SDL_GL_SWAP_CONTROL / kCGLCPSwapInterval which works by dropping frames when frames are generated faster than the screen refreshes, rather than pausing until the screen refresh is ready?

2. I almost kind of wonder... is there any way to just find out what the screen refresh rate is, so maybe I can just generate frames slower than the refresh rate to begin with? I'm currently using a physics engine that performs best when given a non-varying time step, which makes it tricky to do any kind of dynamic framerate thing, but if I know the refresh rate to start with maybe I can just peg my frame rate to that? (This is probably a better way to do it but sounds harder and highly nonportable...)

[Reiss]

If you're comfortable with multithreading, you could try sticking all of your rendering code on a separate thread.  That way, even if the renderer gets blocked, the rest of your game still runs normally.

You'd have to stick -all- of your OpenGL code on that one other thread though, since OpenGL itself isn't threadsafe.

That said, you probably want to avoid framerate-dependent motion...  And it might be easier to avoid that than to wrangle code that was originally not threadsafe into being threadsafe.

[Saint]

That said, you probably want to avoid framerate-dependent motion...  And it might be easier to avoid that than to wrangle code that was originally not threadsafe into being threadsafe.

This.

The typical solution to doing fixed-framerate simulation in a dynamic framerate setting is to collect the time spent into a cache and just run fixed-timestep simulation steps as there is enough time, like so;

For each frame in the physics simulation (where TTotal is global and initialized to 0.0 at startup);
1. Get the time taken since last frame, TF, and add it to TTotal
2. Get the wanted time for a single frame of physics simulation, TP
3. if TTotal < TP, leave this and do something else
4. TTotal -= TP
5. Do a single frame of physics simulation (TP time)
6. Goto 3

... You'll get a slight offset but it shouldn't be noticeable if your timestep is small enough.