WELL...
BELIEVE ME IT WAS NOT EASY TO DETERMINE WHAT'S GOING ON!
But, I think I've solved it... by a means that really gave me some trouble.
[complaint mode on...]
What's happening here is that my screen is "FLASHING" bits and pieces of images saved in the video ram, meaning my Direct-X or hardware interface files have gotten messed up. I've tried re-installing but that hasn't worked yet, so I sort of had to live with the problem while I was working.
[complaint mode off...]
Anyway, here's the scoop -- the problem is in the READ WORD command. But it's not the command's fault -- it OUR fault, though I guess we could blame the command as if we wanted to. Here's what's happening;
When we write out a value to the level file it goes as RAW DATA, meaning it really is exactly two bytes. Trouble is, when we read the data the same is the case, but the read command doesn't like byte data so it tries to make the value into a number. In order to this, it makes the two bytes into a LONG number, meaning that a -1 for examples back with the value of 65535!
This means that although all the cubes are listed properly, their positions are all messed and way, way off screen. So, I propose trying this;
read word 1, i
if i > 32767 then i = i - 65536
xpos(n) = i
do that for each statement. And as for why you were getting a straight line of the blocks, those values were being saved correctly while the others were not. And you also forget a position command in the load;
if objs(n)
make object cube objs(n),64
position object objs(n), xpos(n), ypos(n), 0
endif
So try making these changes and see if that clears it all up.
ttfn, I'll keep playing with it too...
S.
Any truly great code should be indisguishable from magic.