Collision Detection

[keybone]

The & is for long integer type best used with _RGB32 color variables, use && if want alpha too ie _RBGA32().

Actually, you could use ~& or _UNSIGNED LONG to get _RGBA32 too, will probably save a bit of memory.

[FellippeHeitor]

Yeah, there's definitely no need for _INTEGER64 (&&) to store colors, even with transparency. Long (or unsigned long) is more than enough.

[SMcNeill]

Yeah, there's definitely no need for _INTEGER64 (&&) to store colors, even with transparency. Long (or unsigned long) is more than enough.

Personally, I advocate *ALWAYS* using _UNSIGNED LONG for color values.  The reason should be apparent in the little code snippet below:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(800, 600, 32)
2. PSET (0, 0), -1 'bright white (_RGB32(255,255,255))
3.  
4. DIM k AS LONG, k1 AS _UNSIGNED LONG
5. PRINT POINT(0, 0) 'How QB64 reports it naturally
6. k = POINT(0, 0) 'what we'd store it as, if we store it as a LONG
7. k1 = POINT(0, 0) 'how we'd store that value as UNSIGNED LONG
8. PRINT k, k1 'print to illustrate the different values
9.  
10. IF k = POINT(0, 0) THEN PRINT "LONG TRUE" ELSE PRINT "LONG FALSE" 'and how they change behavior with IF
11. IF k1 = POINT(0, 0) THEN PRINT "UNSIGNED LONG TRUE" ELSE PRINT "UNSIGNED LONG FALSE"

If you're going to use POINT at all in your code, make certain you compare its values against UNSIGNED LONG values.  Otherwise, you're going to end up with a lot of false results which are going to make your program harder than heck to debug and work properly in the future.

[keybone]

Personally, I advocate *ALWAYS* using _UNSIGNED LONG for color values.

I agree 100%, no point in wasting space and potentially causing errors at the same time.

Maybe that guy either didnt realize about _UNSIGNED or he didnt realize that the number

signing was the only thing stopping the color value from fitting in a LONG variable.