2020-06-01


Making some decent progress. NextBASIC is always going to be slower (much) than assembly, so I’m trying to look carefully at the code path to see what optimisations I can do.

I did however manage to get the mummy’s to bounce off each other, but good lord making that anywhere near usable was a massive pain in the arse.

I originally went with a sprite collision function, but the point that the mummy’s have collided is too late to turn around - so they just ended up overlapping then bouncing back and forth like some crazed yellow blobs.

In the end I track the position of the mummy’s in a BANK (effectively 16K of swappable RAM), and in each movement, I check the position I’m about to move to for another baddie, and if there is, flip my direction and bail the function.

If not, I remove the current position and update with it’s new position. Originally I wrote this code as a group of functions (as I would do normally), reducing the amount of code reuse which made everything readable. This is a snippet:

#autoline 10
DEFPROC getIndexForXY(%x,%y)
ENDPROC =%(32*(y/8))+(x/8)
;
DEFPROC getBaddieBankIndex(%i)
  LOCAL %j
  PROC getIndexForXY(%A[i*6],%A[(i*6)+1]) TO %j
ENDPROC =%j
;
DEFPROC clearBaddie(%a)
  BANK %e POKE %(32*(A[(b)+1]/8))+(A[b]/8),%0
ENDPROC
;
DEFPROC setBaddie(%a)
  BANK %e POKE %(32*(A[(b)+1]/8))+(A[b]/8),%b
ENDPROC
;
DEFPROC setBaddieInBank(%a,%b)
  LOCAL %j
  PROC getBaddieBankIndex(%a) TO %j
  BANK %e POKE %j,%b
ENDPROC

But good lord did that hose the performance - the mummy’s were going through sludge.

In the end I inlined every call, which is horrid to look at, but the performance went right back up again. The lesson: no functions.

…which makes me thing I need some kind of compiler to inline everything, but that might be for another day.

I also got the tomb open visuals working, and next need to add the graphics for the scroll, pharaoh, key and treasure:

One growing concern is that the game is playable with 3 baddies, but at 9 (which isn’t a stretch to have going on in the original game), it gets very clunky, and I’m wondering if I can optimise the code further by throwing away the mummy array (that holds each mummy data) and move to first class variables for each iteration, ie. %x becomes the mummy’s x position - and I back the data into memory using PEEK and POKE.

It would reduce the number of array lookups and would reduce/remove a lot of maths that goes on during the mummy logic.

It’s just a rather large change…and a headache.

Get Go Mummy! (ZX Spectrum Next)

Download NowName your own price

Leave a comment

Log in with itch.io to leave a comment.