Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: Raven_Singularity on April 27, 2019, 11:21:26 pm

Title: _RGBA inconsistencies (explained)
Post by: Raven_Singularity on April 27, 2019, 11:21:26 pm
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?
Title: Re: _RGBA inconsistencies (possible bug)
Post by: FellippeHeitor on April 27, 2019, 11:23:04 pm
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)
Title: Re: _RGBA inconsistencies (possible bug)
Post by: FellippeHeitor on April 27, 2019, 11:24:16 pm
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).
Title: Re: _RGBA inconsistencies (possible bug)
Post by: Raven_Singularity on April 27, 2019, 11:25:33 pm
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.
Title: Re: _RGBA inconsistencies (possible bug)
Post by: RhoSigma on April 27, 2019, 11:28:20 pm
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 :(
Title: Re: _RGBA inconsistencies (possible bug)
Post by: FellippeHeitor on April 27, 2019, 11:29:10 pm
Quote from: Raven_Singularity on April 27, 2019, 11:25:33 pm
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.
Title: Re: _RGBA inconsistencies (possible bug)
Post by: FellippeHeitor on April 27, 2019, 11:32:01 pm
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)
Title: Re: _RGBA inconsistencies (possible bug)
Post by: FellippeHeitor on April 27, 2019, 11:40:59 pm
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.
Title: Re: _RGBA inconsistencies (possible bug)
Post by: Raven_Singularity on April 27, 2019, 11:48:10 pm
Quote from: FellippeHeitor on April 27, 2019, 11:29:10 pm
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.



Quote from: FellippeHeitor on April 27, 2019, 11:32:01 pm
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).



Quote from: FellippeHeitor on April 27, 2019, 11:40:59 pm
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&"?

Quote from: Wiki
colorIndex~& = _RGBA(red&, green&, blue&, alpha&[, imageHandle&])
Title: Re: _RGBA inconsistencies (possible bug)
Post by: FellippeHeitor on April 27, 2019, 11:50:35 pm
Quote from: Raven_Singularity on April 27, 2019, 11:48:10 pm
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.
Title: Re: _RGBA inconsistencies (possible bug)
Post by: Raven_Singularity on April 27, 2019, 11:55:47 pm
Quote from: FellippeHeitor on April 27, 2019, 11:50:35 pm
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.  :-)



Quote from: RhoSigma on April 27, 2019, 11:28:20 pm
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
Title: Re: _RGBA inconsistencies (possible bug)
Post by: SMcNeill on April 28, 2019, 12:54:17 am
Quote from: FellippeHeitor on April 27, 2019, 11:50:35 pm
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.  ;)
Title: Re: _RGBA inconsistencies (explained)
Post by: SMcNeill on April 28, 2019, 12:55:54 am
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.
Title: Re: _RGBA inconsistencies (explained)
Post by: Raven_Singularity on April 28, 2019, 09:10:13 am
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!
Title: Re: _RGBA inconsistencies (explained)
Post by: FellippeHeitor on April 28, 2019, 09:33:06 am
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.  
Text Only | Text with Attachments