2020-08-09

The last series of work has been play testing, trying to catalogue and fix bugs and adding polish the game where possible.

I’ve been wanting to bring a bit more visual interest to the screens I had though I’m limited in the game itself, the main options screen could do with some love.

The screen initially I’d picked Papyrus, albeit at random for it’s oldworldly feel and the screen looked like this:

But I wanted something that harked back a little to the original game roots and give it a bit of an Egyptian feel (or certainly what I imagine that would feel like).

I ran through a number iterations until I found a font and some border images that started to bring it together:

The first was a little too streetwise and the second looked like it would suit a shooting game of some sort. I liked the third, but the fourth felt a little more dynamic which is how I think of the game - a bit frantic.

To get this to load into NextBASIC, I have three options:

1. I can export as an 8-bit BMP and load on the machine using .bmpload - which is probably fine, but has a little more latency that I’d like.
2. I can convert the file first to an BMP and then to an SL2 file - which is a pure dump of the screen layer. Then easily loaded back in using LAYER 2,1: LOAD "screen.sl2" LAYER. This is quick (there’s no calculation to be done as it represents a memory dump) but it does read of the SD card. This would be fine if I was showing this screen once, but I show it many times, particularly through the option screens.
3. Generate the SL2 file, and load individual thirds into banks - this is the method I used since the data is loaded in memory for quick copying back into the screen memory.

I made another online tool that lets me upload any file format, and so long as it’s 256x192 (or not wider than 256) then my code will translate the data to both an 8-bit BMP (with the default Spectrum Next palette) and an SL2 file (which is very similar to a BMP, just ordered slightly differently).

Once I have the SL2 file, I need to break it into 3 equal parts of 16K (the size of a memory bank) and for the final touch, the last third of the screen is solid black for 16 lines - which I can do at the same time.

A unix tool called dd can be used to split the file up:

$ dd if=screen.sl2 of=screen1.bin bs=16k count=1 skip=0
$ dd if=screen.sl2 of=screen2.bin bs=16k count=1 skip=1
$ dd if=screen.sl2 of=screen3.bin bs=16k count=1 skip=2

This will create 3 files of 16K blocks each (based on screen.sl2).

The final task is to block out the last 16 lines in black pixels - 0x00 which conveniently is what comes out of /dev/zero, so I can source that stream and use dd to write it into the screen3.bin file:

$ dd if=/dev/zero bs=4k count=1 oseek=3 of=screen3.bin

Now the binary files can be reploaded into banks then loaded into the LAYER on demand:

LOAD "screen1.bin" BANK 20
LOAD "screen1.bin" BANK 21
LOAD "screen1.bin" BANK 22
; later in the code
BANK 20 COPY TO 9   ; bank 9 is the start of LAYER 2
BANK 21 COPY TO 10
BANK 22 COPY TO 11

So the state of play on Sunday 9 August is that all the (known) bugs are fixed, the new music and sound effects are in place, high scores are updating and saving. I’m investigating a couple of performance tweaks (that aren’t required, but will be nice if I can it off) which leaves me with one last problem to solve.

Do I keep the name “Oh Mummy!”? There’s other clones of Amsoft’s Oh Mummy, some have a different name, some reuse the name, but there is a question over copyright. I’d hope that copyright holders would see this as a hat-tip to old but it bears considering.

So, so far there’s some ideas:

• Mummy Mummy!
• Return of Oh Mummy!
• Oh Daddy!
• Go Mummy!
• (and) Oh Remmmy!

Although the last one is rather self serving, I quite like it - just trying to work out how it fits in the story line… (I also prefer titles that are approximately the same length as the original).

So close…