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)
Go Mummy! (ZX Spectrum Next)
ZX Spectrum Next clone/reimagination/upgrade of Amsoft's Oh Mummy from the CPC 464
Status | Released |
Author | rem |
Genre | Survival |
Tags | nextbasic, Retro, specnext, spectrum-next, zx-next, zxnext, ZX Spectrum, zx-spectrum-next |
More posts
- Fin - 2020-08-25Aug 25, 2020
- 2020-08-09Aug 09, 2020
- 2020-07-28Jul 28, 2020
- 2020-07-20Jul 20, 2020
- 2020-07-07Jul 07, 2020
- 2020-06-25Jun 29, 2020
- 2020-06-15Jun 15, 2020
- 2020-06-07Jun 08, 2020
- 2020-06-03Jun 08, 2020
Leave a comment
Log in with itch.io to leave a comment.