2020-07-07

This most recent round of development has been dedicated to squashing out bugs and investing in performance optimisations.

What’s particularly fun about NextBASIC is that it’s so close to the metal (as it were) - NextBASIC -> interpreter -> machine code - that it has a heavy hand in the code design that I work with.

I’m used to JavaScript which goes through part compile, part interpreted along with a lot of JIT’ting and hot path optimisation. No such pleasantries with NextBASIC.

A simple example is that in modern high level languages, I’d reduce my code reuse and refactor based on the rule that if a value or expression is used more than once, then it belongs in it’s own variable or routine.

Using that approach with NextBASIC comes at a cost, a cost that is immediately visible in the execution. Multiple routine calls slows down the runtime speed. Inlining code will always speed execution up (and this is also true of languages like JS).

There’s also the aspect of finding the absolute perfect fit of code for the problem - which again in JavaScript (or other languages) the perfect fit isn’t always necessary (and sometimes discouraged and it makes it harder to read later). But this approach makes me think carefully about how the system works at it’s lowest level.

A recent change is that I removed all the CLS calls from my game. This clears the screen. But the ROM routine does a lot more than “just clearing the screen”.

Instead, now I’m writing bytes directly to the screen memory which has a near instant effect and there’s no longer a wipe-and-wait delay:

; bank 9-11 is the thirds of the screen memory in layer 2
; bank 25 contains 1/3 of a screen header
BANK 25 COPY TO 9 :; "Oh Mummy header"
BANK 10 ERASE 252 :; Set the middle third to yellow
BANK 11 ERASE %0,%$3000,252 :; REM 0-0x3000 as yellow
BANK 11 ERASE %$3000,%$1000,0: ; last 4k is black

The bugs I’ve been squashing have been mostly been subtle issues that (hopefully) make the difference between “okay cool” and “oh, that’s odd”.

Here’s a fun bit of debugging to make sure the footsteps are positioned correctly:

The most recent fix I was most proud of is a control hack. If the player tries to move right, but there’s a wall in the way, it’ll continue moving in the direction they were previously facing until they’re free to move right. This hack means skimming around corners is much more natural - an invisible change to the player, but it felt sticky (or broken) when the player would be stuck hitting wall before a corner.

The outstanding tasks before the game is in a (first draft) complete state are:

• (required) Game over - Win state
• (required) Hi-score table
• (feat) Change colours of tombs between each level
• (feat) “Get outta there” / “now find the archaeologist” / “find that key!” marquee

Which doesn’t feel too far away!