Manic Miner in 48k with 40 rooms

[Norman Sword]

On 2/3/2020 at 12:05 AM, Norman Sword said:

Manic 40 Miner

After I stopped developing the JSW128  VK VL VM   engine. I spent a week writing a version of Manic Miner called  Manic 40 Miner.

This does not contain any new rooms. They are the original and Ligans rooms.

This is NOT meant to be a playable version. It was just a test routine.

The rooms have a lot more scope to edit and have a lot more tiles to play with.

NOTE this runs in 48k the same as the original.

It does a lot more than is obvious from a quick glance.

The purpose and scope of the routine was primarily a proof of concept.

After asking myself how easy is it to edit the original Manic Miner and compress the data slightly to enable 40 rooms.

I decided to take a new naked listing of Manic Miner and look at how the original stored its data.

Matthew stored the room graphic layout as an attribute tile for each and every one of the 512 tiles.

In JSW the tiles were stored as a bit stream of pairs of bits describing one of four types, resulting in a reduction from 512 bytes down to 128 bytes plus an eight byte overhead to describe one stair and one conveyor.

Manic Miner has more tile types and two bits does not give enough scope to describe the room without more add ons.

Manic Miners room layout can be described with a stream of three bits (giving enough scope for all the rooms) .

But a three bit stream of data is not easy to visualise or edit, and we still need to tag on one extra bit to describe the direction of the conveyors. Easy enough to write in code- but as I said not easy to edit the bit stream when seen as data.

It makes more sense and is easier to visualise if we expand to a four bit stream of data. Here each four bits corresponds to a nibble of data. Very easy to edit, easy to visualise and editable with just a hex editor

Expanding to nibbles to describe a room, actually compresses the original 512 bytes of data describing each rooms layout in Manic Miner down to 256 bytes. 

*** NOTE *** this compression is designed to be primitive in its layout. I could compress down to a quarter of this size

if I used a more aggressive method. Editing naked layout data then becomes very difficult.

Once I decided on using nibbles to represent each of the tiles, it is obvious I can have more types of tiles described by each nibble.  

Reducing each basic room layout and definition from 4*256 bytes to 3*256 bytes still does not give enough scope to greatly expand the room count...  It has released 20*256 bytes of data, which is nearly enough for seven rooms. So doing just this slight compression allows 27 rooms for Manic Miner.

It would not take much effort to do this- an expansion to 27 rooms is very easy. It just needs the indexing of rooms and the drawing of the rooms to be changed. (ignoring the few data reference's that also need changing)

40 rooms needs a bit more effort. 

 

Edited August 14, 2021 by Norman Sword
Removing the excess text space displayed.

[Norman Sword]

Space for 40 rooms.


The numbers game.

From this point on we start to play the numbers game. Here we look at the data and do a simple calculation on how much code is needed to compress the data.

 

For manic Miner and twenty rooms, compression is rather pointless in most cases. To save a byte in the room data needs to take less than 20 bytes to extract from the data. In JSW the bytes saved for each room needs to take less than 60 bytes to save any memory and then we loose the nice page alignment that makes the data so easy to use. In expanding JSW to 128 rooms we now have the bigger savings. Each byte saved in a rooms data, can be offset by needing 128 of code to make the saving not worth while. 128 bytes of code is a large piece of code.

Back to 20 rooms and Manic Miner. If we look at the bigger room count of 40 rooms, we can see that each byte saved in a room now can be matched against needing less than 40 bytes of code to justify its inclusion.

The definitions for each tile are stored in each room. Manic miner has space for the definitions used in 20 rooms, each room storing its own  tile definitions for space/floor/wall/collapse/nasty 1/nasty 2/key/conveyor.  That is 8 character/tile definitions per room or 160 tile definitions in total.

Manic Miner does not use anywhere near that amount of tile definitions. Scanning the data it was found to use less than 80 tile definitions. 
If the room count is expanded to 40 rooms. Manic Miner, if left unchanged would store enough tile definitions for 320 tiles. Whilst the original 20 room Manic Miner manages with less than 80 definitions, this suggest we have leeway in reducing the amount of tile definitions used. It would not compromise how the rooms are stored and drawn. If we undertook a massive reduction from the 320 tile definition possible, down to 128 tiles in total. From past usage this would not introduce a great restriction. Saving (320-128)*8 bytes . The problem now is now how does the room store the new data, and how much code does it take to expand out.

One problem at a time.

1)The tile data is very rarely referenced. Its main and biggest reference is drawing the rooms. So the room draw routine needs changing to reference tiles in a more obscure way. The room draw routine has been changed to uses nibbles for its data, changing the room draw routine to permit tile numbers instead of the tile graphic data does not take much code. Probably less than fifty bytes. which is dwarfed by the amount of data potentially saved.

 

