SDL does "SemiTriple" buffering!?

I noticed that asking for SDL_SWSURFACE | SDL_DOUBLEBUF on Win32
(DirectDraw) seems to give you a double buffered h/w page flipping
screen along with a s/w shadow buffer. Seems like I get both a s/w
surface with “blit flips” and h/w flips with retrace sync.

That is, it seems like the DDraw backend already implements the
"SemiTriple" feature of Kobo Deluxe, meaning that using the
SemiTriple mode in Kobo Deluxe does nothing but add an extra s/w->s/w
blit. (Kobo Deluxe uses an internal hack to get retrace sync’ed flips
while doing the actual rendering into a s/w surface. This is to avoid
alpha blending causing reads from VRAM.)

Is this to be relied upon, or are there other h/w page flipping
targets that just give you a single buffer and a shadow surface if
you ask for double + s/w surface?

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se

Nope… It’s just SDL that pulls in SDL_HWSURFACE automatically if I
ask for SDL_DOUBLEBUF. Doh!

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Monday 06 October 2003 04.17, David Olofson wrote:

I noticed that asking for SDL_SWSURFACE | SDL_DOUBLEBUF on Win32
(DirectDraw) seems to give you a double buffered h/w page flipping
screen along with a s/w shadow buffer. Seems like I get both a s/w
surface with “blit flips” and h/w flips with retrace sync.

(Kobo Deluxe uses an internal hack to get retrace sync’ed flips=20
while doing the actual rendering into a s/w surface. This is to avoid=20
alpha blending causing reads from VRAM.)

I would love to know more about how this ‘internal hack’ works. I just put
the finishing touches on a game I have been working on for a long time, only
to find out that when I put it on some computers my fast moving sprites have
terrible tearing. Laptops are the trend so far; I’ve tried two and the same
tearing happens on both of them. The other computers I have tried, all
desktops, and some very old, all seem to work fine. Is there any way you
would be willing to share your ‘internal hack’, or maybe just give some info
on how you went about synching a software surface? It would be bery much
appreciated. I have been scouring the net with no luck.

Thanks,
Dave

It’s in the source, and it’s all GPL and LGPL;

http://olofson.net/kobodl

Anyway, though there was some very non-portable experimental code
that actually implemented retrace sync directly on the hardware, the
SemiTriple buffering mode does not. It’s just a trivial setup that
allows rendering into a s/w “screen” while still using double
buffering with h/w page flipping. I implemented it after testing the
game on Win32 and noticing the performance impact of overdraw and
alpha blending when rendering into VRAM.

It’s as simple as this:

1. Set up a double buffered display with a h/w surface.
   NOTE: If this fails - ie you get a s/w surface -
   give up and do your usual stuff. There's nothing
   more you can do.

2. Create a s/w shadow surface with the same pixel
   format as the display surface.

while(running)
{
	3. Render into the s/w shadow surface.

	4. Blit the shadow surface to the screen.

	5. SDL_Flip()
}

With some luck, you’ll get a fast DMA blit for 4, and retrace sync for
5 - and that’s as fast and nice s/w rendering gets on modern
hardware.

Note that if you’re only performing blits to the screen (ie no direct
pixel fiddling), you should first check whether you can get all blits
you need h/w accelerated after opening the display. If you can, just
SDL_DisplayFormat*() all your surfaces and blit directly to the
double buffered display.

That said, very few backends support h/w alpha blending, so until
glSDL and similar backends become widely available, you might as well
assume that alpha is never accelerated, if you’re feeling lazy.

This is what I’ve been doing in Kobo Deluxe so far, although it is
possible to enforce normal single or double buffering via the video
options. The upcoming release also has an option to remove all
in-game alpha blending, so h/w acceleration can be used as long as
there’s accelerated colorkey blitting.

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Wednesday 08 October 2003 03.27, David Beck wrote:

(Kobo Deluxe uses an internal hack to get retrace sync’ed
flips=20 while doing the actual rendering into a s/w surface.
This is to avoid=20 alpha blending causing reads from VRAM.)

I would love to know more about how this ‘internal hack’ works. I
just put the finishing touches on a game I have been working on for
a long time, only to find out that when I put it on some computers
my fast moving sprites have terrible tearing. Laptops are the trend
so far; I’ve tried two and the same tearing happens on both of
them. The other computers I have tried, all desktops, and some very
old, all seem to work fine. Is there any way you would be willing
to share your ‘internal hack’, or maybe just give some info on how
you went about synching a software surface? It would be bery much
appreciated. I have been scouring the net with no luck.

Just wanted to say thanks for such a quick and informative response! It
really helped me out.

Thanks!