_RGBA inconsistencies (explained)

[Raven_Singularity]

I am trying to create a bunch of constants for common _RGBA colour values, and would prefer that my code remains easily readable like this:

Code: QB64: [Select]

1. CONST C_Black = _RGBA(0, 0, 0, 255)
2. CONST C_White = _RGBA(255, 255, 255, 255)

Rather than looking unreadable like this:

Code: QB64: [Select]

1. CONST C_Black = 4278190080
2. CONST C_White = 4294967295

However, when I have tried using _RGBA before my application is in graphical mode, it doesn't return the RGBA value, instead matching the closest palette entry (in this case, 0 and 15).  After this, I tried entering graphical mode before setting the constants, and discovered that _RGBA has highly inconsistently behaviour:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 360, 32)
2.  
3. CONST First_Method = _RGBA(255, 255, 255, 255)
4. PRINT First_Method
5.  
6. Second_Method& = _RGBA(255, 255, 255, 255)
7. PRINT Second_Method&
8.  
9. ' Third method
10. PRINT _RGBA(255, 255, 255, 255)

Expected results:

Code: QB64: [Select]

1. 4294967295
2. 4294967295
3. 4294967295

Actual results:

Code: QB64: [Select]

1. 15
2. -1
3. 4294967295

What am I missing?  Or is this really buggy?

[FellippeHeitor]

Since _RGB32 now supports a fourth parameter for alpha, use it instead:

Code: QB64: [Select]

1. CONST C_Black = _RGB32(0, 0, 0, 255)
2. CONST C_White = _RGB32(255, 255, 255, 255)

[FellippeHeitor]

BTW: _RGB and _RGBA work according to the screen mode currently active. To make sure you'll get 32bit values, always use _RGBA32 and _RGB32 (starting with v1.3, all you need is _RGB32).

[Raven_Singularity]

Thanks.  I actually thought I was using _RGBA32, that's what I use everywhere else in my code.

But can you explain the totally inconsistent behaviour I posted?

I am in 32bit graphical mode and I am getting 3 different values for the same _RGBA() statement, including -1 which is not a valid colour number in any text or graphical mode.

[RhoSigma]

You must use _RGBA32 for this purpose, not _RGBA which works different. There is also a color library available by forum member Steve. If i remember right it was called ColorAllLibrary.

Ok - was to slow :(

[FellippeHeitor]

Thanks.  I actually thought I was using _RGBA32, that's what I use everywhere else in my code.

But can you explain the totally inconsistent behaviour I posted?

I am in 32bit graphical mode and I am getting 3 different values for the same _RGBA() statement, including -1 which is not a valid colour number in any text or graphical mode.

When you use _RGBA to set a CONST you are actually pre-calculating the color value at compile time (CONST values are always stored as constants). Because of that, you get wrong values. _RGB32 has been modified to work differently. Next version of QB64 may bring the _RGBA fix, *but* switching to _RGB32 will work even for CONSTs.

[FellippeHeitor]

One last note: _RGB32(255, 255, 255) is &HFFFFFFFF, which translates to -1 if you don't use an _UNSIGNED LONG instead of a signed LONG. It is therefore a valid color value in 32bit mode (you can even COLOR -1 for white if you want in 32bit mode)

[FellippeHeitor]

Ah, no fixing needed:

Code: QB64: [Select]

1. CONST C_Black = _RGBA(0, 0, 0, 255, 32)
2. CONST C_White = _RGBA(255, 255, 255, 255, 32)

Specify one last parameter to store the values for 32bit mode. _RGB32 doesn't require that.

[Raven_Singularity]

When you use _RGBA to set a CONST you are actually pre-calculating the color value at compile time (CONST values are always stored as constants). Because of that, you get wrong values.

Thank you, once again.  That makes a lot of sense.

One last note: _RGB32(255, 255, 255) is &HFFFFFFFF, which translates to -1 if you don't use an _UNSIGNED LONG instead of a signed LONG. It is therefore a valid color value in 32bit mode (you can even COLOR -1 if you want for white in 32bit mode)

So RGBA colour FFFFFFFF just happens to be the exact same size as the maximum for LONG variable type?

I guess not totally coincidental, being that computer data types are base 2, and each hex digit is 4bits long, and computer storage and most variable types use multiples of 8bits (1 byte of data for each "FF" in the RGBA).

Ah, no fixing needed:

Code: QB64: [Select]

1. CONST C_Black = _RGBA(0, 0, 0, 255, 32)
2. CONST C_White = _RGBA(255, 255, 255, 255, 32)

Specify one last parameter to store the values for 32bit mode. _RGB32 doesn't require that.

Hmmm... how does this one make sense when the help says it is taking an image handle, not "mode%|imageHandle&"?

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

[FellippeHeitor]

Hmmm... how does this one make sense when the help says it is taking an image handle, not "mode%|imageHandle&"?

The mode% syntax is exclusive for use with CONST. Undocumented indeed.

[Raven_Singularity]

The mode% syntax is exclusive for use with CONST. Indeed undocumented.

Thank you, one last time (for now)!


I will use the _RGBA32() statement with my constants, as it is very clear what the code is doing.  :-)

