Tearring graphics

SDL Development
1

Just a simple question: how do you (anybody who cares to respond) avoid
tearring graphics? Is it as simple as passing SDL_DOUBLEBUF to
SDL_SetVideoMode() or is there more to it? The game I’m working on
doesn’t have any protection against tearring so generally on quick loops
you can get screenshots of half the screen drawn with a new frame and
the old frame still taking up 300 rows down. Any suggestions?–
Chris Thielen <@Christopher_Thielen>

2

Screenshots…? I assume you’re using som external tool for that,
since SDL isn’t thread safe.

Anyway, there’s only one way to prevent this: Retrace sync’ed page
flipping. If the rendering target doesn’t support it, there isn’t
much SDL can do about it.

Note that there are two commonly used methods of “flipping”; actual
h/w pageflipping (multiple buffers; a flip is just changing one or
two h/w registers), and fake flipping through blitting (a "flip"
means you blit the off-screen back buffer into the display buffer.)

If you use SDL_DOUBLEBUF, the underlying rendering backend has a
chance of doing the right thing (real page flipping), but there’s
no guarantee. Either SDL or the driver might still use back->front
blits, and may not even be able to sync them with the retrace. (Which
wouldn’t help much anyway, unless you’re on a real time OS. To do
blit based flipping without tearing, you have to hit the retrace
right on, or you’ll get tearing anyway.)

Also note that virtually no desktop environments are double buffered,
so forget about SDL_DOUBLEBUF in windowed mode. Use SDL_FULLSCREEN,
or you’ll almost certainly enforce fake blit based flipping, and you
may also lose the retrace sync.

Finally, note that it’s on some platforms (Linux; maybe some others),
only a few drivers can retrace sync at all. You’re basically out of
luck on these. Best bet is to use OpenGL in fullscreen mode, as
that’s much more likely to support both h/w pageflipping and retrace
sync, at least in my experience.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -’
— http://olofson.net — http://www.reologica.se —On Wednesday 29 January 2003 05.44, Chris Thielen wrote:

Just a simple question: how do you (anybody who cares to respond)
avoid tearring graphics? Is it as simple as passing SDL_DOUBLEBUF
to SDL_SetVideoMode() or is there more to it? The game I’m working
on doesn’t have any protection against tearring so generally on
quick loops you can get screenshots of half the screen drawn with a
new frame and the old frame still taking up 300 rows down. Any
suggestions?

3

Oh, almost forgot: There is one trick that can greatly reduce
tearing, when you can’t have retrace sync’ed flips: Sub-pixel
accurate rendering.

This more or less requires OpenGL, at least if you want to do
full-screen scrolling, and probably does anyway, as you need frame
rates several times higher than the display refresh rate for this
trick to work well.

What happens is basically that by redrawing the screen over and over,
several times per CRT refresh, using sub-pixel accurate rendering,
each displayed image become slightly “skewed”, rather than torn. The
higher the rendering frame rate, the smaller the difference between
each rendered frame - and thus, if the frame rate is high enough, you
won’t see the tearing, although it’s still there, theoretically.

This is part of the reason why tearing isn’t as obvious in 3D games as
it is in 2D games.

Check out “smoothscroll-1.1” at http://olofson.net/mixed.html for a
basic example of sub-pixel accurate rendering with OpenGL. It also
runs in SDL software mode, so you can see the difference. It’s really
intended to demonstrate ultra smooth scrolling without designing for
specific refresh rates (which you can’t do these days unless you’re
into consoles or arcade machines), but also demonstrates that the
same method gives you tearing reduction on non-sync’ed displays as an
extra bonus.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -’
— http://olofson.net — http://www.reologica.se —On Wednesday 29 January 2003 05.44, Chris Thielen wrote:

Just a simple question: how do you (anybody who cares to respond)
avoid tearring graphics? Is it as simple as passing SDL_DOUBLEBUF
to SDL_SetVideoMode() or is there more to it? The game I’m working
on doesn’t have any protection against tearring so generally on
quick loops you can get screenshots of half the screen drawn with a
new frame and the old frame still taking up 300 rows down. Any
suggestions?

4

another idea would be something like when you hold down a button, your game
enters some kinda “pause” mode where it doesnt update anything that would
cause the graphics to change, allowing you to take a screen shot because
even if tearing happens, you cant see it since its just the same frame over
and over. Pressing the button again would take it out of pause mode.> ----- Original Message -----

From: david@olofson.net (David Olofson)
To:
Sent: Wednesday, January 29, 2003 8:26 AM
Subject: Re: [SDL] tearring graphics

On Wednesday 29 January 2003 05.44, Chris Thielen wrote:

Just a simple question: how do you (anybody who cares to respond)
avoid tearring graphics? Is it as simple as passing SDL_DOUBLEBUF
to SDL_SetVideoMode() or is there more to it? The game I’m working
on doesn’t have any protection against tearring so generally on
quick loops you can get screenshots of half the screen drawn with a
new frame and the old frame still taking up 300 rows down. Any
suggestions?

Oh, almost forgot: There is one trick that can greatly reduce
tearing, when you can’t have retrace sync’ed flips: Sub-pixel
accurate rendering.

This more or less requires OpenGL, at least if you want to do
full-screen scrolling, and probably does anyway, as you need frame
rates several times higher than the display refresh rate for this
trick to work well.

What happens is basically that by redrawing the screen over and over,
several times per CRT refresh, using sub-pixel accurate rendering,
each displayed image become slightly “skewed”, rather than torn. The
higher the rendering frame rate, the smaller the difference between
each rendered frame - and thus, if the frame rate is high enough, you
won’t see the tearing, although it’s still there, theoretically.

This is part of the reason why tearing isn’t as obvious in 3D games as
it is in 2D games.

Check out “smoothscroll-1.1” at http://olofson.net/mixed.html for a
basic example of sub-pixel accurate rendering with OpenGL. It also
runs in SDL software mode, so you can see the difference. It’s really
intended to demonstrate ultra smooth scrolling without designing for
specific refresh rates (which you can’t do these days unless you’re
into consoles or arcade machines), but also demonstrates that the
same method gives you tearing reduction on non-sync’ed displays as an
extra bonus.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -’
— http://olofson.net — http://www.reologica.se —

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

5

Or, if the problem is really the screenshots, just implement a
screenshot feature in the game. As long as you don’t deliberately
break SDL’s “single thread for graphics” requirement, it will Just
Work™, since you can’t preempt rendering if the screenshot code is
in the same thread.

This obviously does nothing to reduce visible tearing when you’re
playing, of course.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -’
— http://olofson.net — http://www.reologica.se —On Wednesday 29 January 2003 19.19, Atrix Wolfe wrote:

another idea would be something like when you hold down a button,
your game enters some kinda “pause” mode where it doesnt update
anything that would cause the graphics to change, allowing you to
take a screen shot because even if tearing happens, you cant see it
since its just the same frame over and over. Pressing the button
again would take it out of pause mode.

6

Yeah, I’m not having any issue with the game taking screenshots. An
external screenshot application is just the best way to notice the
tearring.On Wed, 2003-01-29 at 11:00, David Olofson wrote:

Or, if the problem is really the screenshots, just implement a
screenshot feature in the game. As long as you don’t deliberately
break SDL’s “single thread for graphics” requirement, it will Just
Work™, since you can’t preempt rendering if the screenshot code is
in the same thread.

–
Chris Thielen <@Christopher_Thielen>