02-10-2010, 07:09 PM
Yes indeed! That's why I wanted to bring that one particularly to your attention.
I can work around it by always using < instead and swapping the variables of course. But it took me ages to realize that was the bug, and I had to do quite a bit of testing to get there.
(I'm sort of being proud of myself for isolating that). If you try the test program I listed with 1.23 and 1.24 both have the problem. I think not many people have been working with the fixed type - but I decided to try floating point screen pixels for added accuracy.
Though given the low resolution of the spectrum, I sorta wish there was a faster, smaller 16 bit float that could do +/- 255 (or even 511 to allow for overflow off screen). Even if it only had 4 bits of floating point (and thus was accurate to about 0.125) it would be ideal for screen work. I suppose I can emulate it by working with an integer and multiplying up co-ordinates for internal storage though.
Anyway, back to the original point: Yes, this bug could trip someone badly! Thank you for looking into it.
I also have some suspicions about AND and OR not working quite right. Not sure if that was to do with my corrupted compiler or not - I haven't done a definitive test since reinstalling.
The compiler is becoming very useful actually. I'm getting into medium sized programs now, and it's holding together very well. And for the most part, it seems to be producing fast code. Thankyou for building it!
I can work around it by always using < instead and swapping the variables of course. But it took me ages to realize that was the bug, and I had to do quite a bit of testing to get there.
(I'm sort of being proud of myself for isolating that). If you try the test program I listed with 1.23 and 1.24 both have the problem. I think not many people have been working with the fixed type - but I decided to try floating point screen pixels for added accuracy.
Though given the low resolution of the spectrum, I sorta wish there was a faster, smaller 16 bit float that could do +/- 255 (or even 511 to allow for overflow off screen). Even if it only had 4 bits of floating point (and thus was accurate to about 0.125) it would be ideal for screen work. I suppose I can emulate it by working with an integer and multiplying up co-ordinates for internal storage though.
Anyway, back to the original point: Yes, this bug could trip someone badly! Thank you for looking into it.
I also have some suspicions about AND and OR not working quite right. Not sure if that was to do with my corrupted compiler or not - I haven't done a definitive test since reinstalling.
The compiler is becoming very useful actually. I'm getting into medium sized programs now, and it's holding together very well. And for the most part, it seems to be producing fast code. Thankyou for building it!