ColorAll Library

[SMcNeill]

I know a lot of folks have enjoyed my color name library for 32-bit colors, so sometime back, I decided to expand the library so that the color names could be used in any screen mode for us, as I'll illustrate below and in the next few posts.

First thing to do, grab the two library files below and put them in your QB64 library.

Next, be aware that the library now makes use of QB64's precompiler, so you'll need to set a precompiler value to tell it which screen mode your program is going to be working with.  The variable for this is simply called KOLOR.

   So, for a text screen (SCREEN 0) program, all you'd need to do is basically set KOLOR to 0 (to indicate it's going to be SCREEN 0 text graphics), and then include the ColorAll.BI at the top of your program, and then you can use the color names instead of the numbers for your program -- as indicated below.

Code: QB64: [Select]

1. 'First, set the KOLOR value to tell the precompiler what color scheme we need.
2.  
3. $LET KOLOR = 0
4.  
5.  
6. 'Then include the library file.
7. '$include:'ColorAll.BI'
8.  
9.  
10. 'Then use the names
11. COLOR White, Yellow
12. PRINT "White on Yellow"
13. COLOR Red, Blue
14. PRINT "Red on Blue"
15. COLOR BrightWhite, Yellow
16. PRINT "Bright White on Yellow"
17. COLOR Blink + BrightWhite, Magenta
18. PRINT "Blink Bright White on Magenta"
19.  

Color values can be read by looking at the variables inside ColorAll.BI, but for simplicity's sake, I'll include them here since there's only a few to deal with in text mode:

$IF KOLOR = 0 THEN
    CONST Black = 0~%%
    CONST Blue = 1~%%
    CONST Green = 2~%%
    CONST Cyan = 3~%%
    CONST Red = 4~%%
    CONST Magenta = 5~%%
    CONST Brown = 6~%%
    CONST White = 7~%%
    CONST Gray = 8~%%
    CONST LightBlue = 9~%%
    CONST LightGreen = 10~%%
    CONST LightCyan = 11~%%
    CONST LightRed = 12~%%
    CONST LightMagenta = 13~%%
    CONST Yellow = 14~%%
    CONST BrightWhite = 15~%%
    CONST Blink = 16~%%
$END IF

[SMcNeill]

32 bit images work basically the same way, except we set KOLOR to 32 and then have access to a whole lot more color names to make use of  inside our program, as below:

Code: QB64: [Select]

1.  
2.  
3. 'First, set the KOLOR value to tell the precompiler what color scheme we need.
4.  
5. $LET KOLOR = 32
6.  
7.  
8. 'Then include the library file.
9. '$include:'ColorAll.BI'
10.  
11.  
12. 'Then use the names
13.  
14. SCREEN _NEWIMAGE(800, 600, 32)
15.  
16. COLOR White, Yellow
17. PRINT "White on Yellow"
18. COLOR Red, Blue
19. PRINT "Red on Blue"
20. COLOR Silver, Gold
21. PRINT "Silver on Gold"
22. COLOR BrickRed, SkyBlue
23. PRINT "Brickred on Skyblue"
24.  
25.  

[SMcNeill]

Now, 256 color images are a little more complex to work with, as I didn't bother to try and name the standard QB64 palette.  Instead, I changed QB64's 256 color palette so that it matches the names which I provided -- a subtle and important distinction!   (Think of it as a Square is a Rectangle, but a Rectangle does not have to be a Square... We're making QB64's palette suit the names, not making the names suit the palette.)

If you attempt to simply use the program with a 256 color screen, as you were using it for text and 32-bit screens, you'll see a failure which will resemble the following:

Code: QB64: [Select]

1.  
2.  
3. 'First, set the KOLOR value to tell the precompiler what color scheme we need.
4.  
5. $LET KOLOR = 256
6.  
7.  
8. 'Then include the library file.
9. '$include:'ColorAll.BI'
10.  
11.  
12. 'Then use the names
13.  
14. SCREEN _NEWIMAGE(800, 600, 256)
15.  
16. COLOR White, Yellow
17. PRINT "White on Yellow"
18. COLOR Red, Blue
19. PRINT "Red on Blue"
20. COLOR Silver, Gold
21. PRINT "Silver on Gold"
22. COLOR BrickRed, SkyBlue
23. PRINT "Brickred on Skyblue"
24.  

