Manic Miner in 48k with 40 rooms

[Norman Sword]

I ran out of memory way back in version 1

 

since then I have added:-

 

1) the ability to define the keys used in a room
2) the ability to delete keys in a room
3) the ability to add keys to a room.
4) the ability to move portals
5) the ability to define the start position of willy
6) the ability to define the start phase of willy
7) the ability to identify which sprite uses which sprite slot
8) the ability to increment a sprite page in a sprite slot
9) the ability to decrement a sprite page in a sprite slot.

 

The above are editor specific additions.

 

I also added a variable tune speed playing routine

 

I can not keep adding routines to Ram I do not have.

---------------------------------------------------------
When editing in mode 5:

The colour indicated when pressing a numeric key is only to identify which sprite occupies which sprite slot. The colour change is not stored. Evident if any drawings is done then the sprite will revert back to the colour it is defined as.

Last time I looked there was about five bytes of memory left. The figure for memory left changes with each edit of the code. 

It looks very tempting to enable sprite colour changing. But even if the space available was around 50+ bytes, I can see no way of enabling such a change, and I have repeatedly tried. 

Bar a major re-think on this code. There will be no more additions. I will look for quirks and flaws and sort them out.

 

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

 

Re -organised memory to place all the game data in a continuous block and not variable depending on code.
 

 

 

Edited February 25, 2020 by Norman Sword

[IRF]

Fair enough.  Presumably with horizontal guardians it would be more difficult to store the colour, because the 'speed' bit for HGs shares a byte.  Vertical guardians just have a single byte dedicated to the attribute.

 

(That's assuming that the guardian data storage may be as it is in original MM; yours may be compressed?)

[Norman Sword]

The guardians can occupy any slot in any order.

Matthew's data layout, is complicated by the addition of two control codes into the data.

If zero skip, if #ff then end.

Editing a colour needs to check for past end of enabled sprites. The 00 skip colour or the #FF terminator.

Try doing that in less than five bytes.

Ld hl,data
ld de,offset  --- out of memory

Edited February 27, 2020 by Norman Sword

[Norman Sword]

I am amazed I have got this far without the collection sound being included. I had written the code a long time ago, just never bothered to call the routine.

 

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

That was yesterday. And today having revised around 1700 lines of code / comment/ data.  I have added a new key "C" in mode 5

The figure of 1700 for the lines of code/comment/data, show what started as a trivial add onto the program, is now consuming a lot of memory.

What follows are very quick and rough figures.

Size wise the code is just over 1.5K for the editor

To put that in perspective:-

The code for Manic 40 Miner without the data is around 4.75k

A quick look at the original Manic miner , gives a code size of around 3.5K.

Which shows the trade off between having nice simple data layout, and compressing everything in sight.

So I have added around 1.25k in code just for the compression of data.

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

The addition of 1.25k in game code, plus re- writes of most of the other code, has permitted the addition of 20 more rooms and the addition of more features. Plus I have also managed to have 1.5k of free space (used by the editor) as well.

Without the extra code and compression, those extra 20 rooms would need an extra 20k of space. That would somehow need to be fitted into the unused  memory from #934c to #9d00  around  3.25k

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

The end result is, after juggling the figures around. I have fitted the extra 20 rooms in 1.75k of the memory that was free.
----------------------------------------------------------------------------------------------------

 

[Spider]

Excellent to read the updates, thank you. :)

 

I think regarding the sound the last time I did this I merely leapt out (called) of the existing 'collect the item being touched' routine into what was part of the 'dead space area' to make the JSW effect then returned back.

[IRF]

Nice touch in V5 to make the border colour match/indicate the selected guardian colour.  :)

[IRF]

I just noticed that a V6 has been uploaded (attached to post 1 in this thread).

 

I'm not sure what the difference is with it, but I tried to change a guardian's sprite, failed to do so, but ended up with it walking backwards!

 

Oh, and a big red number '5' appears now when the editor is viewed in 'guardians moving' mode.  (I'm not sure what the '5' signifies?)

Edited March 7, 2020 by IRF

[Norman Sword]

In every version up to now that has a mode 5; The "+"(plus)  sign or the "-" (minus) sign would change to red if the sprite was un editable.  Graphically I have forced a distinction between yellow and editable and a big five in red saying < Yes you are in mode five. But I can not allow editing whilst displaying the hex screen or the graphic trail screen>  change display till the "+" or "-" are seen.

This version is flawed-  I have found a flaw in the assembler which has introduced problems. The assembler can sometimes incorrectly value a variable, with the wrong value. E.g.   A-B should be the same as -B+A. or written another way that removes it from looking like assembler opcodes.    X-Y should equal -Y+X.  

 

What has happened is during a re-write of variables I changed some around. ( a layout change) 

 

 

         ld hl, Flag-100

 

should be the same as

 

    ld hl,-100+Flag

 

The assembler for thousands of these type of calculations has no problem. But I have found in the last check I did. That the assembler can sometimes give the wrong answer.

 

 

What the parameter for the error is. Is not going to be investigated further. I have written giga bytes of assembly using this assembler. And I have found a problem on less than a handful of occasions.

Edited March 7, 2020 by Norman Sword

[IRF]

Ah, I've just seen the notes, and discovered the use of the 'P' key for toggling between 4 and 8 frames for horizontals guardians.

The flaw you've discussed probably explains why I can't seem to change the sprites for some of the guardians.

[Norman Sword]

Placing platforms in a room has been substantially improved. By changing  a lot of code and logic order.

Added a Phase change in Mode 5  - pressing "P" changes phase on horizontal sprites.

Mode 5 uses colour to indicate options. yellow(editable), red( not editable) Blue background(8 Phase ) Black Background(4 phase)  

These changes are not notified, because to me they are one of thousands of changes I will make. And as mentioned in post #'48 that version is already obsolete due to a flaw.