Blitting with SDL/OpenGL

SDL Development
1

hi :slight_smile:

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 ?

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).

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 :frowning: … 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 …

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

any others ?

again, thanks for any help/idea

=)

jan

ps.: i’m new in the list so sorry if this has been discussed before
(searching i found out some discussion in 1999 only)

2

gl can also work in orthographic mode. Ortho is 2d blitting basicly and
lets you work in screen space instead of 3d. You cant specify draw this
from (50,50)-(590,430) in pixel points but you could do something like map
your view matrix in such a way to make the screens dimensions go from 0-100
and then by drawing a rectangle from (25,25)-(75,75) it would make a
rectangle in the middle of the screen that is 50% of the width and height.
The only problems i have had with combining ortho and non-ortho gl is in
rendering in select mode (where you load names and draw things and it tells
you what was drawn under the mouse cursor). It doesnt seem to like doing
that from both modes but ::shrug:: i might not be doing it right.> ----- Original Message -----

From: janpf@yahoo-inc.com (Jan Pfeifer)
To: “SDL”
Sent: Monday, November 04, 2002 9:00 AM
Subject: [SDL] blitting with SDL/OpenGL

hi :slight_smile:

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 ?

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).

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 :frowning: … 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 …

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

any others ?

again, thanks for any help/idea

=)

jan

ps.: i’m new in the list so sorry if this has been discussed before
(searching i found out some discussion in 1999 only)

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

3

so far i haven’t had problems working simultaneously with non-ortho and ortho
(with screen coordinates for pixmaps) modelview/projection matrices. But i
haven’t done “select rendering yet” nor do i know how to find out what screen
area has been redrawn by my 3d models (the program has to recopy from the
background only the “dirtied” area). (did i understand you right?)

but then, my main problem still is to find out the best way to copy the
surfaces (images) around (from memory to video memory, and from video memory
to video memory) using SDL/OpenGL …

any ideas ?

thanks :slight_smile:

janOn Monday 04 November 2002 15:34, Atrix Wolfe wrote:

gl can also work in orthographic mode. Ortho is 2d blitting basicly and
lets you work in screen space instead of 3d. You cant specify draw this
from (50,50)-(590,430) in pixel points but you could do something like map
your view matrix in such a way to make the screens dimensions go from 0-100
and then by drawing a rectangle from (25,25)-(75,75) it would make a
rectangle in the middle of the screen that is 50% of the width and height.
The only problems i have had with combining ortho and non-ortho gl is in
rendering in select mode (where you load names and draw things and it tells
you what was drawn under the mouse cursor). It doesnt seem to like doing
that from both modes but ::shrug:: i might not be doing it right.

----- Original Message -----
From: “Jan Pfeifer” <@Jan_Pfeifer>
To: “SDL”
Sent: Monday, November 04, 2002 9:00 AM
Subject: [SDL] blitting with SDL/OpenGL

hi :slight_smile:

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 ?

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).

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 :frowning: … 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 …

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

any others ?

again, thanks for any help/idea

=)

jan

ps.: i’m new in the list so sorry if this has been discussed before
(searching i found out some discussion in 1999 only)

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

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

4

Jan Pfeifer wrote:

hi :slight_smile:

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 :frowning: ).

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 :frowning: … 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.