1a) The keys use the tile data to repeatedly draw the keys. It is easier and quicker to copy each rooms key data into a buffer (when drawing the room) and use that data.

 

1b) The storage of the graphics is separated from the room data. This changes how the room stores the graphic data. I  kept the colour byte and replaced  the eight definition bytes for each tile with a tile index value. This changes the original layout and reduces the size of the tile data from 64 bytes per room to 8 bytes per room.  (At a later date this was expanded to use the whole 16 possible tile definitions)

 

1c) The room and its data size is now less than a nice page aligned value. We now need to calculate the offset to each room.

Playing the numbers game.

Data reduction by shifting the graphics(tile) data out of the rooms into a separate list is reduced by having to write several pieces of code and having to incorporate a new set of indexes into each room.

Data lost from each room for a 40 room version of Manic Miner is 56 bytes. but we also now have a big table of data being all the tile definitions which is (128*8) bytes

overall for 40 rooms the figures are.

40 rooms reduced in size by 56 bytes  or  2240 bytes against adding the tile data (128*8) byes or  1024 byes + the code.

It is a very large piece of code that consumes nearly 1116 bytes - it is worth the convoluted effort to use separate  tile graphics

The above is a start.

we can compress ....

 

 

(edited --- 2)

   

 

Edited February 5, 2020 by Norman Sword

[Norman Sword]

Spotted a few errors in the above - . This is a general walk through and not specific.

A room now consists of:-    (This is a draft layout (A lot of data and scope for errors) and might get updated)

The lines starting with > are what was originally in the room and comments on that data 

> Room name  - original 32 bytes

32 bytes the room name - no change in data size

> tile definitions (expanded from the original 8 types) - original 8 by 9 bytes - 72 bytes

16*2 bytes the 16 tile definitions *** NOTE this defines 16 tiles and not 8 as originally ***

1 byte the key definition - Originally stored elsewhere - the original was 8 bytes

Carrying on through the room data

> The next 7 bytes define Willies start position etc

>   1 byte - The pixel y is defined by the attribute - so can be deleted

>   1 byte - animation frame  and direction is less than 4 bits

>   1 byte - Direction and movement flags --- can be described in 2 bits

>   1 byte - Airborne status 

>   2 bytes - Willies attribute position - can be described in 9 bits

>   1 byte - jump animation counter

>  The macro below :- defines all the wanted data from above in two bytes

WILLY  0,0,13,2    --- this defines Willy at 13 down and 2 across + various flags

>The next four bytes are copied to 806F and specify the direction, location and length of the conveyor.
> 1 byte  Direction of conveyor 
> 2 bytes Location in the screen buffer of the conveyor 
> 1 byte  Length of the conveyor

The above is not needed. The room layout data contains enough information to decode the position and direction of conveyors

> The next byte is copied to Border_Col_32883 and specifies the border colour. - Originally 1 byte
1 byte  - Border colour    ; MOST BITS used

> the next byte was not used - so deleted

> The next 25 bytes specify the location and initial colour of the items in the cavern

>The below macro's reduce the key data from 25 to 10 bytes;- we do not need a starting colour

key1 3,0,9 ;23561   ;Item 1 at (0,9)

key1 4,0,29 ;23581  ;Item 2 at (0,29)
key1 5,1,16 ;23600  ;Item 3 at (1,16)
key1 6,4,24 ;23704  ;Item 4 at (4,24)
key1 3,6,30 ;23774  ;Item 5 at (6,30)

