[SDL] blitting with SDL/OpenGL

[Stephane Marchesin]

Jan Pfeifer wrote:
> hi :-)
> 
> i'm looking for a fast (and still portable) way for blitting in SDL+OpenGL in 
> 2 scenarios, but I'm not being able to find out how to do this. Any hints ? 
> I'll be grateful for any comments.
> 
> Scenario 1) 
> Fixed Image (background for the 3d animation): 
> the ways i wonder it's possible to do this is:
> 
> a) create a big texture with the background and draw a texturized quad 
> wherever region i want to redraw. How should one handle when the size of the 
> screen is not easily divided into 2^n sized rectangules ? (for instance 
> 800x600) Do i have to handle the assossiated geometry complexity or is there 
> some library ?

There is an extension for non 2^n textures : 
http://oss.sgi.com/projects/ogl-sample/registry/NV/texture_rectangle.txt

Or if you don't care too much about texture memory, create a huge 
texture (ie 1024x512) and use it only in part (this can also be used as 
a fallback for the previous solution, if the extension is not present).

Or generate mipmaps with glumipmaps but this will break image quality 
and will be slow.

Or, as you said, handle the geometry by hand.

> 
> b) create an auxiliary color buffer, glDrawPixels the image there and then 
> glCopyPixels the are for redraw. I've heard (read actually) that this is slow 
> (because it allows lots of optional per pixel processing, even though i'm not 
> using any). And i didn't find anything in SDL to create the auxiliary buffer 
> ... (I wonder GLX -- or equivalent -- has to handle this).

In scenario 1 the fastest way is a), because you're not sure to get fast 
SDL blits (and you're mixing two accelration architectures, which I 
wouldn't do), and the texturing hardware is very powerful nowadays. You 
can also try glSDL, which in this case would fit pertectly (but not 
finished :( ).

> Scenario 2)
> Animated image, coming from main memory every frame. Again, i thought of two 
> simillar aproaches:
> 
> a) use glDrawPixels: i found out this to be terrible slow :( ... even in the 
> default (no special per pixel processing) settings ... i would guess that 
> this would be hw accelerated for any board that supports openGl but 
> apparently it's not ...

No, it's only accelerated on SGI machines (not the old ones) and maybe 
on powervr cards.

> 
> b) use Texture: load each image to texture and paint the texturized quad

This is rather slow (you have to upload a new texture every frame, you 
video bus bandwith will limit you somewhat), especially on Nvidia cards. 
You can look at software like mplayer that uses it. Don't even think of 
it if you use mipmaps, as mipmaps take quite some time to be generated.

Maybe you should take a look at test/testgl.c in the SDL sources, it 
shows a spinning opengl cube with a blitted overlay. This might be a 
good choice for scenario 2.