HOWTO color cycling

SDL Development
#1

Hi fellow,

Some time ago, someone (David Olafson, I think) asked for doing color
cycling when you can’t really use hardware palette.

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.
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.

Best regards,
IoDream.______________________________________________________________________________
ifrance.com, l’email gratuit le plus complet de l’Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP…
http://www.ifrance.com/_reloc/email.emailif

#2

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. :slight_smile:

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! :slight_smile:

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 -'On Saturday 25 August 2001 22:03, Jo wrote:

#3

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.

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.
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.

Everything is right, but palette images are faster, if working in
system memory or blitting from system memory to video memory.
Only if the blitting is hardware accelerated or you are blitting
from hardware to hardware memory the palette images could be slower.

Bye,
Johns–
Become famous, earn no money, create music or graphics for FreeCraft
http://FreeCraft.Org - A free real-time strategy game engine
http://FreeCraft.Net/fcgp - The FreeCraft Graphics Project
http://FreeCraft.Net/fcsp - The FreeCraft Sound Project

#4

-----Message d’origine-----De : sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]De la part de
David Olofson
Envoy? : lundi 27 ao?t 2001 14:47
? : sdl at libsdl.org
Objet : Re: [SDL] HOWTO color cycling

(snipped)

Cool idea! :slight_smile:

Thanks :wink:

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.

I agree with that, but I’ve noticed that palette effect (like fade-in/out)
don’t work with GDI display (look at testwin in SDL test programs). This
should be emulated by the SDL, I think.

(snipped)

//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 -’

ifrance.com, l’email gratuit le plus complet de l’Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP…
http://www.ifrance.com/_reloc/email.emailif

#5

just an idea: save the image 3 times: 1time only with the r component,
second the g component, third with the b component! then cycle it with the
alpha value? is just an idea and i did no thinking about it!> ----- Original Message -----

From: iodream@ifrance.com (Jo)
To:
Sent: Tuesday, August 28, 2001 11:08 PM
Subject: RE: [SDL] HOWTO color cycling

-----Message d’origine-----
De : sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]De la part de
David Olofson
Envoy? : lundi 27 ao?t 2001 14:47
? : sdl at libsdl.org
Objet : Re: [SDL] HOWTO color cycling

(snipped)

Cool idea! :slight_smile:

Thanks :wink:

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.

I agree with that, but I’ve noticed that palette effect (like fade-in/out)
don’t work with GDI display (look at testwin in SDL test programs). This
should be emulated by the SDL, I think.

(snipped)

//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 -’

__

ifrance.com, l’email gratuit le plus complet de l’Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP…
http://www.ifrance.com/_reloc/email.emailif

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

#6

[…]

I agree with that, but I’ve noticed that palette effect (like
fade-in/out) don’t work with GDI display (look at testwin in SDL test
programs). This should be emulated by the SDL, I think.

Weird… Even if SDL didn’t emulate it (as in "windoze fools SDL into
believing the screen is in a real 256 color mode), it should work, I
think. I’ve done that very thing in a Win16 port of Project Spitfire (the
DOS version fades between intro/demo/credits/game screens), and I guess
it should work on Win32 as well…

//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 -'On Tuesday 28 August 2001 23:08, Jo wrote:

#7

It would probably be a lot faster to rip and adapt SDLs alpha blitting
code to use separate alpha channels - because that’s what you’d achieve;
an RGB blending effect of sorts. :slight_smile:

//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 -'On Wednesday 29 August 2001 13:18, Dan wrote:

just an idea: save the image 3 times: 1time only with the r component,
second the g component, third with the b component! then cycle it with
the alpha value? is just an idea and i did no thinking about it!

#8

I was using a real 32bpp mode. Sorry I should have told you :wink:

-----Message d’origine-----De : sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]De la part de Dan
Envoy? : mercredi 29 ao?t 2001 13:19
? : sdl at libsdl.org
Objet : Re: [SDL] HOWTO color cycling

just an idea: save the image 3 times: 1time only with the r component,
second the g component, third with the b component! then cycle it with the
alpha value? is just an idea and i did no thinking about it!

----- Original Message -----
From: @Jo1 (Jo)
To:
Sent: Tuesday, August 28, 2001 11:08 PM
Subject: RE: [SDL] HOWTO color cycling

-----Message d’origine-----
De : sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]De la part de
David Olofson
Envoy? : lundi 27 ao?t 2001 14:47
? : sdl at libsdl.org
Objet : Re: [SDL] HOWTO color cycling

(snipped)

Cool idea! :slight_smile:

Thanks :wink:

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.

I agree with that, but I’ve noticed that palette effect (like fade-in/out)
don’t work with GDI display (look at testwin in SDL test programs). This
should be emulated by the SDL, I think.

(snipped)

//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 -’

__

ifrance.com, l’email gratuit le plus complet de l’Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP…
http://www.ifrance.com/_reloc/email.emailif

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

ifrance.com, l’email gratuit le plus complet de l’Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP…
http://www.ifrance.com/_reloc/email.emailif