> The next 37 bytes define the portal

>the portals have had their graphics moved out of the data

portals reduced to 4 bytes   + exterior data for the portals

1 byte  defines the Attribute      

1 byte gives the definition index
2 bytes  the location in the attribute buffer 

> the next eight bytes define the object - moved to one byte after the graphic definition index data

> The next two bytes define the game clock and air bar

The following macro in 1 byte defines the game clock and air bar 

GamePeriod 63,252

;===============Guardians===============

the space for the guardians the terminators and the guardian definitions

> 4 horizontal guardians at 7 bytes each

> 1 byte terminator

> 2 unused bytes

> 4 vertical guardians at 7 bytes each

the above 59 bytes are replace by 8 by 8 byte definitions - original 59 now 64 --- more data, but allowing more scope to change order, definitions and actions.

and again the guardian definitions are moved into a continuous space and indexed into

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

The above to extract uses a lot of code. But the savings are worth the effort.
 

Edited August 14, 2021 by Norman Sword
removing excess white space on the text

[Norman Sword]

Side track on those editor keyboard keys

--- Which have all probably been worked out---

************** NOTE 1 *****************

The original program that was at the beginning of this topic has been deleted. I added a piece of code just before I assembled it and then placed the code on this website. The code that I added was a bypass of the cheat code. This was done so that you would not need to have knowledge of what the cheat code is. Unfortunately that addition has made the code ( see the key combination Z H O ) Unable to remove the cheat code. 

************  NOTE 2  ******************

I have attached a revised program. V2

The revised program has been modified to include (Item/key) editing

This has changed the way this programs keyboard responds.

*********** NOTE 3 *******************

I have attached a revised program. V3

The revised program has been modified to include 

1) moving Willies start position and start animation frame in a room

2) Moving the position of the portals

*********** NOTE 4 ******************

I have attached a revised program V4
The revised program has been modified to include.

1.  removal of Kong switch Bug
2.  removal of score Glitch
3.  A lot of small changes
4.  The addition of editor Mode 5

    mode 5 permits altering a sprites room definition

*********** NOTE 5 ****************

I have attached a revised program V5

The revised program has been modified to include

1.  a means of defining a sprites room colour
2.  removed fixed colour on Kong - Still Red it it falls
    

Rather than have multiple explanations of what the keyboard keys are.

I will edit the text below. Since I have revised the code, I see no point in keeping

an explanation of the old code current.

(for now I will part indicate the changes)

Explanation below is for V5  (Version 5)

 

****************************************************************************

*      This has not been updated to V6 - The explanation for V6 is available alongside the file in post #1            *

****************************************************************************

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

I will start with a WARNING.

 

If the program file is edited so that the first room is unplayable. Then going back to the title screen can cause a lockout of the editor.

The room needs to be drawn and the first loop of the game passed before the keyboard is scanned for both the cheat code, the cheat type in, and all the editor keys. If the sprites are set to start with a collision on the first room or Willy started over any Nasty graphic. Then death will occur before any other action can take place. This means that further editing and even game play can not proceed. If the start of any other room causes instant death then the editor is still reachable via any other room, and the problem area can be changed via editing.

(hopefully)

 

It is the first room that can remove access to editing and for that reason editing the first room needs more care than any other room.

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

At present the game starts with cheat enabled and this part editor in memory. It allows normal game play with cheat, and the ability to jump into this limited Editor. The editor does have the ability to delete/encrypt itself and turn the cheat and editor off. When that is done, it is still possible to type in the cheat code and again use the cheat. The editor and all its function will however not be available,  

 

Manic 40 Miner -- Editor

While playing the game. 

When the game is played and the boot is shown on the lower portion of the screen.
Beneath the cheat boot is the active room number.

active keyboard keys for cheat.

the "3" key is the cheat activator

3           -  Reset the room to its start position
3 Plus 1 - Move back a room. Wrap around to 40 if on room 1

3 Plus 2 - Move forward a room. Wrap around to 1 if on room 40

3 Plus 0 - Activate the Editor (If available)
 

