_RGB vs _RGB32 in SCREEN 0 and SCREEN 32bit

[TempodiBasic]

Hi guys
while I'm attempting to build something for the 15 Days Halloween Challange I have fallen in this issue
In the wikipage of CONST you can read this

The constantName does not have to include a type suffix. The datatype is automatically infered by the compiler using the value.
Constant values cannot reference a variable, SUB or FUNCTION return values when defined.
The exception to the above are color functions _RGB32 and _RGBA32, which can be used in a CONST statement. See Example 2 below.

and if you pick the example 2 from the wiki in the page of CONST http://qb64.org/wiki/CONST  and you run the code you get error from the line

Code: QB64: [Select]

1. COLOR Red

and following the execution then we get an usual color text of SCREEN 0.
1. So code example 2 must be correct!
2. Using _RGB instead it runs good. So in SCREEN 0 we must use _RGB for not legacy color.
3. Creating a graphic screen in 32 bit of colors , if we use a _RGB color we get no graphic output to the screen while if we use _RGB32 it is all ok.
Here code demonstration

Code: QB64: [Select]

1. ' here we create a  _RGB color as CONST
2. SCREEN 0
3. CONST Red1 = _RGB32(255, 0, 0), red2 = _RGB(255, 0, 0), blu = _RGB32(0, 0, 255)
4.  
5. COLOR Red1
6. PRINT "Hello World PRINTed with _RGB32 color"
7. SLEEP 1
8. COLOR red2
9. PRINT "Hello World PRINTed with _RGB color"
10.  
11. SLEEP 2
12.  
13.  
14. SCREEN _NEWIMAGE(400, 300, 32)
15. PAINT (1, 1), red2
16. COLOR blu
17. PRINT "background made with _RGB color"
18. SLEEP 2
19. CLS , Red1
20. PRINT "background made with _RGB32 color"
21.  

In sum    _RGB -->SCREEN 0
              _RGB32-->SCREEN GRAPHIC 32

these results are features or glicthes?

Thanks to read and feedback

[SMcNeill]

_RGB and _RGB32 are two completely different commands.

_RGB returns a color value -- BASED ON THE SCREEN MODE.
_RGB32 returns a 32-bit color value.

Try this:

Code: QB64: [Select]

1. SCREEN 0
2. PRINT _RGB(255,0,0), _RGB32(255,0,0)
3. SLEEP
4. SCREEN 12
5. PRINT _RGB(255,0,0), _RGB32(255,0,0)
6. SLEEP
7. SCREEN _NEWIMAGE(640,400,32)
8. PRINT _RGB(255,0,0), _RGB32(255,0,0)

The two commands give vastly different values, which will affect your COLOR statement differently.

[TempodiBasic]

Thanks Steve
so we can agree to substitute in wiki example 2 _RGB at the place of _RGB32,
and we can  correct my first sentence

In sum    _RGB -->SCREEN 0
              _RGB32-->SCREEN GRAPHIC 32

to

In sum    _RGB -->SCREEN 0 and SCREEN GRAPHIC 32 if used AFTER SCREEN instruction
              _RGB32-->SCREEN GRAPHIC 32

as you show me _RGB gives as result the legacy number of color in SCREEN legacy mode and RGB value in SCREEN 32. So it can adapt its result to the kind of SCREEN and so it MUST be used after SCREEN statement.
Thanks again

[SMcNeill]

as you show me _RGB gives as result the legacy number of color in SCREEN legacy mode and RGB value in SCREEN 32. So it can adapt its result to the kind of SCREEN and so it MUST be used after SCREEN statement.
Thanks again

For CONST, _RGB works a little differently than we'd normally see.

Normally, _RGB has 4 parameters -- Red, Green, Blue, optional IMAGE_HANDLE.  (Maybe not after the changes to allow RGBA values with the RGB command; I'm not 100% certain of the new syntax.)

Since CONST are defined pre-compile, we can't use program handles for them, so that 4th optional parameter is used to specify a SCREEN MODE.

For example:

Code: QB64: [Select]

1. CONST Red1 = _RGB(255, 0, 0, 0), Red2 = _RGB(255, 0, 0, 13), Red3 = _RGB(0, 0, 255, 32)
2. PRINT Red1
3. PRINT Red2
4. PRINT Red3

Red1 is _RGB(255,0,0) for a SCREEN 0 image.
Red2 is _RGB(255,0,0) for a SCREEN 13 image.
Red3 is _RGB(255,0,0) for a SCREEN _NEWIMAGE(x,y,32) image.

The fourth parameter lets us spell out which RGB value we need to work properly with our program.

(Whereas _RGB32 always just gives us the 32-bit values.)

[SMcNeill]

And, I agree with you: 

Example 2, as it's written, is wrong.  http://qb64.org/wiki/CONST

Code: QB64: [Select]

1. CONST Red = _RGB32(255,0,0)
2.  
3. COLOR Red
4. PRINT "Hello World"

The above tosses us an error.

One fix is to make it a screen 0 color value:

Code: QB64: [Select]

1. CONST Red = _RGB(255,0,0)
2.  
3. COLOR Red
4. PRINT "Hello World"

Another is to use it while in a 32-bit screen:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640,400,32)
2. CONST Red = _RGB32(255,0,0)
3.  
4. COLOR Red
5. PRINT "Hello World"

It needs one, or the other, to work properly.  As it is, it's just creating a value too large for the screen to know how to handle it.

[TempodiBasic]

Thanks Steve
I must remark that also this is ambiguous

colorIndex~& = _RGB(red&, green&, blue&[, imageHandle&])

If the imageHandle& is omitted the image is assumed to be the current destination or SCREEN page

at wikipage http://qb64.org/wiki/RGB
in the manner that ImageHandle& is a LONG variable to point to an handle of an image (Destination or Screen in use) while as you learn me about _RGB(Red&,Green&,Blue&, ScreenMode%)  where ScreenMode is one legacy Qbasic SCREEN mode (0-13) or 256 or 32bit Screen made by _NewImage(width%,Height%,256/32)
OR
here it lacks of another parameter if [,imageHandle&] has its own goal.

Thanks to read