Instantiable FlxColors

[IQAndreas]

I touched on this in the FlxColor spreadsheet, here I will elaborate.

Right now, we have lots of static methods that all follow the same pattern (some of them I just added to make a point):

• RGBtoHex(r, g, b):uint
• RGBtoHexString(r, g, b):String
• RGBtoHSV(r, g, b)
• HexToHSV(uint)
• RGBtoHSB()
• HSVtoRGB()
• etc.

Along with those we also find things like getGreen(uint), getBlue(uint), getAlpha(uint), getAlphaFloat(uint).

This all to me looks very messy, and we can keep adding conversion methods until the cows come home.

Instead, how about we allow people to create instances of FlxColor:

var royalBlue:FlxColor = new FlxColor(0xFF040585);
trace(royalBlue.red); // 4
trace(royalBlue.alphaFloat); // 1.0;

If they don't want to use a hex value, they can use one of the static helper methods:

var royalBlue = FlxColor.fromHSB(240, 97, 52);
var royalBlue = FlxColor.fromRGB(4, 5, 133);
var royalBlue = FlxColor.fromCMYK(97, 96, 0, 48);

And if they want to convert one color to another:

var royalBlue:FlxColor = new FlxColor(0x040585);
var hsv = royalBlue.toHSV();

Or put it on one line:

var hsv = FlxColor.fromRGB(4, 5, 133).toHSV();

[IQAndreas]

We can hammer out details on what goes on inside the FlxColor instances later. For example, it would be a better idea to store a color generated with fromHSB with the actual HSB values instead of loosing accuracy by converting it to a uint and storing it that way.

Also, Flixel would probably still continue to use uints when storing colors internally (exhibit A) for performance reasons, but users of the library are more than welcome to use FlxColor instances in their games if performance isn't an issue.

Any thoughts? Would it help make Flixel more logically organized, or just complicate things?

[Dovyski]

That's great! I would definitely make Flixel more logically organized. My only concern was the performance hit, but if we stick with uint for color internally, there will be no problems.

[JoeCreates]

I've actually been working on this is HaxeFlixel, and strangely, it's very much as you have described, except there is no such thing as converting a color, because a FlxColor can automatically pretend to have any rgb/hsb/hsl/cmyk property. https://github.com/HaxeFlixel/flixel/issues/1027

I will be pushing both a completely revamped FlxColor and demo for FlxColor pretty shortly. It includes the ability to get and set any rgb/hsb/hsl value, though precision is lost as the underlying type is an Int (see below). I've added additional features for creating gradients with optional easing functions.

Using a little haxe magic, FlxColor is actually an Int in disguise, so it is interchangeable with Ints/hex literals. For example, you can do:

var myColor:FlxColor = 0xff123456;
trace(myColor.hue);

Basically it provides the convenience of FlxColor methods, without losing the int performance and functionality. I'm not sure how much of it will be portable to as3, but before anyone starts duplicating work, you may want to wait and see how much can be reused. ;)

[JoeCreates]

I've made a pull request to HaxeFlixel with instantiable FlxColors: https://github.com/HaxeFlixel/flixel/pull/1113

[IQAndreas]

I've actually been working on this is HaxeFlixel, and strangely, it's very much as you have described

Do you mind if I pretty much steal the entire class for AS3 Flixel? That way, the two libraries match which will help both users and tutorial writers.

It includes the ability to get and set any rgb/hsb/hsl value, though precision is lost as the underlying type is an Int (see below).

I'm not a fan of loosing precision unnecessarily, so for the AS3 version, I have a different plan of approach which should work.

Using a little haxe magic, FlxColor is actually an Int in disguise, so it is interchangeable with Ints/hex literals.

That so cool! Haxe has so many cool features, I don't know why I haven't switched over yet. Alas, Flash doesn't have anything like that (well, we could pervert the prototype chain for AS3's uint class, but that's just wrong in my eyes).

[JoeCreates]

You are welcome to try to take as much as you can from HaxeFlixel's FlxColor, however, I'm not sure some of it will translate so well to AS3, considering a lot of the implementation ended up being centered around the use of the haxe abstract.

Also, it's possibly worth considering the performance implications of mimicking the behavior. The benefit that comes with the small loss of precision in HaxeFlixel's FlxColor provides the benefit of keeping the performance as if only ints were ever used. There is no data other than a single int, and no complex data type instantiated. In HaxeFlixel, this has meant that FlxColor has replaced everywhere that used to use an int or uint as a color without any loss to performance, whereas in AS3 Flixel, it might be best to use FlxColor only for when conversions are required?

As I say, you are welcome to use of it what you can. The conversion algorithms themselves should port pretty easily. :)