QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: Cobalt on June 26, 2021, 11:46:01 am
-
Ok I think I know what is going on here but I just wanted more input on this,
Is this how SELECT\CASE in QB64 is supposed to handle this?
TEST = &HFF
'TEST = &H80
'TEST = &H40
'TEST = &H08
'TEST = &H01
CASE &HFF 'flaged conversations CASE &H01 'standard dialog
C~%% = TEST
T%% = &HFF
Its not catching the first 2 CASE scenarios here. least not on my side, V1.5 stable
I think it may treating the &H as an unsigned value?(&H80 and up sets bit 7 which makes it a negative in a signed scenario)
should it be treating the values differently? if you assign TEST to an unsigned variable it doesn't change it, the BITs are still set properly so why isn't SELECT\CASE matching it? if you put &HFF into a signed variable it becomes -1.
From my perspective &HFF is both -1 and 255 based on the SELECT variable used; SIGNED or UNSIGNED.
Its an easy fix of adding _UNSIGNED to my UDT in the actual code, but I just wanted to make sure the SELECT\CASE was behaving properly, which I think it might be but I'd rather have input from others on that one to make sure.
-
I'd just make TEST an unsigned byte because when you are doing the case, &HFF is going to be pointing to 255 while your variable will be overflowed and not match the value. That's my guess
-
TEST = &HFF
'TEST = &H80
'TEST = &H40
'TEST = &H08
'TEST = &H01
Case &HFF%%
'flaged conversations Case &H01%%
'standard dialog
Assign the variable type to your &H-math manually, like I've done above, and QB64 won't have to guess at what that value is supposed to be.
-
I'd just make TEST an unsigned byte because when you are doing the case, &HFF is going to be pointing to 255 while your variable will be overflowed and not match the value. That's my guess
Yeah, I mean that is what I ended up doing. QB64 defaults to LONG with undefined variables and constants or SINGLEs? so &HFF is probably being treated as a LONG or SINGLE even though the comparison variable is BYTE. I'd almost think it would want to match the CASE type with the SELECT type.
In terms of BITs they are identical,at BYTE width, &HFF = 11111111, -1=11111111, and 255=11111111. So in a bit-wise comparison they should always be =.
Been doing a lot of BIT work in my game lately, so probably why I was taken aback by this.
Assign the variable type to your &H-math manually, like I've done above, and QB64 won't have to guess at what that value is supposed to be.
Oh yeah, I forgot about that. Been a long time since I have used that method.
✅Thanks for the feedback guys.✅
-
I looks like the way CASE is interpreting &HFF
TEST = &HFF
'TEST = &H80
'TEST = &H40
'TEST = &H08
'TEST = &H01
CASE -1 'flaged conversations CASE &H01%%
'standard dialog