#### Archived

This topic is now archived and is closed to further replies.

# cycling colors in a bitmap with precise color control.

This topic is 5934 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Anyone have any tips on this? My game runs in 16bit color. How the pixels are packed depends on what machine runs it, but I have functions to compensate for that (I'm using SDL). I have a sprite who needs to constantly cycle its colors through a range, and the range needs to be redefinable. Such as I may want it to smoothly blend from yellow to orange and back to yellow, or maybe later I want it to go from yellow to blue (and pass through green on the way there) and back to yellow. Oh yeah, this is automated. Every x milliseconds I run this function so the sprite just cycles it's colors on its own. So far I've taken some stabs at it, but I can't control the color cycling as precisely as I'd like. Basically I'm grabbing each pixel one at a time, chopping it up into three 8 bit values representing r, g and b, incrementing the three values, then packing it back into the pixel. But it doesn't seem like incrementing the values linearly will achieve what I want. Stuff like i = base increment value r += 4*i; g += 2*i; //b stays the same in hopes of cycling from yellow to orange, since green and red make yellow, and by biasing towards red it heads for orange. But then when red goes beyond 255 and back down to 0, I get stuck with very green colors until red can catch up again. Stuff like if (r >254) r = 128; help, but it's still chunky. Maybe my approach is just wrong all together. I'm still very new to graphics programming. Thanks. [edited by - tortoise on September 12, 2002 2:27:46 PM]

##### Share on other sites
What you want is: Sprite is color A, and it must become color B within T milliseconds.

Then, let Ar, Ab, Ag be the colors of A, and Br, Bg, Bb the colors of B. The R, G, B pixel colors will be defined as:

R = Ar + t*(Br - Ar)/T
G = Ag + t*(Bg - Ag)/T
B = Ab + t*(Bb - Ab)/T

Where t is the time, in milliseconds, since the last color change. The colors will shift linearily.

With this method, when t = 0, R = Ar, G = Ag, B = Ab, and when t = T, R = Br, G = bg, B = Bb

When T = t, set t back to 0, set A to B (since you''ll be shifting from the current color to another one) and generate a new B as you see fit (from an array, or randomly, or any way you choose), and change T as well if you need to have slower color shifts.

I strongly advise that you precalculate (Bx - Ax)/T and store it as a new variable (say, Lx) so the function will be faster only calculating 3x(X = Ax + t*Lx) each pixel.

A = (255, 255, 0) Yellow
B1 = (255, 128, 0) Red, T1 = 1000 ms
B2 = (255, 255, 0) Yellow, T2 = 5000 ms
B3 = (255, 255, 0) Yellow, T3 = 60000 ms
B4 = (0, 0, 255) Blue, T4 = 500 ms
and so on...

Good luck!!!

-Cheers, ToohrVyk

1. 1
2. 2
3. 3
Rutin
15
4. 4
5. 5

• 9
• 9
• 11
• 11
• 23
• ### Forum Statistics

• Total Topics
633678
• Total Posts
3013290
×