Hello all, this is something very, very simple. So simple, it's almost silly. However, I've been using it since I started using allegro (and wrote these files on 4/10/2005). All it is, is a simple list of colors defined to replace makecol calls. In most cases, you'd just use makecol(r,g,b), but sometimes you just want to write the color name. Perhaps it is tedious to look up the list, but after a while, I've grown so use to it, I often just say a color name and can expect it to be in the list. And of course, there's routines to break a color into its separate r,g,b components of which I have also written functions for, but they aren't optimized so I'm not relaying them here.

Also note, that I didn't write this list of colors. They come from the CMUgraphics Library and I've included a disclaimer at the bottom of the header file. Well, anywho, here they are (you could just include the following code in your own header/cpp files somewhere).

In a header file:

// Apparently my post is too big.  I've attached the header code w/disclaimer in a text file.

In a c/cpp file:

Now for some sample usage. I've written a simple button object that takes a back color (among other intital variables) and breaks down the color on its own functions and changes rgb settings to get its depth. Here's two buttons, one with SADDLEBROWN and the other as ROYALBLUE:

[img http://comp.uark.edu/~spsilve/button1.JPG]
[img http://comp.uark.edu/~spsilve/button2.JPG]

Maybe you can use it, maybe you can't. Just thought I'd offer.

I dont want to say its a bad idea, surely anything that lets you express colors in a more readable way is better but Ive never heard of most of those colors, much less know what r,g,b values they probably represent.

Looks handy. One thing that could help it: Define an array of references to allow easy indexing, then make an identical array of c-style strings to hold the names of the colors. It would make for a nice user interface usage.

Why have two arrays? Create a struct that stores both the value and name and create one array of this struct.

Make it with C++, and use the stl map.

map<string, int> colors;

colors["white"] = makecol(255,255,255);

...

Hey, you guys do whatever you want with it. Although, I prefer WHITE over colors["white"].

This is starting to turn into another C++ Fractal.

AE.

In my endeavours to create a SVG rendering library I had to define a list of all standard named colours in SVG (which I think is the same as the standard CSS colours). I did it like this:

One can easily create an array of Allegro colour values, but I didn't actually need that...

I'm used to clBlack, clWhite and such from my time using Borland C++ Builder, so I've continued to do also with Allegro.
Although I don't have a predefined pretty file with XX colors, I just add them whenever I need a new color.
Also, rather than using integers taking up memory(I know, its not much but still) I do it with defines instead like:

#define clBlack makecol(0,0,0)
#define clWindow makecol(192,192,192)
#define clWindowBorder makecol(20,20,20)
etc..

Onewing:
Having those const's call makecol at start before the color depth is set, or by default 8bit, doesn't mess up at 15+bit color depth?

ixilom:
What's worse? Taking memory or calling a function every time you use cl######?

I'm more perplexed by this:

Why do Americans/American English speaking people need a different shade of grey than the British English speaking world?

I wrote this in 10 minutes:

If I want a particular colour, say beige, I can pretty well guess where it is in a hsv world. The hue would be like orange, but saturation would be lower and the value raher high. So I would write:

my_beige = colour(orange, 0.5, 0.8);

And if I want some blue with a twist towards violet, I could interpolate:

my_indigo = colour(interpolate(blue, magenta, 0.1), 0.4, 1);

I think I get closer what I really want this way, instead of using some constants named SEASHELL. Well, I had to test two times on the latter one, before I got what I wanted.

[edit]
Well, the interpolation should have to take care of cases where the two colours are on both sides of hue = 360. The mean of 10 and 350 is not 180. It should be 0 or 360.

The problem with this is that there's this thing called the International Colour Consortium (ICC) which sets these things called standards. There's a bunch of standard colour names with standard colour values. So if you're going to guess colour values, you'd better name them something like my_approximation_of_beige. Because "beige" is a standard name for the colour represented by rgb(245, 245, 220).

On the other hand different sets of standard colours are often used for different purposes anyway...

I don't know, haven't messed with it as of yet.

To me, "calling a function every time" is worse than "taking memory", considering what all computers can handle these days. However, the list above is quite bloated, especially if you don't even use 90% of it in your program.

Yeah, I once called GRAY and then later called GREY for virtually the same background color and got two very different results. I was perplexed by this as well.

Rock on.

You just answered the second quote with your first

Actually, No I didn't.

It might not be much of a difference

60000000 Loops
Using Define: 4.7s
Using Int: 1.2s

600000000 Loops
Using Define: 50.0s
Using Int: 14.4s

Almost a 3:1 difference

I know there will be a timedifference, but set your bit depth to something else, assign a color to an int with another bit depth.
We don't want that now do we?

That's simple to avoid though, by assigning the variables after setting the color depth.

That's basically what I do.

I reset the colors everytime the color depth changes.