[SDL] Palettized picture looks bad, but only in SDL
joey at rmci.net
Wed Aug 27 22:11:01 PDT 2003
> --- 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
> > > *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
> > 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
> > > 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
> be added to an image when it's not strictly necessary... would you
> 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,
More information about the SDL