Help with SDL_Convert

SDL Development
1

I’ve used this function before but not so heavily that I might have
cause massive memory leaks. But now I’ll be using it a lot, so I
thought I’d get a firm description of what’s going on here.

The name SDL_Convert implies that one surface is being converted to
another’s format. But in fact it returns a new surface. My situation
is that I have a surface that’s a fraction of the size of my display
surface. But apparently I need to convert the surface so that when I
blit it to the display surface it matches format. Does that mean that
surface designated as “src” in the documentation should be the
non-display surface that I need converted to the display surface format?
Notably the format is not take from src, necessarily.

Please unconfuse me.–
Lilith

2

I’ll assume you mean SDL_ConvertSurface.

The name SDL_Convert implies that one surface is being converted to
another’s format. But in fact it returns a new surface.

Right, as the documentation says.

My situation is that I have a surface that’s a fraction of the size of
my display surface. But apparently I need to convert the surface so that
when I blit it to the display surface it matches format.

I don’t think so, but for performance reasons I would always convert loaded
images to the display’s format. Other than that, I think that you can also
blit between surfaces of different formats, it then does the conversion on
the fly.

Does that mean that surface designated as “src” in the documentation should
be the non-display surface that I need converted to the display surface
format?

Yes. You call it with the surface you want to blit to the screen but with the
screen’s format.

UliOn Monday 14 May 2007 18:38:32 Lilith Calbridge wrote:

3

I’ll assume you mean SDL_ConvertSurface.

Sorry about that. That will teach me to try to pen messages between
phone calls at the office.

The name SDL_Convert implies that one surface is being converted to
another’s format. But in fact it returns a new surface.

Right, as the documentation says.

My situation is that I have a surface that’s a fraction of the size
of

my display surface. But apparently I need to convert the surface so
that

when I blit it to the display surface it matches format.

I don’t think so, but for performance reasons I would always convert
loaded
images to the display’s format. Other than that, I think that you can
also
blit between surfaces of different formats, it then does the
conversion on
the fly.

Does that mean that surface designated as “src” in the documentation
should

be the non-display surface that I need converted to the display
surface

format?

Yes. You call it with the surface you want to blit to the screen but
with
the
screen’s format.

Let’s say I have a surface called “terrain” and I want to convert it to
the format of “screen”.

terrain2 = SDL_Convert Surface (terrain, screen->format, options);

I assume that terrain2 points to a newly created surface and that
terrain is still pointing to a valid surface?>>> On 5/14/2007 at 1:14 PM, Ulrich Eckhardt wrote:

On Monday 14 May 2007 18:38:32 Lilith Calbridge wrote:

Uli

–
Thanks,
Lilith

4

Well, if your ultimate goal is to simply make your surface blit quicker to
the screen because of it having the same format, I’d suggest using the
SDL_DisplayFormat(surface) function, as it is simpler and directly
accomplishes your goal. If you have a per-pixel-alpha surface(from a .png,
for instance), you should use SDL_DisplaySurfaceAlpha(surface).

You use it like so:
SDL_Surface * temp = IMG_Load(“pic.png”); //or SDL_LoadBMP(“pic.bmp”);
SDL_Surface * s = SDL_DisplayFormatAlpha(temp); //or
SDL_DisplayFormat(temp);
SDL_FreeSurface(temp); //if you really don’t need the original anymore…

Voila! Your surface, s, is ready for primetime. Hope that helps!
(really, you should check the return values from the functions, as per good
programming procedure, but this will do in a pinch.)
-Dave> ----- Original Message -----

From: lilith@dcccd.edu (Lilith Calbridge)
To:
Sent: Monday, May 14, 2007 2:06 PM
Subject: Re: [SDL] Help with SDL_Convert

On 5/14/2007 at 1:14 PM, Ulrich Eckhardt wrote:
I’ll assume you mean SDL_ConvertSurface.

Sorry about that. That will teach me to try to pen messages between
phone calls at the office.

On Monday 14 May 2007 18:38:32 Lilith Calbridge wrote:

The name SDL_Convert implies that one surface is being converted to
another’s format. But in fact it returns a new surface.

