RetroRaider on the Amiga kept me awake for most of the night.

-=-=-

The background of a screen takes about a second (more like 1.5 seconds) to redraw, no matter how I try to optimise it.
I'm not comfortable releasing a game that takes THAT long to redraw, especially when it would instantly be compared to Pitfall on the Atari 2600, which takes .. roughly 1 frame to do the very same thing!
Of course, once the screen is drawn, there's still even more to draw. All the onscreen sprites need to be organised, too, and .. I think I can only draw about 5 sprites without slowdown..?
Gosh, this is so much harder than I thought it was going to be.

So, I lay awake until about 2 in the morning, trying to fathom more optimised ways to do it.

First off, instead of trying to draw all of those pixels in realtime, I wonder how much memory it'd take to pre-render them and hold them in offscreen buffers?
Traditionally there are 5 backgrounds that the game uses.. The trees, the dirt under it, the cavern under that, the egyptian sandy coloured room, and the stone room.

Having all of those pre-rendered in offscreen bitmaps would mean I could simply reuse them and switch them in and out. I think that would work..!? Maybe!

Blitz lets you store up to 10 background bitmaps, and since each one is less than half a screen's height (though is double the width..) it shouldn't be "too" taxing to swap them whenever necessary, assuming I can figure out a way to split the screen whilst still allowing the sprites to jump about.

I'll likely have to redraw them all to share the same palette. I'm not sure Blitz can toggle palettes between slices. Though I've not investigated that yet

As for the sprites.. Again, only having about 4 or 5 sprites to play with could be an issue. The gun's fire rate will need to be locked to only 1 bullet onscreen at once, which then means reducing how many bullets it takes to kill baddies.

Yep, lots to consider.
Will I manage?
Who knows..
Stay tuned to find out!