Manic Miner in 48k with 40 rooms

[Norman Sword]

Re changing sprite in v6- downloaded the version that is present in post #1- no problems--- 


 

[IRF]

On V6, for me for some reason, I can change the colour of the horizontal robot in Central Cavern, and I can toggle it between 4-frame and 8-frame versions when the background colour behind the +/- symbol is blue.  But I can't select a different sprite for the Central Cavern robot.  :unsure:  :wacko:

[Norman Sword]

Eventually found the problem...A deleted opcode. The direction of change indicated by the "+" or "-" symbol was added to the graphic index.  Well it was until I deleted the opcode.

I have just swapped to a new Pc. I need to swap back to my old Pc keyboard or reconfigure the editor a bit better. This Pc has some very strange buttons on it, or more specifically buttons in places I never had buttons before.

The one I do not like is having a button to turn the Pc off, situated on the keyboard. Pick the keyboard up, accidentally  brush against a sticking out memory stick on the destk top unit, and the pc suddenly switches off.  (who ever thought that was a good idea, must have missed the on - off button that desktop units have)

 

 

I have managed to turn this Pc off, just by pushing the keyboard up against the main unit, and have a usb memory stick turn the computer off .....



 

Edited March 7, 2020 by Norman Sword

[Norman Sword]

And the version 6a won't work until I remove the additional check for logic flow. The phase change is rem 'd out

 

 

Now version 6b -   3 in one day

Edited March 7, 2020 by Norman Sword

[IRF]

I can change the CC robot sprite now (in V6b).

[Norman Sword]

Having no memory to change the code, has made progress very very slow. Which adds to a lack of enthusiasm from me. For every idea I can think of, no matter how small. A change is needed in the main code to allow the addition of extra code to permit the idea to take place. This would have been far easier if I had not included a part editor... Which took all the the space normally used to expand game ideas.

 

The file included here, is included solely for the changes I have done to room 23. Whilst other code changes have taken place. They are not visible or have little effect on what is experienced.
 

Room 23 whats in it that's different to Manic Miner

This room has a moving light beam

Has a moved Eugene, different graphics. This Eugene routine can specify which item Eugene reacts to, or reacts when  all collected.

This room has multiple Kongs

Each Kong can define where it removes a wall section from

Each Kong is movable in position

Each Kong has a definable drop

Each kong has a definable definition. (no other definition is provided in this file)

Each Kong has a definable colour

Has a skylab

Skylab moves upward - definable either way

Skylab has a definable crash sound - definable from 4

Skylab has a definable image and animation stages (not provided in this file)

Skylabs can step backward or forward

 

Note most of the above can not be changed via the limited game editor: I am demonstrating what can be done. Or more specifically what I can change.

--------------------

Addendums:- problem solving to be completable

17th August 2021 : Manic 40 Miner V6c1.tap   

modified room 21 -

removed the conveyor collapsing floor

added an extra collapsing floor just above the portal

================================

17th August 2021 : Manic 40 Miner V6c2.tap   

modified room 21 -

added an extra collapsing floor just above the portal

collaspsing conveyor floor left as in V6c

==============================

Game completeable version 

V6C6 - this allows the game to be played through all 40 caverns, without editing.

 

 

 

 

Manic 40 Miner V6c6.tap

Edited August 25, 2021 by Norman Sword
putting the missing file back V6c.tap and addendum

[jetsetdanny]

Thanks for this new development, Norman Sword! 

[IRF]

I just tried out cavern 23 - it's a great, multi-faceted puzzle!

[IRF]

Norman, am I right in thinking that the piano keys on the title screen now light up 'correctly'? i.e. they accurately represent the notes which are being played at the time, so that if you were to reproduce the visual pattern on a real piano then you would end up playing the tune faithfully?

 

And assuming that is the case, then I have a follow-up query: are the appropriate attribute addresses on the screen worked out in your rewritten version of the title-tune routine, using a logarithmic calculation method (as opposed to the linear method in the original MM, which leads to incorrect keys being highlighted)?

 

Or alternatively, does your rewritten routine use a look-up table to determine which piano keys (i.e. which attribute addresses on the screen) to highlight, based on what note (i.e. which pitch value) is being played?

[Norman Sword]

The routine is still playing a linear keyboard. The only changes are the compression of the data, the redrawing of the keyboard, the full key light up and removal of the silent keyboard light ups.

Long time since I looked at the routine. A quick glance does indicate I could change to a key reference lookup quite easily. E.g. permit each note to designate a value for its true key position. Not something I would bother to do.