[SDL] HOWTO color cycling

David Olofson david.olofson at reologica.se
Mon Aug 27 05:44:01 PDT 2001


On Saturday 25 August 2001 22:03, Jo wrote:
> Hi fellow,
>
>    Some time ago, someone (David Olafson, I think) asked for doing
> color cycling when you can't really use hardware palette.

Actually, I tried to explain how to do it. :-)


>    Color cycling is an old *trick* to make movement effect only by
> doing a palette rotation that cost nothing compared to sprite movement.
> Tou can see this effect, for exemple, in animated fountains or
> waterfalls (like in Sonic). It was still in use in DOS VGA 256-color
> games, so it's required when porting old games to SDL.

Well, at least for *easy* porting. However, it's much more portable to 
translate these effects into real animations.

As to performance, that isn't much of an issue is most cases. You can't 
do hardware scrolling (yet), so if you're scrolling you have to redraw 
the entire screen every fram anyway. Besides, most machines used today 
are countless times faster than the original targets.


>    The problem is that in 15-or-more bits modes, there is no more
> hardware palette; the pixels store their RGB(+alpha) into themselves.
> To do an equivalent effect, you need to reserve a range of colors (to
> keep cycling pixel position) and to replace on-the-fly theses pixels by
> the good color values. It's CPU intensive, and unhandy.
>
>    The way I found to achieve this effect is the following one.
>
>    If you want to do color cycling on sprites/pictures, you should have
> these pictures in 8 bits format. To load them fine in SDL, you need to
> load their palettes as well (in my_surface->format->palette). Alright ?
> Don't you see where I am going ? Yes: just do the palette rotation into
> the pictures' palettes. So when you blit them on your screen, SDL will
> use the newly changed palettes. Not so diffucult, you see !
>    The only counterpart of this method is that you mustn't convert the
> pictures' display format to the screen' (this is a well known way to
> improve blitting speed). Otherwise you could lost your palettes, and
> prevent color cycling.
>
>    Am I wrong ? If yes, please correct this stuff.

Cool idea! :-)

It should work, but it's probably faster to use a specifically optimized 
pixel level real time animation instead. If you don't convert the 
graphics to the display format, SDL will have to do the palette lookup in 
real time every time you blit the surface. This is usually not (never?) 
hardware accelerated on mainstream consumer hardware. (IIRC, some 3D 
cards support indexed color textures, though... Would that be usable?)

Then again, SDL's 256 color emulation seems to be pretty darn fast (*), 
so I wouldn't think it's a big deal, at least not for low resolutions 
(like 320x240) on "normal" computers.

(*) Fast enough that I still haven't bothered to port my GUI +
    visualization toolkit to non-256 modes, despite using it on X
    in 32 bit mode most of the time. Resolutions used are 640x480
    and up, with nearly full screen oscilloscope displays and the
    like, and it's not exactly sluggish.


How about using the gamma ramp trick, and fall back on this "emulator 
trick", if gamma isn't supported? (If it's really worth the effort, that 
is.)


//David Olofson --- Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------------> http://www.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> david at linuxdj.com -'




More information about the SDL mailing list