[SUGGESTION] Color-Cycling in 16/32bit

[Lt. Smash]

I would find it useful when it would be possible to do color-cycling (Palette Cycling) in 16/32bit 'cause then we could use alpha blended sprites, transparent things and color-cycling.
I know you will ask how should we handle this but I found out that there is a palette menu(also in 16/32bit) in the new v.2.8 beta.
When this would be implemented we could use this menu to select/change the colors we want to use for the cycling.

I think there should also be a delay in the function(CyclePalette(int start, int end, int delay))which says how long each color should be displayed.


Hope that this could be implemented.

[BOYD1981]

i'd like to see this and/or a way of controlling the cycle speed. perhaps it could be done in a similar way to how Unreal and other earlier 3D games that can handle 16/32bit colour deal with textures; they're limited to using a 256 colour palette, that way you can set the palette values for the items individually. or something.
oh yes, it would also be great if colour cycling didn't get blocked.

[Khris]

I believe that due to how the colors are managed in 16/32bit, traditional color-cycling is impossible.
256 uses a fixed palette, 16bit and above don't (the palette is dynamic and will change as needed or something like that)

I know you will ask how should we handle this but I found out that there is a palette menu(also in 16/32bit) in the new v.2.8 beta.

This palette menu has been there since I've discovered AGS (three years ago). It's only purpose in hi- or true-color mode is to find the color number of an RGB color.

[Gilbert]

Actually as a hidden "feature" in the engine, palette effects "sort of" work in 16/32 modes.
If you import a 8-bit background in a 16/32 bit game and modify the palette in game (eg. palette cycling) the colour could be changed.

BUT according to CJ, he didn't put any effort into implement it, this is just a side effect, perhaps from some of the codes in Allegro or whatever.
Also, it is not perfect, if there is a sprite drawn on top of the area that involves palette changing the colour could be incorrect.

So this is not supported and NOT RECOMMENDED to use (unless CJ had really put some effort in recent versions). In fact it may not even work if for example some libraries are updated in the engine.

I think the delay thing is just redundant.
If you are skillful enough to manage palette effects in a (I mean 8-bit, don't care about 16/32 bit) game, doing scripting for such purpose is too easy.

[Pumaman]

I believe that due to how the colors are managed in 16/32bit, traditional color-cycling is impossible.

Indeed, palette cycling is based on the way that 256-colour mode works. To emulate it in 16/32-bit would be horrendously slow, since it would have to do a per-pixel colour change.

[Monsieur OUXX]

Indeed, palette cycling is based on the way that 256-colour mode works. To emulate it in 16/32-bit would be horrendously slow, since it would have to do a per-pixel colour change.

On the other hand, i think this wouldn't be a real problem in a 320x200 game with a 3000MHz computer :-)

I'll try to write a little module to handle this (YES it'll be even more slow with a script instead of a plugin, but with all this slowness around it would be marginal  )

I think it won't be too hard to define an array of 256*3 RGB values and then pretend it's a palette