Run it and you'll see that our colors don't match squat here.   They're broken BADLY....

So...   How do we fix it???

Include the second library at the end of your program and then call it after you make your 256 color screen to set the screen so the palettes match the value we assign to the names for it, as so:

Code: QB64: [Select]

1.  
2.  
3. 'First, set the KOLOR value to tell the precompiler what color scheme we need.
4.  
5. $LET KOLOR = 256
6.  
7.  
8. 'Then include the library file.
9. '$include:'ColorAll.BI'
10.  
11.  
12. 'Then use the names
13.  
14. SCREEN _NEWIMAGE(800, 600, 256)
15. Set256Palette 0 '0 as this is the default screen handle for our program here.
16.  
17. COLOR White, Yellow
18. PRINT "White on Yellow"
19. COLOR Red, Blue
20. PRINT "Red on Blue"
21. COLOR Silver, Gold
22. PRINT "Silver on Gold"
23. COLOR BrickRed, SkyBlue
24. PRINT "Brickred on Skyblue"
25.  
26. '$Include:'Set256Palette.BM'

Notice the difference here?   We include the library to set the palette for a 256 color screen, and then we call the routine inside it to make the screen colors match the values we assign for the names we're using. 

Not a massive change, but one worth emphasizing, as without it our color names aren't going to work worth a hoot in 256 color modes.

[_vince]

this is really handy, nice work Steve

[SMcNeill]

In a few weeks, as more people adopt the latest development builds, I'll post an update to the library where it'll default to 32-bit colors.  In fixing the glitch here https://www.qb64.org/forum/index.php?topic=720.0 , I added the ability to see if a precompiler variable has been defined already, or not, which would let this work:

$IF KOLOR = UNDEFINED THEN
   $LET KOLOR = 32
$END IF

***************

Since most people use the library for 32-bit color modes, it'd save them a step in using the library.  The only issue is if you don't have a version of QB64 with the bug-fix described above, it'll make the library unusable. -- thus, the delay on adopting the library enhancement until more folks get the development build (or we release v1.3)

[Qwerkey]

32 bit images work basically the same way, except we set KOLOR to 32 and then have access to a whole lot more color names to make use of  inside our program

Steve, this is excellent (again!).  I see that your RGB values are indeed to standard colour names (not quite sure who the keeper of standard colour names is).  Of the 16 million 32-bit colours, you've done 270.  In a few more of your poor sleep nights, you'll probably complete the full set!  Though I hope rather that you'd sleep better (from another poor sleeper).  Richard

[RhoSigma]

FYI

[TerryRitchie]

32 bit images work basically the same way, except we set KOLOR to 32 and then have access to a whole lot more color names to make use of  inside our program

(not quite sure who the keeper of standard colour names is)

That's a good question. A few weeks ago I was looking into this (before I remembered Steve had already done work on this) and noticed the W3C has a color list. But I also found other color lists out there that claim there are only 140 approved colors, other lists maintain there are only 215, and so on.

Who does have the final authority on the color set?

[SMcNeill]

The CSS standards are where most colors come from, as specified here, and are derived from "the X11 color set":  https://drafts.csswg.org/css-color/#named-color

HTML uses the same standard as defined here: https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#simple-colour

If input is an ASCII case-insensitive match for one of the named colors, then return the simple color corresponding to that keyword. [CSSCOLOR]

CSS2 System Colors are not recognized.

Which is why the list Rho posted has "STRICT" and (whatever the other option was) listed.  Browsers *HAVE* to support the "strict" colors to follow the standards set; anything more is just something additional they offer.

Edit:  "Strict" and "Tolerant" we're the terms in the chart Rho shared.

[SMcNeill]

All you'd ever want to know about the history of color names, and more:  https://m.youtube.com/watch?v=HmStJQzclHc#fauxfullscreen

And the RGB.txt he talks about, from MIT: http://li.mit.edu/Archive//NetApp/JavaScript/Reader/rgb.html

[TerryRitchie]

Thanks Steve, I'll look into these.