Pressing the keyboard keys three and zero at the same time
will enter into a limited editor. Provided the editor is still in memory 
 

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

From here onwards keyboard keys described are for the environment of editing the game

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

There are a great deal of keyboard keys active.

And remember that this also has the data for 40 rooms. The memory restriction placed on me due to the extra rooms, has forced convoluted keyboard key usage.

In all modes 

(keyboard keys operational in mode 1, mode 2, mode 3, mode 4, mode 5) 

L - Toggle between the graphic room display and the hex room display modes
 

K - toggle between hex with zero and hex with spaces (hex room display)

J -  toggle between graphic trail and no graphic trail (graphic room display)

J - Toggle full screen display
       If in graphic room display mode  - (switch Items/key, portals and sprites ) - on/off

                                                     (switch graphic trails)  on/off      

       If in hex room display mode - (switch full hex) - on/off

M - Toggle between the five screen edit modes 
       1) room tiles   ------ (mode 1)  - (define tile colours) 
       2) global tiles  -----  (mode 2) - (define which tiles to use in (room tiles and edit tile))

                                                   (define item/key graphic)
       3) edit tile   ------     (mode 3) - (edit a tile definition)
       4) edit room -------  (mode 4) - (define where the platforms etc are in a room)

                                                   (define Willies start position/face direction/phase)

                                                   (define the Portals start position)

                                                   (define the position of keys)

        5) edit sprites ------ (mode 5) - (identify sprite allocation) 

                                                   (change a sprite definition for the current room)

                                                   (change a sprite colour for the current room)

R - Move the cursor left - wraps on left edge
T - Move the cursor right - wraps on right edge
U - Move the cursor up - stops on the top
H - Move the cursor down - stops on the bottom

Q - Move to previous room
W - Move to next room

<ENTER> - exit room editor and resume play

NOTE the purpose of allowing Graphic trails by switching the sprites on.

Is so the user can see where the sprites move in any room.

This enables the user to keep the rooms graphics out of their paths.

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

Room edit mode for room tiles

(define tile colours)

1) room tiles. (mode 1) These are displayed in the lower left part of the screen

There are 16 tiles, each tile is displayed as follows

line 0 - The graphic as defined for the room.
line 1 - The paper colour of the tile
line 1 - can also have a dot displayed in the paper colour
           A dot indicates bright is set
line 2 - The ink colour of the tile
line 2 - can also have a dot displayed in the ink colour
           A dot indicates that flash is set
line 3 - A hex digit signifying what key is designated to what graphic
          A room is built from these 16 tiles

The cursor when moved will jump across the gaps between the

upper eight tiles and the lower eight tiles.

Whilst it moves it will stay illuminating the hex digits for the tile.

The only method of changing the selection is via

the cursor move keyboard keys. [ R-T-H-U ]
 

active keyboard keys for room tiles in addition to the global keyboard keys

(additional mode 1 keyboard keys)
 

I - change the Ink
P - change the Paper
B - change the Bright - Note the dot - indicating bright
F - change the Flash  - Note the dot - indicating Flash

all changes to the tiles will be seen instantly in the playing area

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

Room edit mode for Global tiles

(define which tiles to use in (room tiles and edit tile))

2) Global tiles. (mode 2) these are displayed on the lower right of the screen.

    8 rows of 16 tiles in yellow. allowing access to 128 tiles

The space for tiles is shared with the space for portals.
The ability of expand past 128 is not included 
There exists a big block of empty shared memory for the portals and the tiles.

When moving the cursor round the Global tiles using those pesky keyboard cursor keys.[R-T-H-U] It will be evident that the tile graphic under the cursor is displayed next to the room tiles. (middle lower left of the screen)

The tile under the cursor can be selected as a room tile. Just by pressing
one of the keyboard keys representing the 16 room tiles.

E.g. pressing "1" will transfer that selection into position "1" of the room tiles

The graphic is copied into the room and also if the room has those graphics displayed
then the room graphics will also be updated instantly.

*** Note *** transferring graphics into the room tile graphics does not affect
any tiles colour. They are defined only via the room tile editor.

Since the transfer of graphics is instantaneous, it pays to just mess around
transferring graphics into the room tiles.

 