Right, as the documentation says.

My situation is that I have a surface that’s a fraction of the size
of

my display surface. But apparently I need to convert the surface so
that

when I blit it to the display surface it matches format.

I don’t think so, but for performance reasons I would always convert
loaded
images to the display’s format. Other than that, I think that you can
also
blit between surfaces of different formats, it then does the
conversion on
the fly.

Does that mean that surface designated as “src” in the documentation
should

be the non-display surface that I need converted to the display
surface

format?

Yes. You call it with the surface you want to blit to the screen but
with
the
screen’s format.

Let’s say I have a surface called “terrain” and I want to convert it to
the format of “screen”.

terrain2 = SDL_Convert Surface (terrain, screen->format, options);

I assume that terrain2 points to a newly created surface and that
terrain is still pointing to a valid surface?

Uli

–
Thanks,
Lilith

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

5

Thanks for the advice. That’s what I was going for but I seem to recall
having tried such in the past and it not working. My primary problem in
the past was that I would blit something to the “screen” surface and it
would come out in shades of grey. Someone suggested the
SDL_ConvertSurface, which cured the problem. Now I’ve started building
a static background for a game and in the test phases it doesn’t come
out at all. So I figured on trying the same solution. I am
encapsulating much of this into classes and the problem may be tied up
in that approach.

BTW, does anyone know if there are any books published on SDL? My
roommate swears she had one at one time but a thorough search of the
bedroom she filled with books and gaming stuff hasn’t turned up an SDL
book.

Thanks,
Lilith

Well, if your ultimate goal is to simply make your surface blit
quicker to
the screen because of it having the same format, I’d suggest using
the
SDL_DisplayFormat(surface) function, as it is simpler and directly
accomplishes your goal. If you have a per-pixel-alpha surface(from a
.png,
for instance), you should use SDL_DisplaySurfaceAlpha(surface).

You use it like so:
SDL_Surface * temp = IMG_Load(“pic.png”); //or
SDL_LoadBMP(“pic.bmp”);
SDL_Surface * s = SDL_DisplayFormatAlpha(temp); //or
SDL_DisplayFormat(temp);
SDL_FreeSurface(temp); //if you really don’t need the original
anymore…

Voila! Your surface, s, is ready for primetime. Hope that helps!
(really, you should check the return values from the functions, as
per good>>> On 5/14/2007 at 9:36 PM, “David Olsen” wrote:
programming procedure, but this will do in a pinch.)
-Dave

----- Original Message -----
From: “Lilith Calbridge” <@Lilith_Calbridge>
To:
Sent: Monday, May 14, 2007 2:06 PM
Subject: Re: [SDL] Help with SDL_Convert

On 5/14/2007 at 1:14 PM, Ulrich Eckhardt wrote:
I’ll assume you mean SDL_ConvertSurface.

Sorry about that. That will teach me to try to pen messages
between

phone calls at the office.

On Monday 14 May 2007 18:38:32 Lilith Calbridge wrote:

The name SDL_Convert implies that one surface is being converted
to

another’s format. But in fact it returns a new surface.

Right, as the documentation says.

My situation is that I have a surface that’s a fraction of the
size

of

my display surface. But apparently I need to convert the surface
so

that

when I blit it to the display surface it matches format.

I don’t think so, but for performance reasons I would always
convert

loaded

images to the display’s format. Other than that, I think that you
can

also

blit between surfaces of different formats, it then does the
conversion on
the fly.

Does that mean that surface designated as “src” in the
documentation

should

be the non-display surface that I need converted to the display
surface

format?

Yes. You call it with the surface you want to blit to the screen
but

with

the
screen’s format.

Let’s say I have a surface called “terrain” and I want to convert it
to

the format of “screen”.

terrain2 = SDL_Convert Surface (terrain, screen->format,
options);

I assume that terrain2 points to a newly created surface and that
terrain is still pointing to a valid surface?

Uli

–
Thanks,
Lilith

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

6

Thanks for the advice. That’s what I was going for but I seem to recall
having tried such in the past and it not working.

Can you provide example code?

