Gimp and SDL

I have been using Gimp with my project to make my images. What I have been
doing is making gif files with reduced palletes (whatever minimum they
need, such as 10 colors to 200 colors). They work fine for the program I’m
presently doing (TuxTyping, to be released GPL within a couple of weeks at
version 0.5).

However, I notice that I do get lower performance than others get using
the exact same routines I do.

So I was wondering, can anyone tell me what I need to do to get my Gimp
images in a format optimized for SDL (i.e., with less conversion)? For
example, how do I save an image as 8/16/32-bit in Gimp? Is there a format
which will work better loaded by SDL_Image? (I know this last one has
popped up regularily, but I haven’t ever really seen any good
recommendations.)

Thx.

(BTW, sorry if this is slighty OT… it’s more a question about Gimp ;)–
Sam Hart http://www.physics.arizona.edu/~hart/
Web Page Highlights: Video Game History, Black Hole Simulation, & more.
OTHER WEB SITES MAINTAINED BY SAM HART
http://www.geekcomix.com/ - Geekcomix, the Daily Geek Comic Strip Site
http://www.physics.arizona.edu/~hart/gw/ - Ghostworks (Alt./Linux Computing)

Sam Hart wrote:

I have been using Gimp with my project to make my images. What I have been
doing is making gif files with reduced palletes (whatever minimum they
need, such as 10 colors to 200 colors). They work fine for the program I’m
presently doing (TuxTyping, to be released GPL within a couple of weeks at
version 0.5).

However, I notice that I do get lower performance than others get using
the exact same routines I do.

So I was wondering, can anyone tell me what I need to do to get my Gimp
images in a format optimized for SDL (i.e., with less conversion)? For
example, how do I save an image as 8/16/32-bit in Gimp? Is there a format
which will work better loaded by SDL_Image? (I know this last one has
popped up regularily, but I haven’t ever really seen any good
recommendations.)

How you save the images in GIMP really doesn’t matter. How they are
stored in memory at run-time does.

I have found the best speed comes if, after loading a bitmap, you
convert
it to the same format as the display.

Init the display, then…
SDL_Surface *oldSurface = LoadImage(filename); //or is it Load_Image()?
SDL_Surface *newSurface = SDL_DisplayFormat(oldSurface);

This will copy your bitmap to newSurface, which is in the same format
as the actual display. This means SDL does not have to do any bitmap
conversions in realtime, they all happen when it is first loaded into
memory.

		-fjr

Init the display, then…
SDL_Surface *oldSurface = LoadImage(filename); //or is it Load_Image()?
SDL_Surface *newSurface = SDL_DisplayFormat(oldSurface);

Actually, this is better:

temp = IMG_Load(filename); /* It’s “IMG_Load()” :wink: */
surf = SDL_DisplayFormat(temp);
SDL_FreeSurface(temp);
^
_____|
|
This last part’s important, because if you load 10 640x480 32bit images
and reduce them down to 8bit, you’ll end up not with 10 images, but with
20 (because you’re not freeing the 32bit depth bitmaps that you actually
loaded!)

-bill!

William Kendrick wrote:

Init the display, then…
SDL_Surface *oldSurface = LoadImage(filename); //or is it Load_Image()?
SDL_Surface *newSurface = SDL_DisplayFormat(oldSurface);

Actually, this is better:

temp = IMG_Load(filename); /* It’s “IMG_Load()” :wink: */
surf = SDL_DisplayFormat(temp);
SDL_FreeSurface(temp);
^
_____|
|
This last part’s important, because if you load 10 640x480 32bit images
and reduce them down to 8bit, you’ll end up not with 10 images, but with
20 (because you’re not freeing the 32bit depth bitmaps that you actually
loaded!)

I didn’t put that in because I thought it was obvious. Perhaps that was
a
bad assumtion to make.

		-fjr

I didn’t put that in because I thought it was obvious. Perhaps that was
a bad assumtion to make.

There’ll always be newbies. :slight_smile:

-bill!

I didn’t put that in because I thought it was obvious. Perhaps that was
a bad assumtion to make.

There’ll always be newbies. :slight_smile:

I knew about it… but it is always good to include junk like that since
this is a mailing list and goes to so many (who may or may not know).

Thanks to both for the input.

(I actually think I may be doing this… it’s something I know about…
but I do need to go back and check as I haven’t looked at that section in
a while… Granted, I didn’t completely understand what was /really/
happenning until now… Thx.)On Mon, 12 Jun 2000, William Kendrick wrote:


Sam Hart http://www.physics.arizona.edu/~hart/
Web Page Highlights: Video Game History, Black Hole Simulation, & more.
OTHER WEB SITES MAINTAINED BY SAM HART
http://www.geekcomix.com/ - Geekcomix, the Daily Geek Comic Strip Site
http://www.physics.arizona.edu/~hart/gw/ - Ghostworks (Alt./Linux Computing)