Castle of Doom buggy after compilation about basicv2 HOT 4 CLOSED

Especially how the interpreter deals with DATAs in some edge cases is really strange and not what one would expect.
BTW: The distribution contains a bunch of BASIC games in the same style as your example. You can find them in https://github.com/EgonOlsen71/basicv2/tree/master/src/test/resources/games. The ones with a _15000 in the name need to be compiled using the /progstart=15000 parameter. All of them should be compiled using the /compactlevel=4 parameter to keep the code more...well, compact.

from basicv2.

There are two issues with this...one is obvious, the other one quite funny actually. The obvious problem is, that the compiled code reaches into memory locations that the game needs for it's graphics. That can be fixed by using one of the available options to relocate the compiled code. But that still doesn't help much, because the code uses data statements in a strange way. It stores large strings in them, but it doesn't qualify them as strings by using quotes. That's fine with the interpreter because it can dynamically decide which data type to use based on the read command's variable. A compiler has to know the type beforehand. In this case, my data parser sees the numbers and thinks of them as floating point numbers. But they are so large that it actually fails to parse them as such and returns 'Infinity' instead. And that's what it stores in the generated assembly listing and that doesn't work, of course. I'll look into it...

from basicv2.

Should be fixed with the latest checkin. You still have to make sure to compile in a way that the code doesn't interfere with the graphics. One way of doing that is by using the newly added memhole-parameter like so:

mospeed castle.prg -memhole=12200-13000

from basicv2.

I love the huge amount of quirks in this BASIC :-) Thanks, it's working now! Well, it is unplayable but that can be fixed :-)

from basicv2.