I have a 640 x 480 x 8bpp palettized image that is displayed as the
title/menu screen at the beginning of my game. The software that I used
to produce it outputted it in 24-bit color mode, and I decreased it to 8
bit mode. It looks fine, and it uses 208 unique colors.
But, in my game, it doesn’t look as good.
I wondered what the problem was, so I tried decreasing my desktop
display bitdepth to 256 colors. In Microsoft Paint, it looks even worse
than SDL, even when Paint is in full-screen viewing mode, but in Paint
Shop Pro (albeit a 16-bit version) it looks just as good as it should.
I did these tests because I suspected that Windows might have been
hogging the palette entries from SDL, but apparently that’s not the
case, since PSP did it okay.
I believe I’ve tested how my game looked in full-screen mode as well
as windowed. The results were the same; it looks as if a few palette
entries have been deemed equal when they aren’t close enough for it to
look alright. I guess I’m wondering if anyone knows that SDL doesn’t
handle palettized images (in palettized video mode) very well, or
something like that. In that case, I can work around it by using a
higher bitdepth for just the title screen, but not my entire game,
because using the palette simplifies some things. I’ll be happy to
share my relevant code if you suspect something is wrong with it.
Thanks, everyone.
== Joey
question = ( to ) ? be : ! be; – Wm. Shakespeare
(taken from slashdot.org)
I guess I’m wondering if anyone knows that SDL doesn’t
handle palettized images (in palettized video mode) very well, or
something like that. In that case, I can work around it by using a
higher bitdepth for just the title screen, but not my entire game,
because using the palette simplifies some things.
Perhaps you’ve already done this, and I haven’t tried this out in
detail, but I would check out the SDL_HWPALETTE flag and
SDL_SetPalette (or SDL_SetColors) first. If this is redundant, I
apologize.
I think the simple answer is that Paint Shop, MS Paint, and SDL all
have different palettes, or rather different default palettes.
You have to explicity set the palette using SDL - if you’re just using
LoadBMP this isn’t good enough (I think, I may be wrong). There
might be a helper function in SDL_image which loads palettes properly
for you, but in any case there is a function to set the palette in SDL,
you’ll have to figure out how to load the palette from the BMP file
yourself (I do have a tutorial on it somewhere - actually I think it
was out of Andre LaMothe’s Windows Game Programming For Dummies, which
I can’t get for you right now as it’s packed for me to move house
When I started my game in SDL I ran across this problem, so I created a
function to load a BMP from disk and save it’s palette as a text file,
then I created a function which loaded this text file to set the
palette for all images. I can try and dig these out for you if you
like, but they’re probably buried deep…__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Thanks, both to Drake Wilson and Paul Smith! I’ve got it fixed by
copying the image’s palette into the screen’s palette, which works fine
because that’s the only image onscreen. I think this technique should
work for the rest of my game. I guess I assumed SDL would handle
palettes for me. That’s an unrealistic expectation because I’m sure
there would be too much overhead involved. So, don’t bother to find
your code, but thanks again, Paul.
== Joey
question = ( to ) ? be : ! be; – Wm. Shakespeare
(taken from slashdot.org)
Thanks, both to Drake Wilson and Paul Smith! I’ve got it fixed by
copying the image’s palette into the screen’s palette, which works
fine
because that’s the only image onscreen. I think this technique should
work for the rest of my game. I guess I assumed SDL would handle
palettes for me. That’s an unrealistic expectation because I’m sure
there would be too much overhead involved. So, don’t bother to find
your code, but thanks again, Paul.
Not only would there be too much overhead, but it’s just plain wrong.
What would you expect SDL to do if you loaded 2 images, one after the
other, and both were displayed on screen? Use the first palette? Use
the second palette? Use a palette that is specified by the developer?
I know which option I prefer
Glad I helped BTW.
OF course, this means that there’s an extra design element you may not
have thought about when producing your artwork - all of your images have to use the exact same palette (in the same order!) if they are
to be displayed on screen at once. If you using an image editing
facility which scales down from 24-bit to 8-bit by matching the palette
as closesly to the original colours as possible, you’re going to have
problems.
It might be worthwhile reserving a few palette entries for frequently
used colours, like 0 for black, 1 for white, or whatever, so that if
you wanted to you could fill the screen with “colour 0” and know in
advance what that colour is going to be.__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
OF course, this means that there’s an extra design element you may not
have thought about when producing your artwork - all of your images have to use the exact same palette (in the same order!) if they are
to be displayed on screen at once. If you using an image editing
… if you’re using a paletted screen. It’s still very useful to use
paletted images if you’re using a non-paletted framebuffer: they use much
less memory. This works well in OpenGL, too.
in the same order
Not quite: a blit can very easily map palette entries that are in
different orders. It’s somewhat slower, of course, but only by a
lookup in a small (= memory cache-friendly) table. I’m pretty sure SDL
blits do this.On Wed, Aug 27, 2003 at 12:52:09PM -0700, Paul Smith wrote:
— Glenn Maynard <g_sdl at zewt.org> wrote: > On Wed, Aug 27, 2003 at
12:52:09PM -0700, Paul Smith wrote:
OF course, this means that there’s an extra design element you may
not
have thought about when producing your artwork - all of your images have to use the exact same palette (in the same order!) if they
are
to be displayed on screen at once. If you using an image editing
… if you’re using a paletted screen. It’s still very useful to use
paletted images if you’re using a non-paletted framebuffer: they use
much
less memory. This works well in OpenGL, too.
Hmm, hadn’t thought of that, somehow my brain had mapped “paletted
images” onto “paletted framebuffer”. You are of course perfectly
correct.
in the same order
Not quite: a blit can very easily map palette entries that are in
different orders. It’s somewhat slower, of course, but only by a
lookup in a small (= memory cache-friendly) table. I’m pretty sure
SDL
blits do this.
I’m not sure about this. Are you still talking about a non-paletted
framebuffer? It seems strange that an extra level of indirection would
be added to an image when it’s not strictly necessary… would you care
to clarify what you mean so I can learn a bit here?
Paul________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
I’m talking about paletted surfaces to paletted surfaces (including
framebuffers). I believe it just makes a mapping of closest matches.
If the color in the image exists in the framebuffer’s palette, it’ll
map it; if it doesn’t, it’ll find the closest match.
I havn’t double-checked this, though. The word “palette” doesn’t appear
in sdlblitsurface.html.On Wed, Aug 27, 2003 at 10:16:01PM +0100, Paul Smith wrote:
I’m not sure about this. Are you still talking about a non-paletted
framebuffer? It seems strange that an extra level of indirection would
be added to an image when it’s not strictly necessary… would you care
to clarify what you mean so I can learn a bit here?
— Glenn Maynard <g_sdl at zewt.org> wrote: > On Wed, Aug 27, 2003 at
12:52:09PM -0700, Paul Smith wrote:
OF course, this means that there’s an extra design element you may
not
have thought about when producing your artwork - all of your
images
have to use the exact same palette (in the same order!) if they
are
to be displayed on screen at once. If you using an image editing
I’m not really sure what I expected SDL to do with the palettes,
actually :). But my art should work the way I have it now.
… if you’re using a paletted screen. It’s still very useful to
use
paletted images if you’re using a non-paletted framebuffer: they use
much
less memory. This works well in OpenGL, too.
On a somewhat related topic, is there any real advantage to using
palettized images (which I do right now so I can change the color of
certain elements in my art whose pixels point to known palette entries),
but using a 16-bit (or higher) framebuffer? I mean, will other
bit-depths be more accelerated or anything? I thought I’d keep it
simple, with the side-effect of also being functional for people with
ancient video cards.
Hmm, hadn’t thought of that, somehow my brain had mapped “paletted
images” onto “paletted framebuffer”. You are of course perfectly
correct.
in the same order
Not quite: a blit can very easily map palette entries that are in
different orders. It’s somewhat slower, of course, but only by a
lookup in a small (= memory cache-friendly) table. I’m pretty sure
SDL
blits do this.
I’m not sure about this. Are you still talking about a non-paletted
framebuffer? It seems strange that an extra level of indirection
would
be added to an image when it’s not strictly necessary… would you
care
to clarify what you mean so I can learn a bit here?
I’d like if you post what you find on this, if anything, so I can learn,
too.
Thanks.
If you use an unpaletted framebuffer, you can get the bonuses of
paletted images (less memory usage), while not being required to use the
same palette for all images. I don’t know how this works when using
hardware surfaces, however, which you need to use for optimal speed.
I use this with OpenGL, and it’s both a big texture memory win and a
nice speed bonus with no quality penalty. 16-bit textures are usually
faster than 32-bit textures in OpenGL, due to the memory reduction, but
you pay a quality penalty; paletted textures give a speed bonus with
no penalty at all, if the image happens to fit in a 256-color palette.On Wed, Aug 27, 2003 at 08:24:10PM -0600, Joey Hewitt wrote:
On a somewhat related topic, is there any real advantage to using
palettized images (which I do right now so I can change the color of
certain elements in my art whose pixels point to known palette entries),
but using a 16-bit (or higher) framebuffer? I mean, will other
bit-depths be more accelerated or anything? I thought I’d keep it
simple, with the side-effect of also being functional for people with
ancient video cards.
do you have a penalty in speed for it looking up the correct color each blit
or does it cache it somehow?
Also does it mess with shading at all if you used a paletted image?> ----- Original Message -----
From: g_sdl@zewt.org (Glenn Maynard)
To:
Sent: Wednesday, August 27, 2003 10:28 PM
Subject: Re: [SDL] Palettized picture looks bad, but only in SDL
On Wed, Aug 27, 2003 at 08:24:10PM -0600, Joey Hewitt wrote:
On a somewhat related topic, is there any real advantage to using
palettized images (which I do right now so I can change the color of
certain elements in my art whose pixels point to known palette entries),
but using a 16-bit (or higher) framebuffer? I mean, will other
bit-depths be more accelerated or anything? I thought I’d keep it
simple, with the side-effect of also being functional for people with
ancient video cards.
If you use an unpaletted framebuffer, you can get the bonuses of
paletted images (less memory usage), while not being required to use the
same palette for all images. I don’t know how this works when using
hardware surfaces, however, which you need to use for optimal speed.
I use this with OpenGL, and it’s both a big texture memory win and a
nice speed bonus with no quality penalty. 16-bit textures are usually
faster than 32-bit textures in OpenGL, due to the memory reduction, but
you pay a quality penalty; paletted textures give a speed bonus with
no penalty at all, if the image happens to fit in a 256-color palette.
that is a very very cool feature.> ----- Original Message -----
From: slouken@devolution.com (Sam Lantinga)
To:
Sent: Thursday, August 28, 2003 8:46 AM
Subject: Re: [SDL] Palettized picture looks bad, but only in SDL
do you have a penalty in speed for it looking up the correct color each
blit
or does it cache it somehow?
It caches the lookup the first time you blit the surface.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
You can get some truly ugly results, simply because the right mix of
colors does not exist in the palette, and I’m not sure if you can have a
different palette for each mipmap level. (I strongly suspect that you
can not.)On Thu, Aug 28, 2003 at 01:28:45AM -0400, Glenn Maynard wrote:
I use this with OpenGL, and it’s both a big texture memory win and a
nice speed bonus with no quality penalty. 16-bit textures are usually
faster than 32-bit textures in OpenGL, due to the memory reduction, but
you pay a quality penalty; paletted textures give a speed bonus with
no penalty at all, if the image happens to fit in a 256-color palette.
–
1024D/E65A7801 Zephaniah E. Hull <@Zephaniah_E_Hull>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
…and the burnt fool’s bandaged finger goes wobbling back to the fire.
– The Gods of the Copybook Headings, by Kippling.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20030828/cb778b83/attachment.pgp
