Closed mzattera closed 3 months ago
Hi @mzattera and thank you for your bug report!
Yes, you are right: your single example found two bugs.
The first one was that expressions related to IF
were not converted as signed bytes. This means that even if they returned a value of TRUE
(-1
), they were implicitly converted to 255
instead of -1
. So expressions like ... = TRUE
would never work. Those with the omission, however, would (because -1
and 255
are both "non-zero").
The second one had to do with the conversion from BIT
to SIGNED BYTE
which, evidently, did not work. This also explained why you were getting that erratic behavior.
The bug was fixed in COLDFIX v1.16.3 [rev. 20240805].
Then, I would like to compliment you on the choice of adding a _
prefix to the constants. In fact, the need to adapt the language for 10-liner competitions while still leaving it "non-contextual" had forced me to the rule of variables and constants that began with a lowercase character (because the commands are in uppercase). The choice of using the _
character, which is valid but is not an alphabetic character and above all is not used by any command, seems like a really fantastic idea to me!
That said, I would like to suggest a series of small improvements to the code. I don't know if it's real code, but the suggestions are valid anyway. :)
OPTION DEFAULT TYPE BYTE
DEFINE DEFAULT TYPE BYTE
The first one is an alias for the second one, so one is enough.
DIM _BIT_CAUGHT AS BIT: _BIT_CAUGHT=FALSE
In BASIC, variables are always initialized to zero, unless otherwise initialized.
So, actually, the =FALSE
assignment is redundant, since FALSE is 0.
IF SCANCODE==_KEY_FORWARD THEN
Even though I left the ==
operator for comparisons, the standard BASIC operator is =
: the compiler knows when a =
is used for comparison or assignment, depending on the context.
playerDir = playerDir MOD 4
The MOD
operation involves a division operation, which is usually expensive in terms of the amount of code generated and the speed of execution. Since the operation is to ensure that playerDir
is in the range [0...3]
, that is a power of two minus one, it is better to use the bitwise AND
operator with a bitmask of 3
. This bitmask guarantees that the value is between 0 and 3. In other words, I would write:
playerDir = playerDir AND 3
Thank you again!
Verified fixed :-)
Also, thanks A LOT for the suggestions. ugBASIC is so feature rich that I am sure I am missing a lot of ways to write better code.
I have a couple questions about variable types stemming from:
OPTION DEFAULT TYPE BYTE
DEFINE DEFAULT TYPE BYTE
but I-'ll check documentation and forum first.
In the below program (at least when compiled for Dragon target) these two lines of code behaves differently.
From what I understood of ugBASIC syntax they should be the same though.
(Apologies for the long code below, but I could not replicate it with shorter code, for some reason)