Why was Manic Miner never properly optimised?

[ParadigmShifter]

Crucial point is that I do a HALT and then immediately start erasing and drawing everything (to beat the raster - hopefully - I can make it flicker a tiny bit if I give it a really bad case for the solar power beam at the moment but I have some speedups for the beam drawing up my sleeve still).

Once everything is drawn I work out what needs to be erased next frame, I set up all the guardian screen addresses of where they are now at, I work out the path of the solar beam for the next frame, etc.).

It's generally a bad idea (I know it is the simple and obvious way of doing things though, and I made this mistake in my 2010 version) to do it the other way around, which would be

get player input etc.

update and move everything

draw everything

 

You can get away with that if you use a double buffer of course. That wastes a lot of memory and as well as drawing to the offscreen buffer (which can be in noncontended RAM, so that's a bonus), you then have to copy it to contended RAM (preferably immediately after the HALT if you have interrupts enabled.

In my 2010 version I did use a backbuffer and I had a "dirty list" of cells I had to redraw so it only redraw those, which made the drawing fast. Maintaining the dirty list was a pain though so I soon got rid of that idea in my later stuff.

(Of which only one has been released, and it's not great (speedwise and codewise) either, it was while trying to improve it someone decided to draw an 8 frame anim for Willy which started me to rewrite my engine again).

It's not a bad game if you like scrabble and columns though (I don't like the occasional attribute flicker you get though)

https://spectrumcomputing.co.uk/entry/42215/ZX-Spectrum/SJOE

It's like columns but you have to make valid (in Scrabble) 4 letter words (and only 4 letter words count! Hence all words displayed on screen in the UI and the starting names in the high score are all valid 4 letter words (they are random words from the list for the high score names)) 🙂

The entire SOWPODS list of 4 letter words is present and correct (can't remember how many, think it's 5000 odd). You can get a list of them by pressing L from the main menu.

Don't turn on CUSS mode if you are easily offended by scoring points for words 🙂

Edited August 1 by ParadigmShifter

[ParadigmShifter]

You can update and then move if you do the wait for VBlank just before you start drawing as well of course. You may have to jump into the mainloop on the first frame then to avoid updating enemies on the first frame (original Manic Miner may do that - update guardian positions before it draws them for the first time anyway?)

I know Matthew Smith just turned interrupts off and there is no HALT to sync with the raster in his code. That causes tearing and/or flicker if you do that though.

I just do the draw first and I start with empty erase lists so it erases nothing it just draws the guardians without erasing anything. (It will redraw any cells Willy is standing in front of when doing the Willy erase though).

 

The code is now public on Github anyway if you want to read it (or build it yourself - requires sjasmplus)

https://github.com/ParadigmShifterRetro/SlickWilly

Edited August 3 by ParadigmShifter

[Spider]

I did remove (merely out of curiosity) two halt instructions I noted and the speed was insane however that was not the point , I wanted to see it like that, then I put them back. 🙂 

[ParadigmShifter]

In my code you mean? There's only 1 HALT in the mainloop.

There's another halt just before I set the correct attributes for a level to try and avoid a bit of flicker when showing a level for the first time but I don't think it's 100% effective, maybe if I have 512 bytes to spare at that point I could work out the attributes (rather than having to go from collision tile to attribute value via a lookup table) to set them faster.

There's also 2 HALT to delay the colour cycling of the Demo Over message.

The Game Over sequence does drop a frame unfortunately (you can see the foot speed up a bit at the end when it starts not dropping a frame), but it's nowhere near as flickery/teary as the original version.

 

It's generally a bad idea to remove HALT instructions if your game runs faster than 50fps 😉 It looks quite cool though. That was first thing I tried on day 1 of my first job (working on a PS1 game), I saw "WaitVBlank();" in the first example code I compiled and thought hmm waiting sounds bad what happens if I take it out? It was very very fast indeed then and left trails across the screen lol 😉

Edited August 4 by ParadigmShifter