-So for each position on the screen that the ball can be, you make nine
-decisions (currently based on testing the result of nine POINT
-statement), each one to determine to whether the graphic below a
-certain pixel is either:
-
- transparent;
- solid; or
- deadly?
-
-Am I right to think that, taking an overview, you need to know whether
-each tested pixel is transparent or solid for bouncing, but only
-whether any of them at all is deadly? i.e. for the purposes of life or
-death, all you care about is whether any of the pixels at all is
-deadly, you don't care how many or which?
Yes, that's perfectly the situation :) Will need to use an 11th for bouncy
stuff, and could use a 12th to check another pixel above the ball which
would refine movement sometimes :)
-In that case you can say that when the ball is at position (x, y) then
-you care work out how to react from ten Boolean values. The first nine
-are whether or not there is something solid underneath the
-corresponding pixel. The tenth is whether any of the nine pixels are
-deadly.
-
-If you do any subsequent processing to reduce the amount of
-information (e.g. just deciding between 16 types of bounce and whether
-death results) then you can simplify things further. But I daren't
-assume.
I just check all the value's and push or bounce the ball away from them :)
-You can package the ten Booleans into 10 binary digits. In Mode 4,
-each pixel is represented in memory by 4 bits. So you can store the 10
-as 2.5 Sam pixels (so, practically speaking, 3). So you could loop
-through every pixel of your level before the player starts, work out
-the values of the ten values, combine them into 3 Sam pixels then plot
-them to screens that the player will never see. When the player is
-actually playing, do 3 POINTs based on the position of the centre of
-the ball to pull back the 3 pixels, then decode them to get the values
-you're actually interested in.
Now that I actually get this I like the idea, and it makes sense for the
'static' levels, will have to do new code for moving enemies, as they wouldn't
be picked up by the new checking as I was using the POINTS to also find them,
but without speeding the engine up I wouldn't be able to throw any in anyhow ;)
-
-For example (the exact syntax may be a bit scratchy, it's been quite a
-few years for me):
-
-10 LET PCOL = 0
-20 IF POINT(X, Y) > 0 THEN LET PCOL = PCOL+1
-30 IF POINT(X+1, Y) > 0 THEN LET PCOL = PCOL+2
-40 IF POINT(X-1, Y) > 0 THEN LET PCOL = PCOL+4
-50 IF POINT(X, Y-1) > 0 THEN LET PCOL = PCOL+8
-60 SCREEN : PLOT (X, Y, PCOL)
-
-then, later...
-
-70 SCREEN : LET PCOL = POINT(X, y)
-80 IF PCOL BAND 1 THEN PRINT "POINT (X,Y) is > 0"
-90 IF PCOL BAND 2 THEN PRINT "POINT (X+1,Y) is > 0"
-100 IF PCOL BAND 4 THEN PRINT "POINT (X-1,Y) is > 0"
-110 IF PCOL BAND 8 THEN PRINT "POINT (X,Y-1) is > 0"
-
-So, you at least reduce 9 POINTs to 3. Of course, there is only a
-benefit if BAND is cheaper than POINT, which it probably will be.
Thank you for providing example source code :D I will try and change the
game engine tomorrow and see how it works :) This could very well
be just the idea I was needing ;) (I took out just 4 of the POINT checks before
just to see the speed gain, and it was VERY noticeable :D )
I will have to keep the current engine for certain levels however, as
I want some of them to do full screen rotations (prerotating them
on PC, and flipping through screens on SAM), and these ones will need the
engine that checks the 'current' POINTs in real time.
Quite excited hoping I can grab some speed back once I've tried this, so thanks
again for your input !
Cal...
P.S. I put a video up on my YouTube page, but it hasn't gone live yet, will
post when it does !
