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