active keyboard keys  for Global tiles in addition to the global keyboard keys

(additional mode 2 keyboard keys)

0 - copy current tile into graphic slot 0 - Background
1 - copy current tile into graphic slot 1 - Floor
2 - copy current tile into graphic slot 2 - Collapse
3 - copy current tile into graphic slot 3 - Wall
4 - copy current tile into graphic slot 4 - Conveyor ( moving from right to left)
5 - copy current tile into graphic slot 5 - Nasty 1
6 - copy current tile into graphic slot 6 - Nasty 2
7 - copy current tile into graphic slot 7 - Switch
8 - copy current tile into graphic slot 8 - Conveyor (moving from left to right)
9 - copy current tile into graphic slot 9
a - copy current tile into graphic slot a
b - copy current tile into graphic slot b
c - copy current tile into graphic slot n
d - copy current tile into graphic slot d
e - copy current tile into graphic slot e
f - copy current tile into graphic slot f    - Ignore tile 

(continuation of mode 2 keyboard keys)

When the main screen is displaying the flashing keys

e.g. when you can see the Items/keys flashing

K - copy the current tile into the Item/Key graphic

A note on the ignore tile (tile F). All tiles can be walked on. Manic Miner and Jet Set Willy treat any tile that is  found under Willies feet as a tile that can be walked on. It treats collapsing floors as a special case. but everything thing else can be walked on. Walking on nasties will still kill you. Tile "F" is specifically checked for and deliberately ignored as a tile. What this means is that all tiles with the same colour as tile "F" can not be jumped or walked on.  This does not permit the ignore tile, if it contains graphics, to be placed in the path of a sprite. That will still flag a sprite collision and result in the demise of Willy.

An extra note on the ignore tile (tile F) We could use similar colours to tile 0 the background tile, to construct a platform or graphic area from. This would also be treated by the game as a platform that can not be waked on and would seem to make the need of (tile F) superfluous. Unfortunately the graphics are then treated as a background graphic, and willy passing over that graphic will change its colour, which is not what happens to every other game graphic used in conveyors, platforms, collapsing floors etc. So yes the graphics would look the same, but they will not be treated the same visually, and the difference is very noticeable. The plus side is you can define two non interactive sets of colours and willies interaction is different for the two graphically. But not in game movement.  Light beams can pass through a platform generated by using the background colours. A light beam will not pass through an ignore tile. ---  What happens if the ignore tile and the background are the same colour. Then the ignore tile is treated the same as the background. Willy passing in front of the tile will colour it in.

A note on on Switch tiles (Tile 7). The switch tile is checked only when a Kong sprite is defined in a room. In any room that does not have Kong, this tile will act as a normal walk on tile. 

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

Room edit mode for editing tiles

(edit a tile definition)

3) edit tile - (mode 3) this is where the cursor is flashing on the graphic
for the last tile that was under the cursor in Global tiles.

The cursor can be moved around - space will toggle a bit on/off/on etc

***** NOTE **** all editing will affect all the graphics seen on the screen.
If you are editing a tile, then if the tile is a graphic used in the room then you will
see the rooms graphics changing as a result.

***** TIP ***** do not leave the sprite trails on while doing this. It is very distracting.

If  shift is pressed whilst moving the cursor then the tile definition will scroll.

 

active keyboard keys  for edit tile in addition to the global keyboard keys

(additional mode 3 keyboard keys)

space - Toggle the bit on/off/on etc
shift + cursor = scroll the tile

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

Room edit mode for editing room layout

(define where the platforms etc are in a room)

4) edit room layout- (mode 4)  the top two thirds of the screen.

The cursor can be moved around over the hex or graphic data.

***** TIP ***** do not leave the sprite trails on while editing tiles.

                    It is very distracting. (and slow)

pressing any of the alphanumerics 0123456789abcdef on the keyboard will place that tile on the screen at the cursor position.

Because nearly all keyboard keys are active. I added the ability to lock a selection onto
the keyboard space key. If a long platform is needed in say type 4 conveyors then press four on the keyboard to start the drawing off and then use the keyboard  cursor keys [RTUH] along with the keyboard space key to move and deposit conveyors. (because of redraws the action is slow)

 

