In regards to variable types:
_BIT should *only* be used when you’re dealing with a large array for bit packing. If you don’t know what that is, or why you’d use it, ignore that _BIT even exists. It’s slow, has overhead, and will only be a detriment in your programs performance. If you’re really serious to learn about it, start another topic and I’ll write you a book on it. Otherwise, just remember: Unless you’re bit packing an array, DON’T worry with using _BIT. Use _BYTE instead.
When dealing with RGBA color values, either use _UNSIGNED LONG, or _INTEGER64 to store those values. SINGLE is the default variable type for QB64, but it’s not capable of holding all the values in a 32-bit color palette. LONG *may* seem to work for you, but you’re playing with fire if you do.
_RGBA is &HFFFFFFFF.
&HFFFFFFFF in signed long values is: -2,147,483,648
&HFFFFFFFF in unsigned long values is: 4,294,967,295
Both a LONG and an UNSIGNED LONG will hold those 4 bytes for RGBA color values, but if you mix the types and compare them, they give vast different results.
-2,147,483,648 and 4,294,967,295 both in HEX are represented as FFFFFFFF, depending on whether you have a signed, or unsigned variable type. The difference for COLOR is nothing at all, but for an IF statement, those two values are vastly different. Since POINT and other QB64 commands return those 4-bytes as an UNSIGNED LONG, it’s best if you default to using unsigned longs as well.
A quick demo is here:
SCREEN _NEWIMAGE(640, 480, 32)
DIM L AS LONG, U AS _UNSIGNED LONG
L = _RGB32(255, 255, 255)
U = _RGB32(255, 255, 255)
PSET (0,0), L
PSET (1,1), U
IF POINT(0,0) = L THEN PRINT “POINT 0,0 is a match”
IF POINT(1,1) = U THEN PRINT “POINT 1,1 is a match”
Generally speaking, use of all LONGs (if possible) will perform faster on most modern systems than other types. They add faster, process faster, and are generally more efficient at a register level.
_BIT is a niche use type, and slow to use. Think of it basically as a ZIP file. Compressing a file saves disk space, but it harms performance as you have to unzip it to access its data before using it. That’s the exact same thing _BIT does. Generally, just forget it exists.
_BYTE and INTEGER both saves memory, if you only need values in that range, but they tend to be a little slower in processing than LONG. (At least, on my system, they almost always are.)
_INTEGER64 uses twice the memory as LONG, so unless you’re just dealing with super large values, ignore it.
SINGLE and DOUBLE, I tend to ignore, in most cases. _FLOAT uses a ton more memory, but it tends to process faster than the other real types. Since I’m generally only using real values in repetitive loops, and often in complex math operations, I tend to just use _FLOAT for the handful of real variables I need.
My general programming style is basically:
_DEFINE A-Z AS LONG
Color variables are dimmed as _UNSIGNED LONG
Math and fractional values are dimmed as _FLOAT
For anything else, I generally need to have a good reason to incorporate them into my programs.
