The reason yours is working, Jugibur, is due to the way that colors are stored behind the scenes. I'm sure you are aware of this, but colors without alpha are stored as unsigned integers of which 24-bytes are used (0xffffff for example). When you animate this number, it will go like this --> 0x000001, 0x000002, 0x000003, ..., 0x0000ff. It will do this no matter what color you tween to because that's how numbers increment.
So, from black (or any other dark blue) to full blue, it will work. HOWEVER, black green will look like this: 0x000001, 0x000002, 0x000003, ..., 0x0000ff, 0x000101, 0x000102, 0x000103, ..., 0x0001ff, etc etc before finally arriving at 0x00ff00. To animate green (for example), you must increment not by 0x1 as the juggler does, but by 0x100. For red, you must increment by 0x10000.
That is why you are getting flickering, because you are going through over 1.5 million more color combinations on your way to your destination than you expect. For example, 0x0000ff is blue, and then 0x000101 is nearly black. I implemented a method to fade to and from a shade of red in the current game I am working on. Basically I have a BOOL called toRed, and if it is true then in onEnterFrame I add 0x10000 to the color of the stage background. Once it reaches the color I want, I set toRed to NO and then every frame it subtracts 0x10000 from the color. Another method I just thought of would be to create a child class of SPJuggler (call it ColorJuggler or something) and have a method that accepts the passedTime and a specified color. You can then multiply passed time by the offset (0x100 for green, 0x10000 for red, 0x10100 for yellow, etc) and use that value instead.
Both of these implementations have the limitation that they will only go to colors that have either equal values or 0 (FA0000, DD0000, AAAA00, 870087, etc, but not 870198 or anything). If you want to have that kind of control, you will definitely need to track each portion of the color individually. You can quickly extract this by using a bitwise AND (color & 0xff0000 will give you the red value). Then instead of simply checking the color, as I do in my function, you can check all three separately and adjust them if they need it. Something like this (remember bitwise functions have a lower priority than equality checking so they need to be in parenthesis):
#define RED 0xff0000
#define GREEN 0x00ff00
#define BLUE 0x0000ff
- (void)onEnterFrame:(SPEnterFrameEvent *)event
{
uint theColor = __WHATEVER__.color;
if( (theColor & RED) == __XX__ && (theColor & GREEN) == __YY__ && (theColor & BLUE) == __ZZ__)
{
//You reached your target
}
else
{
if((theColor & RED) != __XX__)
theColor += 0x010000; //Or minus, depending on your fade
if((theColor & GREEN) != __YY__)
theColor += 0x000100;
if((theColor & BLUE) != __ZZ__)
theColor += 0x000001;
__WHATEVER__.color = theColor;
}
}
The simpler version with limited colors:
- (void)onEnterFrame:(SPEnterFrameEvent *)event
{
uint theColor = __WHATEVER__.color;
if( theColor == __XX__ )
{
//You reached your target;
}
else
{
theColor += __OFFSET__; //(0x010000 for red, 0x010100 for yellow, etc)
}
}
If you need it to go faster, use 2 instead of 1, etc. However, it won't get much slower than this unless you implement some logic to keep it from happening every frame. Hope this helps!
P.S. Oscar, there is nothing different about a hexidecimal number. If you look at it in the debug variables window, it will actually display as the number it really is unless you turn on hex viewing. Hex is just a convenience method ;). For example, you can easily tell that 0xff0000 is red, but how about "16711680" (the decimal equivalent)? 16711680 and 0xff0000 are the exact same thing to the hardware :).