What's wrong with this? (Glitch in HEX$?)

[SMcNeill]

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 32)
2. CLS
3. PSET (0, 0), &H2CFFFFFF
4. PSET (1, 1), &H2CFFFFFF
5. PRINT HEX$(POINT(0, 0))
6. PRINT HEX$(POINT(1, 1))
7.  

Run the code above, and we get two different values for the colors of our two points.  One blends down to FF2C2C2C, the other claims to blend down to FF000000.  (Gray vs solid Black)

Even more odd, is if we try it like so:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 32)
2. CLS
3. PSET (0, 0), &H2CFFFFFF
4. PSET (1, 1), &H2CFFFFFF
5. PRINT HEX$(POINT(0, 0)), POINT(0, 0)
6. PRINT HEX$(POINT(1, 1)), POINT(1, 1)

Now we're printing the same as before, except our actual POINT levels are reporting that both are the same color (Gray), but the HEX$ values aren't.)

This seems like a glitch to me, but I was wondering if anyone else had any idea about what's actually going on here.  My guess, without digging into it deeply, is that we're overflowing values that HEX$ works with, much like using a SINGLE to store color values, rather than an unsigned long -- but I'm just making a guess at that, at the moment, based on past results with POINT...

Anyone with insight here, feel free to share it.

[SMcNeill]

AH HA!!

The glitch isn't in HEX$, it's another IBTK ERROR.  (Idiot Behind The Keyboard)

Of course the point isn't going to be the same when we read it....  We have a PRINT statement which changes what's on the screen right before it! 

/DUH!

[Pete]

What the HEX is wrong with you?!

Oh, I didn't know Clippy you had Clippy over... and why'd you let him behind your keyboard?

Pete :D