active keyboard keys  for edit room in addition to the global keyboard keys
(additional mode 4 keyboard keys)

0 - place tile 0 at cursor location
1 - place tile 1 at cursor location
2 - place tile 2 at cursor location
3 - place tile 3 at cursor location
4 - place tile 4 at cursor location
5 - place tile 5 at cursor location
6 - place tile 6 at cursor location
7 - place tile 7 at cursor location
8 - place tile 8 at cursor location
9 - place tile 9 at cursor location
a - place tile a at cursor location
b - place tile b at cursor location
c - place tile c at cursor location
d - place tile d at cursor location
e - place tile e at cursor location
f - place tile f at cursor location

space - place last tile selected

 

(additional mode 4 keyboard keys)
(added for V2)

When the main screen is displaying  Willy the portal and the keys
e.g. when you can see the Item/keys flashing

K - Place an Item/Key in the current position

       if no item/key available - request is ignored

       if an Item/key is already at this position - the item/key will be deleted 

(additional mode 4 keyboard keys)

(added for V3)

When the main screen is displaying the start position of Willy and the portal
e.g. when you can see Willy and the Portal

P - Move the portal to this position.

      only legal screen positions are allowed for the portal

N - Move Willies start position.

     If already at this position then cycle through the frames and reverse.

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

(added for V4)
Room edit mode for room sprites
(define room sprites)

5) edit sprites  (mode 5) 

When in this mode the graphic that is normally displayed just left of the centre

on the lower portion of the screen changes colour. It will change from the normal
black and white with blue underlying text to one of two sets of colours 
1) Red and black, (no underlying text)
2) Yellow and black (no underlying text)

There will be no screen cursor. The graphics drawn in the normal graphic box

will be either a "+"(plus) or a "-"(minus). The symbol shown is indicating the

direction that graphics will be changed.

 

Pressing the letter "S" will toggle the "+" to "-" or toggle the "-" to "+"

If the screen is NOT showing static sprites. Then the "+" or "-" will be shown in red.
Red indicates No changes can be made
 

If the screen is showing Static Sprites. Then the "+" or "-" will be shown in yellow.

Yellow indicates sprites can be changed

What follows below is when the sign indicated > the "+" or "-" is in yellow.
 

Each room has eight sprites slots. And a Guradian/sprite can occupy any of the eight slots. 

Pressing the digits 12345678 will flash an active sprites colours if it is in the sprite slot indicated by the digit.  This is used to identify which sprite is in which sprite/Guardian slot. A number if when pressed, gives no visual indication on the screen. Is indicating that that sprite/guardian slot is not used.

 

Having identified a sprite/Guardian, we can change the sprite/guardian by pressing the shift key and the corresponding number for that sprite.

The direction of change is defined by the "+" or "-" seen on the screen
 

The sprites can be changed, but no help is given with adjusting sprites from 8 phase to 4 phase.  No help making sure that horizontal sprites are placed in horizontal definitions. And the same with verticals. No boundary restriction on where the data is taken from. This means we scan the full 32 pages , and not all are used or defined.

In addition V5 adds the ability to force a sprites colour

 

active keyboard keys  for  sprite edit in addition to the global keyboard keys

(additional mode 5 keyboard keys)  (from V4 onward)

 

S - Change the sign and direction of change

 

When Sign is Yellow

1 - Identify sprite slot 1

2 - Identify sprite slot 2

3 - Identify sprite slot 3
4 - Identify sprite slot 4

5 - Identify sprite slot 5

6 - Identify sprite slot 6

7 - Identify sprite slot 7

8 - Identify sprite slot 8

 

shift +1 - Alter sprite in slot 1 (direction of change is indicated by the "+" or "-" sign)

shift +2 - Alter sprite in slot 2 (direction of change is indicated by the "+" or "-" sign)

shift +3 - Alter sprite in slot 3 (direction of change is indicated by the "+" or "-" sign)

shift +4 - Alter sprite in slot 4 (direction of change is indicated by the "+" or "-" sign)