My primary problem in the past was that I would blit something to
the “screen” surface and it would come out in shades of grey.

Hmmm, strange. I just checked some code that works, but I don’t convert
anything and it still works. I’m not using different input formats though,
but I’m also not setting the colour depth of the screen (bpp=0).

Someone suggested the SDL_ConvertSurface, which cured the problem. Now
I’ve started building a static background for a game and in the test
phases it doesn’t come out at all. So I figured on trying the same
solution.

Really, how about some example code?

I am encapsulating much of this into classes and the problem may be tied
up in that approach.

C++ is a mean bitch, it provides many, many ways to shoot yourself in the
foot. Used correctly, it does actually help writing correct programs though,
compared to C.

BTW, does anyone know if there are any books published on SDL?

Yes, there was “Programming Linux Games”, published in 2001 by No Starch
Press in cooperation with Loki Software, Inc. It heavily used SDL, no surprise
since it is a child of Loki (or maybe of Sam Latinga, but I think he worked
for Loki at that time). I have the sources for the book here, they were
rescued when the world turned on and left Loki behind, maybe you can find
them with a websearch.

good luck

UliOn Tuesday 15 May 2007 16:34:01 Lilith Calbridge wrote:

7

Programming Linux Games (http://nostarch.com/frameset.php?startat=plg -
still available for purchase in printed form) was written by John Hall
(who I just learned died of cancer in 2005 :frowning: ). John received
permission to provide a free download of the book and put it on his
website www.overcode.net . Unfortunately the domain has since expired
and has been picked up by squatters. http://overcode.yak.net which
mirrored his blog doesn’t mirror the writing directory. The good news is
that the wayback machine has a lot of that directory -
http://web.archive.org/web/20051118124325/http://www.overcode.net/~overcode/writing/plg/ . The things that don’t appear to be accessible are tarballs, however the PDF of the book appears to be available: http://web.archive.org/web/20041023042307/http://www.overcode.net/~overcode/writing/plg/local/release/plg-final-pdf-no-really-i-mean-it-this-time.pdf .

Rest in peace John…On Tue, 2007-05-15 at 18:51 +0200, Ulrich Eckhardt wrote:

On Tuesday 15 May 2007 16:34:01 Lilith Calbridge wrote:

BTW, does anyone know if there are any books published on SDL?

Yes, there was “Programming Linux Games”, published in 2001 by No Starch
Press in cooperation with Loki Software, Inc. It heavily used SDL, no surprise
since it is a child of Loki (or maybe of Sam Latinga, but I think he worked
for Loki at that time). I have the sources for the book here, they were
rescued when the world turned on and left Loki behind, maybe you can find
them with a websearch.

–
Sitsofe | http://sucs.org/~sits/

8

Programming Linux Games (http://nostarch.com/frameset.php?startat=plg>>> On 5/20/2007 at 2:36 PM, Sitsofe Wheeler wrote:

still available for purchase in printed form) was written by John
Hall
(who I just learned died of cancer in 2005 :frowning: ). John received
permission to provide a free download of the book and put it on his
website www.overcode.net . Unfortunately the domain has since
expired
and has been picked up by squatters. http://overcode.yak.net which
mirrored his blog doesn’t mirror the writing directory. The good news
is
that the wayback machine has a lot of that directory -

http://web.archive.org/web/20051118124325/http://www.overcode.net/~overcode/

writing/plg/ . The things that don’t appear to be accessible are
tarballs,
however the PDF of the book appears to be available:

http://web.archive.org/web/20041023042307/http://www.overcode.net/~overcode/w

riting/plg/local/release/plg-final-pdf-no-really-i-mean-it-this-time.pdf
.

And this right after I ordered the book from Amazon. :slight_smile:

Rest in peace John…

–
Lilith

9

Would that be the 2.5Mb bz2 tarball with all the code listings you’re
looking for? Seeing as it’s GPLed I can’t see any objection to it being
uploaded somewhere should that be needed.On Sun, 2007-05-20 at 20:36 +0100, Sitsofe Wheeler wrote:

The things that don’t appear to be accessible are tarballs,

Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html