Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
The reason to use a single number as a color was because 3-component colors in a data structure drawing command just seemed too unwieldly. But I'm starting to wonder if this was truly a wise decision to make. The trouble now is it would mean having two versions of every drawing instruction, yuck!
yeah, but once all formats are equally compatible, then in no time they
would be used by all (I think, it sound logical). of couse back-comp would
be nice...
Personally I think, 1-element colors are easier to handle, especially as we don't have [pak] yet. In an abstraction, I would only need to use one dollar variable to pass a color instead of three, and the required counting of positional arguments in data structure drawing instructions already is *very errorprone*. And using 3-element colors would triple the amount of color arguments to count! I'm already trembling ...
My GEM patches OTOH have a lot of [unpack $1 $2 $3] constructs. Btw: It would be nice if the GEM color objects would accept lists instead of being forced to [unpack 0 0 0] in front of every colorRGB object.
But I admit: Generally colors don't map well to a one-dimensional scale, as the data structure colors show. Colors generally are better mapped to things like a 2-dimensional color circle or to three or four sliders. Encoding RGB color in one float is hard enough, but how to encode RGBA into one float?
This really is a hard question and probably it is another area, where a general mapping abstraction library will be necessary.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__