shift +5 - Alter sprite in slot 5 (direction of change is indicated by the "+" or "-" sign)

shift +6 - Alter sprite in slot 6 (direction of change is indicated by the "+" or "-" sign)

shift +7 - Alter sprite in slot 7 (direction of change is indicated by the "+" or "-" sign)

shift +8 - Alter sprite in slot 8 (direction of change is indicated by the "+" or "-" sign)

 

In addition from V5 onwards

 

Pressing a number will up cycle the sprites colour. Used to identify a sprite slot.

 

If the "C" key is held down then the colour is stored. The border will also change

colour to match the sprites colour.

 

added keyboard keys for V5

 

C +1 - Set colour of sprite in slot 1
C +2 - Set colour of sprite in slot 2
C +3 - Set colour of sprite in slot 3
C +4 - Set colour of sprite in slot 4
C +5 - Set colour of sprite in slot 5
C +6 - Set colour of sprite in slot 6
C +7 - Set colour of sprite in slot 7
C +8 - Set colour of sprite in slot 8

 

 

Method to use... Find a sprite/guardian slot with keys 1 to 8

When the sprite that needs its colour changed is found, hold down the keyboard "C" key and tap the number that corresponds to that sprite slot. The border and the sprite will up cycle colour.

The colour remembered for the sprite is the border colour while up cycling and the keyboard "C" key was pressed.

Subsequent changes of colour are ignored if the keyboard "C" key is not held down.
This changes only one sprite's colour at a time.

Not a logical or easy set of operations to follow - (the best I can do in the space I have)
 

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

This is a global keyboard key press that changes everything
 

(available in all modes -- e.g.  mode 1, mode 2, mode 3, mode 4, mode 5)
 

While in the editor ...

 

Holding Z H and O <all are letters>

will result in a block slowly moving across the screen.

( on a red screen this might not be noticeable)

 

The amount of time it takes to fully activate, is deliberate.

Once done all the code for the editor is deleted. 
 

The game will be put back into a standard uneditable game,

without cheat activated.

 

If this is aborted part way through the screen might need

refreshing by pressing any key that updates the screen.
 

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

 

The storage of the tiles was made as simple as possible. This was to enable editing from any hex editor. The rooms have no compression and are very simple to edit.

The colour of each tile defines what action is taken by the game.

 

If a tile is defined with multiple tiles in the same colour it will exhibit normal Manic Miner duplication of actions.

Tile "0" is the background. 

Tile "1" is the standard floor tile. (can be walked on)

Tile "2" is the crumbling floor tile. (can be walked on but crumbles)

 

Tile "3" is Wall tile. (Blocks movement through it)
 

Tiles "4" and tile "8" are conveyors in the opposite directions. The tiles are scanned on building the room to display. The positions of the conveyors are noted and copied into a list. This list has a finite size. Any more than the maximum number of conveyors will just be ignored. This means they will still be conveyors- but not animated.

 

Tile "5" is Nasty 1 (kills if touched)

Tile "6" is Nasty 2 (kills if touched)

 

Tile "7" ( the switch tile)  is also tracked when a room is built. The first two switches found in the room (scanning from the top left) are the active switches for Kong. They can be placed anywhere in the room, or even omitted.
 

Tile "9"  Free to use.

Tile "A" Free to use.

Tile "B" Free to use.

Tile "C" Free to use.

Tile "D" Free to use.

Tile "E" Free to use.

Tile "F" (ignore tile) is specifically checked for and deliberately ignored as a tile. What this means is that all tiles with the same colour as tile "F" can not be jumped or walked on.  This does not permit the ignore tile, if it contains graphics, to be placed in the path of a sprite. That will still flag a sprite collision and result in the demise of Willy.

============================================================
Room events

Editing these is not undertaken in this editor

skylabs

1)  Can descend or ascend

2)  They can step left or right after each ascent/descent

3)  The sound of crashes are selectable from a list of four

4)  They can animate or stay static

Light beams

1) standard light beam - down and left

2) left light beam switching on and off - down and right
3) moving light beam - down and left switching periodically  to down and right

4) Light beams can be mixed and can be used in any room.

 

