SDL_CopyPixels?

Scott_Lahteine · July 15, 2003, 1:35am

Hi,

I’m working on a game that loads images with SDL and creates OpenGL
textures from the loaded images. Part of this process involves making
an SDL surface that has the appropriate size for an OpenGL texture
(having dimensions that are powers of two such as 128, 256, 512, 1024)
and then copying the loaded image into the new surface. However, when I
use SDL_BlitSurface to do the copy the alpha channel is dropped from
the destination. So I wrote my own function called “CopyPixels” that
simply copies the surface pixels and alpha straight into the
destination. Was this necessary, or is there some SDL function to do
the equivalent operation?

if (source->flags & SDL_SRCALPHA && source->format->BitsPerPixel == 32)
	// Images with alpha are copied verbatim
	CopyPixels(source, srcRectPtr, surface, NULL);
else
	// Other images are compatible with SDL
	SDL_BlitSurface(source, srcRectPtr, surface, NULL);

scott

Glenn_Maynard · July 15, 2003, 3:38pm

You want to unset SDL_SRCALPHA before blitting, so alpha is simply copied.
SDL_SetAlpha( image, 0, SDL_ALPHA_OPAQUE );On Tue, Jul 15, 2003 at 01:34:03AM -0700, Scott Lahteine wrote:

I’m working on a game that loads images with SDL and creates OpenGL
textures from the loaded images. Part of this process involves making
an SDL surface that has the appropriate size for an OpenGL texture
(having dimensions that are powers of two such as 128, 256, 512, 1024)
and then copying the loaded image into the new surface. However, when I
use SDL_BlitSurface to do the copy the alpha channel is dropped from
the destination. So I wrote my own function called “CopyPixels” that
simply copies the surface pixels and alpha straight into the
destination. Was this necessary, or is there some SDL function to do
the equivalent operation?

–
Glenn Maynard

Eric_Wing · July 15, 2003, 9:48pm

Check out the documentation for SDL_BlitSurface and
SDL_SetAlpha. There are serveral flags that affect the
behavior of SDL_BlitSurface. (SDL_SRCALPHA,
SDL_SRCOCOLORKEY).

Keep in mind that that SDL_Surface coordinate systems
(y increases downwards) are inverted from OpenGL
coordinate systems (y increases upwards), so if you
follow standard OpenGL texture coordinate conventions,
your images are going to be upside down. So depending
if this is important to you or not, the possible
saving grace of having your own CopyPixels routine is
that you can invert the pixels there. But of course,
you need to fully embrace your routine and not mix and
match with BlitSurface depending on the bit-depth.

Good luck,
-Eric> From: “Scott Lahteine”

Hi,

I’m working on a game that loads images with SDL and
creates OpenGL
textures from the loaded images. Part of this
process involves making
an SDL surface that has the appropriate size for an
OpenGL texture
(having dimensions that are powers of two such as
128, 256, 512, 1024)
and then copying the loaded image into the new
surface. However, when I
use SDL_BlitSurface to do the copy the alpha channel
is dropped from
the destination. So I wrote my own function called
"CopyPixels" that
simply copies the surface pixels and alpha straight
into the
destination. Was this necessary, or is there some
SDL function to do
the equivalent operation?

if (source->flags & SDL_SRCALPHA &&
source->format->BitsPerPixel == 32)
// Images with alpha are copied verbatim
CopyPixels(source, srcRectPtr, surface, NULL);
else
// Other images are compatible with SDL
SDL_BlitSurface(source, srcRectPtr, surface,
NULL);

scott

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Scott_Lahteine · July 20, 2003, 6:02pm

Glenn Maynard wrote:

You want to unset SDL_SRCALPHA before blitting, so alpha is simply
copied.
SDL_SetAlpha( image, 0, SDL_ALPHA_OPAQUE );

That does the trick, Glenn. Thanks!

Eric Wing Wrote:

…
Keep in mind that that SDL_Surface coordinate systems
(y increases downwards) are inverted from OpenGL
coordinate systems (y increases upwards), so if you
follow standard OpenGL texture coordinate conventions,
your images are going to be upside down.
…

Actually it depends on how you define your Orthographic projection. In
my sprite engine I initialize it as follows so that top-left
corresponds to 0,0:

glOrtho(0, screen->w, screen->w, 0, -1.0, 1.0);

SL

Eric_Wing · July 21, 2003, 6:13pm

Eric Wing Wrote:

…
Keep in mind that that SDL_Surface coordinate
systems
(y increases downwards) are inverted from OpenGL
coordinate systems (y increases upwards), so if
you
follow standard OpenGL texture coordinate
conventions,
your images are going to be upside down.
…

Actually it depends on how you define your
Orthographic projection. In
my sprite engine I initialize it as follows so that
top-left
corresponds to 0,0:

glOrtho(0, screen->w, screen->w, 0, -1.0, 1.0);

SL

Actually you’re only partially correct. That ortho
trick is unusable in many situations. But first, I
said “if” you follow standard OpenGL conventions it
will be an issue. If you don’t care, it’s not an
issue. It’s a convention. Conventions are arbitrary,
but they may have consequences if you don’t conform
with the majority of the community.

OpenGL has been around for awhile so there is a lot of
legacy code available. If you try to use some if it
you might be in for some nasty surprises. Or consider
if you are working with other engineers that are
following the standard conventions. When you interface
your code, you may have issues.

So consider the following examples:

You are not using an orthographic projection. You
are placing textures on 3d models or terrains that
require a perspective mode projection. You won’t be
able to use that ortho trick
In #1, you could get around the issue by changing
the placement of your glTexCoords, but consider what
if you had taken a complicated model loader somebody
else had written. The model loader might use platform
specific image loaders, so you replace that section
with an SDL_image loader. But most likely your
conventions are inverted and your model is going to
look really messed up with the inverted textures. You
could change the TexCoords everywhere in the code
(assuming you have access to it), but it would be much
easier to just flip your image. And it woold save you
grief if you later require another outside module
which has the same problem.
You are a one of many engineers on a project. You
are responsible for writing a module for the program,
but you are not allow to touch certain OpenGL states
such as the projection matrix. All the other engineers
are following standard OpenGL conventions, so you’re
stuff is will be inverted.

But as I said, it’s only a convention. SDL follows
conventions from most 2D APIs (y is done to make it
easier to think about how it is stored in memory) and
OpenGL follows the conventions of most 3D APIs (y is
done to follow standard mathematical conventions), but
now that SDL supports both 2D and 3D, one of the
conventions had to be pushed aside.

So if you’re writing all your own code, and you never
have to deal with any other OpenGL engineers or
interface with outside OpenGL code, then you’re
probably safe. But it’s something to think about.

-Eric__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software