> The problem is that I don't know if it suffices to define only
> signed values. (Only unsigned values definitely won't...)
I think signed only is good enough. Why would a simple robot need
numbers bigger than 32767?
> (Which is quite a lot, come to think of it, maybe I should limit it
> to 14 bits/16kB)
I think that would be better. For people without JoyNet, more than 1
robot would have to run on a single MSX.
Also, if you store the stack(s) and the program itself outside of the
memory, a robot program will use more MSX memory than just the
internal memory of the virtual machine.
> Another possibility is to introduce a few registers (read/write), which set
> the stack ranges. In that case a user can define his own stack sizes and make
> efficient use of the available memory...
It is probably possible to merge the two stacks into a single stack.
In that case, there is no need to set the stack size, a smart
programmer would always leave it at the maximum size.
> >> But I suggest you don't put them in memory,
> >> in that case you only have to say something about their size.
>
> True. Any other arguments in favour of putting them outside memory, apart
> from the possibility to mess with the stacks?
Stack overflow is easier to detect.
> It's an example. The scanner ranges upto the borders of the playing field.
That long? Why would a scanner be able to scan up to the border of
the playing field, but only in 1 direction?
I think a limit range scanner is more fun (maybe even more useful).
> That's one sensible solution, another could be limiting the possibility
> of the SCAN command such that it can only scan north, south east and west
> and take the northwest etc out...
Sounds like a good idea. It's strange to allow diagonal scanning but
not diagonal moving or attacking.
> >> The ATCK command makes the robot attack another robot at a neighbouring
> >> square.
> >
> > What if there is no robot in that square? Is the empty square attacked or
> > is there no attack at all? Since attacking costs a turn, there is a
> > difference.
>
> IMHO, the empty square should be attacked, regardless of whether the square
> is actually occupied or not and it takes a turn. Question is whether you
> will lose energy attacking an empty square...
I think it should take energy.
> A similar argument holds for the MOVE command of course. What should happen
> if a robot wants to MOVE to an occupied square? IMHO, only the result of the
> MOVE should be ignored: energy is lost, turn is over, but you did not move.
Sounds good.
By the way, would any well-written program ever attempt such an action?
> Duh.. with your comments being right all the time, wouldn't it be easier if
> _you_ wrote the versions and _I_ be awaiting them? ;-D
It's much easier to spot flaws in other people's work than doing the
work yourself. ;)
Bye,
Maarten
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