You must use _RGBA32 for this purpose, not _RGBA which works different. There is also a color library available by forum member Steve. If i remember right it was called ColorAllLibrary.

Ok - was to slow :(

Also, thank you as well, even if Speedy Gonzales answered before you.  :-P

[SMcNeill]

The mode% syntax is exclusive for use with CONST. Undocumented indeed.

Since CONST works as a precompiler, there’s no way for it to know what screen your program is using — nor should it.

workscreen = _NEWIMAGE(640,480,256)
displayscreen = _NEWIMAGE(640,480,32)
CONST Red = _RGBA(255, 255, 255)

With the above, what screen should CONST set a value for?  The workscreen, displayscree, or SCREEN 0, since there’s no actual screen set yet?

Since it’s a precompiler command, you can’t tell it to be something like CONST Red = _RGBA(255, 255, 255, workscreen).  workscreen is a variable and might change in a program; a CONST doesn’t.  So, when it comes to CONST values, you *can’t* assign an image handle; instead, you assign the screen mode value you want the CONST to represent.

CONST Red0 = _RGB(255, 255, 255, 0)
CONST Red256 = _RGB(255, 255, 255, 256)
CONST Red32 = _RGB(255, 255, 255, 32)

* note: I’m half asleep on my iPad; those are WHITE colors, but they work fine for illustration sake.

As you can see, that last value designates which screen mode we want to return our color value back for us.  ;)

[SMcNeill]

https://www.qb64.org/forum/index.php?topic=351.msg2346#msg2346 — link to my ColorAll library, in case you want to make use of it.

[Raven_Singularity]

I had no idea constants were set at compile time, I thought they were set like variables as encountered, so I figured the current SCREEN mode would be the determining factor.  I did notice that using certain functions to set constants didn't work, being compile time explains this as well.

Thanks all!

[FellippeHeitor]

It's interesting to see the difference between outputs:

Code: QB64: [Select]

1. CONST A = 5
2. B = A

The above will result in this C++ output:

Code: C++: [Select]

1. S_0:;
2. do{
3.     *__SINGLE_B= 5 ;
4. if(!qbevent)break;evnt(2);}while(r);
5. sub_end();
6. return;
7. }
8.  

Now if you use only variables, not constants:

Code: QB64: [Select]

1. A = 5
2. B = A

Here's the C++ output you'll get:

Code: C++: [Select]

1. S_0:;
2. do{
3.     *__SINGLE_A= 5 ;
4. if(!qbevent)break;evnt(1);}while(r);
5. do{
6.     *__SINGLE_B=*__SINGLE_A;
7. if(!qbevent)break;evnt(2);}while(r);
8. sub_end();
9. return;
10. }
11.