Automated generation of Manic Miner speedrun/walkthrough

[Norman Sword]

Quantum Tunnelling

Willy passes through objects.

 

[IRF]

7 minutes ago, Norman Sword said:

Quantum Tunnelling

Willy passes through objects.

Wrong analogy.  The green thing is clearly a vaccine needle, jabbing Willy to give him immunity from the cyan-blue Covid virus located behind him.

Edited March 25, 2021 by IRF

[Spider]

15 hours ago, Norman Sword said:

I also included a full screen Second title page.  Which is displayed  after the boot. 


This is what the current 2nd Title picture looks like.
 

That's excellent Norman 🙂 🙂

12 hours ago, IRF said:

(Incidentally, the SP version of Processing Plant also has different graphics for some of the Fire cells [and item shapes], but those shouldn't have any impact on the maximum possible score since the collisions with Fire cells are attribute-based rather than pixel-based.)

Well spotted! , It is something that is overlooked. Don't forget the items too 😉

Pic attached:

[IRF]

Those items are bunches of grapes, I believe, to fit in with the Pac-Man theme.

[Spider]

4 hours ago, crem said:

Surely will do! Could you help me to pick a right file with this version, is it this one? (from worldofspectrum)

Do you know if the memory layout is the same in this version? (currently I use a breakpoint at $870e to separate frames, at $8908 to detect loss and at $902b to detect win. Also some memory locations here to fetch state details)

Interesting, I thought all collision detection was pixel-based.

@IRF has answered you @crem but that's the correct file.

For reference the Mastertronic and VentaMatic are based on the Software Projects release too, the latter has a different loader with a vaguley hidden cheat and some language changes, the former is missing a single byte of data from the end of the code, effecting the horizontal guardian in Final Barrier in its appearance.

 

[Norman Sword]

Processing Plant. The change in graphics for the Nasties and the Objects/items will have no impact on playing the room.

Sprite collision is pixel based.
Item/object collection and Nasties death are Attribute based

[IRF]

6 hours ago, crem said:

Do you know if the memory layout is the same in this version? (currently I use a breakpoint at $870e to separate frames, at $8908 to detect loss and at $902b to detect win. Also some memory locations here to fetch state details)

See the post below - this might be the easiest way of facilitating the algorithm's latest mission.  i.e. instead of adjusting your break points, etc, just copy the Software Projects data over to the Bug-Byte gamefile:

(And you wouldn't have to copy the whole dataset from #B000 onwards; just the vertical guardian sprite data for the two caverns of relevance. i.e. addresses #F300-#F37F and #F700-#F77F.)

Edited March 25, 2021 by IRF

[Norman Sword]

crem I  might be stating the obvious. 

The variables being monitored in Manic Miner. I will assume you also modify Manic Miner with the following change in code.

87AB    LDIR    ;<<<<< SET #87AB=0 , #87AC=0
RESTORE WITH #87AB=#ED #87AC=#B0

87D1    LDIR  ;<<<<< SET #87D1=0, #87D2=0
RESTORE WITH #87D1=#ED, #87D2=#B0

 

This change in the code will double the speed of the program. It will loose the game display whilst it plays. But I do not believe you watch the game being played at hyper speed trying to find the quickest path.

 

[Spider]

11 hours ago, crem said:

Do you know if the memory layout is the same in this version? (currently I use a breakpoint at $870e to separate frames, at $8908 to detect loss and at $902b to detect win. Also some memory locations here to fetch state details)

I did plan on this earlier but there were some time constraints.

BB: #870E = SP: #8714

BB: #8908 = SP: #890E

BB: #902B = SP: #9036

Attached are three slightly messy (sorry) combi pics of the disassembly, however its likely enough for what you want as you can clearly see the locations.

BB version on left side and SP on right side, so you can see its properly 'matched up' , the addresses you mention are highlighted (obviously only in the left part as the SP version is in a slightly different place!) 🙂

 

 

 

Ignore 'breakpoint' red dot on them, and the rest of the code around the indicated line(s).

[crem]

18 hours ago, Norman Sword said:

crem I  might be stating the obvious. 

The variables being monitored in Manic Miner. I will assume you also modify Manic Miner with the following change in code.

87AB    LDIR    ;<<<<< SET #87AB=0 , #87AC=0
RESTORE WITH #87AB=#ED #87AC=#B0

87D1    LDIR  ;<<<<< SET #87D1=0, #87D2=0
RESTORE WITH #87D1=#ED, #87D2=#B0

 

This change in the code will double the speed of the program. It will loose the game display whilst it plays. But I do not believe you watch the game being played at hyper speed trying to find the quickest path.

Thanks for the suggestion, I indeed noticed that 40% of the time my tool spent in LDIR instruction emulation and thought about doing such change, but I was lazy to check whether that change would break something (e.g. maybe something after this instruction relies on BC being equal to 0 or something like that).

During the search process I actually only show the screen only once per 10000 frames or so, just to visually control that the search progresses as expected. What I could do is to put LDIRs back only before the frames where I going to show the screen contents.

Usually, it took around 10-12 hours to process one cavern. With this optimization it would be 6-10, would surely be useful.

However, now that MM is almost "done", I think it's too late to implement such optimization.
I'll surely look into that when I start the search in JSW. Will probably need some help in this forum. My experience with Z80 CPU is quite limited, I've read some books on this topic and also read some code, but I believe I've never written a single Z80 instruction myself.