You're quite right — some hasty testing in Sim Coupe reveals that it
is much slower. I was imagining that POINT might go through some
arcane paths with all the xos/yos/xrg/yrg stuff.
If you have the memory to spare, could you maybe skip over the problem
by allocating a new screen that is never shown to the player, then in
advance (maybe just after the level has been loaded?) plotting a
colour at each position that represents what should happen when the
ball is there? It'd mean you could cut yourself down to using a single
POINT.
On 18 Sep 2008, at 15:37, Geoff Winkless wrote:
On Thu, 18 Sep 2008 13:26:15 +0100, "Thomas Harte"
<[EMAIL PROTECTED]> wrote:
Maybe something like the following to get the colour of the pixel
at (x,
y):
10 LET A=IN 252 BAND 31
20 LET BASE=(A+1)*16384
30 LET ADDR = BASE + (x/2) + y*128
40 LET BYTE = PEEK(ADDR)
50 IF x BAND 1 THEN LET COL = BYTE/16 ELSE LET COL = BYTE BAND 15
I can't believe that would be any quicker (in fact I'd be amazed if
it's
not slower) than POINT().
The way to improve the speed in a generic way is to write machine
code that
checks the edges of a bitmap you pass it and tests the appropriate
points
on the screen.
The _fastest_ way is to write a specific set of checks based on the
sprite
and the direction of movement.
Basically, let's say you figure out that if you're moving upwards
you need
to test pixels 2 to 6 on line 0 and pixels 1 and 7 on line 1. Your
code for
"test-up" would therefore be
LD A, (IX+1) # pixels 2+3
OR A, (IX+2) # pixels 4+5
RET NZ
OR A, (IX+3) # pixels 6+7
INC I:IX (or whatever your assembler uses for that non-instruction)
OR A, (IX) # pixels 0+1 line 1
AND &0F # isolate rightmost pixels
RET NZ
OR A, (IX+3) # pixels 7+8 line 1
AND &f0 # isolate leftmost pixel
RET
IIRC if you call this with USR you get the value in A as the result
(or is
it BC? Can't remember), so you can just
IF USR(upcode)<>0 THEN GOTO HIT
There are ways of passing parameters to USR functions, I can't
remember how
though :( I'm also not sure if using IX is better than INCing H and L
(probably not)
The problem with POINT (or similar) is that it has to completely
recalculate the positions in memory for every check. That's slowed
down
even further because each time it has to access the values from
BASIC's
variable stack which (since it's all floating-point and they're
stored in a
non-optimal way) is ridiculously slow (it's a shame Andy Wright
didn't see
fit to add integer variables like you get in BBC Basic, for example)
Geoff
