Correct me if I'm wrong, but the variable Red must always be an UNSIGNED LONG (~&), otherwise you'll get the wrong value: _RGB32(r,g,b) will give values in the range 0 - 4,294,967,295.
QB64 tends to overflow values instead of tossing errors for us, so in *most* cases, you can use either signed or unsigned variables and still operate properly with FUNCTIONS/SUBS.
Try this:
DIM x AS _BYTE
DIM ux AS _UNSIGNED _BYTE
ux = 255
x = ux
PRINT x
In this case, ux is 255, so what is x?
It’s -128.
WHY?
Because in hex, *both* values are represented as FF.
**************
So how does this allow us to pass both signed and unsigned values to a FUNCTION and have it behave as intended?
SUB whatever (x AS _UNSIGNED _BYTE)
Let’s say the above is a SUB in my program, and I call it via the following line:
whatever -1
What value will x have inside the sub Whatever? We passed it a value of -1, but x is defined as an unsigned byte, so what value does it become?
255. (As we saw above, in reverse.)
***********************
So WHY can we use signed LONG values for *most* color functions?
Because of this overflow property.
White& = _RGB32(255, 255, 255)
What value does White become, in the above??
-1
But what happens when we use that -1 value to set COLOR?? Try it:
SCREEN _NEWIMAGE(640, 480, 32)
COLOR -1
PRINT “Hello World 2”
Run the above and you’ll see that the -1 overflowed to become bright white, since COLOR expects unsigned long values to be passed to it.
************************
In *most* cases, the difference in signed and unsigned doesn’t matter, when passing values to subs and functions.
“So when *does* it matter,” you ask?
When doing direct comparisons.
SCREEN _NEWIMAGE(640, 480, 32)
White& = -1
PSET (0, 0), White&
IF POINT(0, 0) = White& THEN
PRINT “You’ll never see this. It doesn’t.”
ELSE
PRINT “I told you so.”
END IF
With the above, White is a LONG variable, so its value is -1 (as we assigned it). The issue is POINT returns unsigned values to us, and -1 is *NOT* equal to 4325467898712 (Whatever the unsigned value actually is).
The only way to make the above work is to do one of two things:
1) Make White an unsigned long value, so it compares properly with our return function values.
OR
2) Never do direct comparisons, without assigning return function values to signed variables first, so they overflow properly as well.
P& = POINT(0, 0)
IF P& = White& THEN....
(The above would be true, since IF is comparing -1 to -1, for both variables.)
************************
So what do *I* recommend to do??
Always use unsigned variable types for color values.So, why did I use a signed Long in my previous post??
Just because that’s what the original poster used in defining his variables.
Personally, I think all color variable types should be unsigned, to prevent issues like with the POINT comparisons, but one can work around those limitations if they choose to. Since I was responding to someone’s question, I tried to answer using the same style as their original post — even if it’s not my preferred method. 😉
