FlxColorUtil and FlxColor

[JoeCreates]

I'm wondering if FlxColor and FlxColorUtil are a little overcomplicated. FlxColor, which is likely the first place anyone would go to try to make a color, doesn't contain anything but presets. To make a color from rgb values you have to go to FlxColorUtil, at which point you are flooded with options, some of which seem redundant.

For example, let's say we just want to make a simple color from RGB values, and possibly an alpha. We can use:-

• FlxColorUtil.makeFromARGB(Alpha:Float, Red:Int, Green:Int, Blue:Int)
• FlxColorUtil.getColor32(Alpha:Int, Red:Int, Green:Int, Blue:Int)
• FlxColorUtil.getColor24(Red:Int, Green:Int, Blue:Int)

Why not something nice and simple in FlxColor? Like this perhaps:

• FlxColor.RGB(Red:Int, Green:Int, Blue:Int, Alpha:Int = 255)

Then we have things like:-

• FlxColorUtil.ARGBtoHexString(Color:Int):String
• FlxColorUtil.ARGBtoWebString(Color:Int):String
• FlxColorUtil.colorToHexString(Color:Int):String

Neither of the first two specifically take ARGB values, and yet they have ARGB in the name. The third isn't a "color" to hex at all, rather it is a byte (or value from 0-255) to hex string, and is used by the first two, but isn't really a color only thing.

Then there's a load of permutations for conversions of color representations:-

• ARGBtoRGB
• RGBtoHSV
• HSVtoARGB

Are these useful? ARGB and RGB are both just ints, and all this "conversion" does is set the alpha to 255. Seeing as there already exists methods for getting HSV or ARGB objects from color ints, the others also don't seem necessary.

If there were simply functions for getting colors for each method (getRGB, getHSV, etc..) that return an argb Int, and "to" functions for turning an Int into the desired representation, then every combination of conversions would be possible by doing things like toHSV(RGB(r, g, b)).

In summary, the colors stuff seems a bit excessive. I'm wondering if it might be possible to make it a bit for efficient. Perhaps, FlxColorUtil could in fact be merged into just FlxColor?

[gamedevsam]

Agreed, FlxColorUtil is kinda redundant, FlxColor is a much better place for all of that good stuff.

[Gama11]

I don't like that idea - I don't want to mix color constants with utility functions. Auto completion is so much more helpful if you keep them seperated.

[sruloart]

// I want to have something like this:
FlxG.color(function that returns a hex value / hexvalue you choose from your IDE).add(palette's name, color's name)

// So, I can have something like this:
TitleText.color = FlxG.color.menu.text;

// So I can easily achieve stuff like this:
Make all of the in-game menu texts' colors blue.

[JoeCreates]

@Gama11
I would question the need for so many presets in the first place. Autocompletion is only an issue due to having so many, and it already wouldn't be as bad if there were fewer (and more concise) functions.

All the colors like "charcoal", "wheat" and "ivory" seem a bit unnecessary. If a dev has a color in mind, they will not likely find any such colors via autocomplete as these names are not colors. (If somebody has a dark grey in mind, are they likely to type "FlxColor.ch"?) They could, perhaps, find them if the browse the autocomplete list or the FlxColor api, but that's likely just going to be way more effort than just using a tool to figure out your own color or experimenting with rgb values. Then there's "FlxColor.TRANSPARENT", which presumably exists to alleviate the arduous task of typing "0".

Also, not wanting to mix utility constants with utility functions does make it harder to find the functions. I don't think it's wise to separate things based on whether or not they're functions or constants. They should be separated based on what their intended use is: what does the developer require? Currently, if a dev wants a color, there are way too many options, and they all obscure each other. There are too many constants, too many functions, and too many classes. Autocomplete already takes a massive hit from this complexity.

@sruloart's suggestion is nice. I was wondering about a way of being able to store your own presets.

I don't consider the autocomplete thing to be a big issue, but it would be even smaller with fewer presets. We could also put presets in an object, like FlxColor.presets.RED. This is possibly unnecessary, but if we were to add some kind of customizable palette it would probably make sense to put presets in there, e.g. FlxColor.palette.red or FlxG.color.red.

[JoeCreates]

Guys, I'm looking for opinions on how color presets should be accessed now that FlxColor is instantiable and has a few new static methods.

In order for presets to be useable as default params, and to give autocomplete suggestions, the presets need to be static.

The new static methods of FlxColor are: fromRGB, fromHSB, fromHSL, fromCMYK, fromInt, interpolate, and gradient.

Options for preset access include FlxColor.RED, FlxColorPreset.RED and FlxColor.preset.RED. The first won't break anything, but is potentially less good for autocomplete. Right now I'm thinking that wouldn't matter so much, though. It is at least consistent in the fact that everything static in FlxColor is used to get a FlxColor instance (or multiple in the case of gradient).

There are 44 presets in total.

[sruloart]

I don't think I understand the all presets thing (44 presets?). Can you give an example? What, Why and How.

[JoeCreates]

@sruloart http://api.haxeflixel.com/types/flixel/util/FlxColor.html Currently FlxColor is nothing but a bunch of preset colors.

For what you wanted to do before, by the way, I'd recommend making a class of static vars for your own presets. The main benefit being that it will give you autocomplete suggestions, whereas having dynamic palettes will not. Furthermore you cannot use the values from a dynamic palette as default method parameters.

[sruloart]

• aah, I just didn't understand what do you meant by "presets" (a single color cannot be a set...). FlxColor.RED is useful as it is.
• What if instead of 44 colors you will have a very long list of colors with parameters names, hex, RGB, saturation, lightness (Similar to this)? There's no point in having "Medium_Blue" next to "CHARTREUSE", there's no consistency and no reason for these specific colors. No one knows what half of these colors are anyway, even with the auto-complete.
  • Instead, you will have hundreds of colors to choose from, and you will sort it out for the auto-complete like so: FlxColor.[Base Color, e.g. RED].[List of all the colors that are considered red, including easy to understand colors, like LightRed, DarkRed and so on].
• With all of these colors available, I (and everyone) can have a static colors based palette.