Kong

1) Kong's switches can be anywhere in a room
2) the order the switches are pressed is unimportant
3) Kong can be anywhere in a room
4) Kong's distance if Fall is definable
5) The wall opening is part definable
6) It still has a fixed sprite that can pass through a fixed opening.

 

Eugene

1) Eugene can be placed anywhere

2) Range definable

 

Sprites/guardians

1) any type of guardian/sprite can occupy any rooms sprite/guardian slot

   this means you can/could have eight verticals or eight horizontals in any room

2) any type of guardian/sprite can be mixed with any other

3) Eugene is a guardian/sprite and not a room event

4) Skylabs are a guardian/sprite and not a room event

5) Kong is a guardian/sprite and not a room event

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

 

The edit function was added as a mess around. Its purpose (to me) was to see how much code it would take to add an edit function. I ran out of space and the amount of code needed to expand the scope of editing is not available with 40 rooms as well.

 

What it does not edit

 

PORTALS - NO - (V3 now includes altering start position of portal)
SPRITES - NO - (V4 now includes altering sprite definition) (V5 Includes basic colour changing)
START POSITION - NO - (V3 now includes altering start position and animation frame)

ROOM NAME - NO

 

Edited August 14, 2021 by Norman Sword
removing excess white space on the text

[Norman Sword]

Quirk that was unknown to me before doing this....

When Ms Kong is knocked of her perch, she falls down the screen. The platform she was standing on is erased. And Kong is moved down the screen. Because it can pass over one of the lower sprites Kong has her collision detection turned off for her fall.

I mention the above due to playing around with the position of KONG and the position of the switches. It became possible (and still is) to enable the KONG sprite to pass over Graphics as it falls and also pass over Willy without flagging collision. 

I can think of no other sprite that turns off its collision in such a way. (the toilet in JSW is always off - Kong changes from active to passive) 

   

[IRF]

I can think of no other sprite that turns off its collision in such a way. (the toilet in JSW is always off - Kong changes from active to passive)

 

I guess that's because Kong changes from being alive to dead when you flick the switch!

 

 

The edit function was added as a mess around. 

 

It does not edit most of the rooms data

PORTALS - NO

SPRITES - NO

START POSITION - NO

ROOM NAME - NO

 

What about location (and bitmap) of the collectable items in the cavern that you're editing?  Can that be done via your edit function, or does it have to be done by editing the global table?

Edited February 5, 2020 by IRF

[Norman Sword]

Item location and editing.

The items are in the global table and can be edited.

Position and definition --- Easy to edit in the source listing - It uses a macro for x,y,number.

Since I last looked I think there was about 15 bytes of spare memory in the 48k. Not enough space to even permit the changing of the definition

(or enough space to change the definition - but no easy way of showing it was changed and to what it was changed)

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

In the process of going out. - I will think about this whilst out. But I can not en visualise a solution in the memory available. 

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



 

Edited February 6, 2020 by Norman Sword

[Norman Sword]

Managed to add a key edit function. Works well enough. But I will analyse my code and possibly rewrite.

[Norman Sword]

Re wrote the code and made smaller. There was really no memory to add the edit key function. What I have done is delete some of the space allocated for extra graphics and portals, and used that memory for code.

Revised the editor explanation code - spent a lot longer  typing the revised explanations than I did to writing the code.

I will shortly attach the revised code to the first post- Manic 40 Miner v2  

[IRF]

Slight confusion between references to keys for keypresses on the keyboard, and also for collectable items (not all of which are key-shaped. e.g. Snowshoes, bananas are also collectable)you in some caverns).

But I can see that the INK parameter needs to take precedence for use of the letter 'I' on the keyboard.

 

Anyway, the ability to edit the placement and form of the collectable keys/items in each cavern is a welcome addition to the editor.  :)

 

**

 

I previously misunderstood the purpose of the 'graphic trail' mode; I tried in vain to find a key combo which allowed me to edit the parameters of the guardians.  But I can see the benefit of displaying the range of the guardians' paths, so that when placing room tiles you can avoid a collision between the two.

Edited February 6, 2020 by IRF