Jump to content


Idea for a new cell type in Manic Miner

  • Please log in to reply
45 replies to this topic

#11 Norman Sword

Norman Sword

    Advanced Member

  • Member
  • PipPipPip
  • 190 posts

Posted 13 February 2018 - 03:58 PM

Code at $8ebc


          change to             original

8EBC  call Butt               LD A,($85CF)
8EBF  ld a,($85CF)       ADD A,$10
8EC1                             AND $F0
8EC2   ADD A $10
8EC3                             LD ($85CF),A
8EC4  AND $F0
8EC6  call $8E99          CALL $8E9C  see the routine below
8EC9 LD A,$02
8ECB LD ($85D1),A
8ECE LD HL,$85D0
8ED1 RES 1,(HL)


; the call to this routine is moved to the point that "a" is saved

8E94 LD A,($85CF) 
8E97 ADD A,$08 
8E99 LD ($85CF),A          ; moved to call here
8E9C AND $F0                 ;<<<<<<<< original call point
8EA2 ADC A,$5C
8EA5 LD A,($85D3)
8EA8 AND $1F
8EAC LD ($85D3),HL


; a very vague Butt routine


        test if code is wanted, e.g. jump direction, headbutt flag

        return if not wanted
        else call Butt2
        inc hl


;all calls here return with hl intatct


       code to check where  hl is pointing

       return is not wall tile

      act on the headbutt 

      If tile graphics not cleared then return

      clear TILE from Master Attrib





Teaser:   The border bits are very wasteful. The bits 0-1-2 are the border colour and the rest of the byte is wasted. So I use 1 bit for setting the Butt to on or off. That still leaves 4 bits

With the room  fixed to 256 bytes in size,. Conveyors and ramps use

Ramp_dir                 1 byte

Ramp_position         2 bytes

Ramp_length           1 byte

Conveyor_dir           1 byte

Conveyor_position   2 bytes

Conveyor_length     1 byte

That is eight bytes to define these two actions


It is possible on variable room size (as I now have) to delete a lot of the fixed room data. The bytes that store the conveyor and ramp direction are now also stored in the border colour byte. In fact I have deleted all the ramp data and all the conveyor data from the room data. e.g. these eight bytes are reduced to the top two bits in the border flag...   


It uses a big chunk of code to restore these bytes but the code is part of a bigger piece of code. And the ramp/conveyor specific code (the bit dealing with replacing the data, deleted from the room) is no where near 100 bytes


Simple maths will show you why it is worth the effort of removing unwanted data.  Those 8 bytes are repeated 128 times, if using the old room storage method.( in a 128 room game) So the data contained would use 128*8 bytes of memory ( 1024 )  verses the 100 bytes of code


The above is an over simplification. 

Edited by Norman Sword, 14 February 2018 - 11:21 AM.

#12 Norman Sword

Norman Sword

    Advanced Member

  • Member
  • PipPipPip
  • 190 posts

Posted 13 February 2018 - 09:16 PM

You are probably coming into the routine at 8ebc from one of the two jumps below, which presents a problem


8DF7  LD A,($80B2) 
8DFA  CP (HL) 
8DFB  JP Z,$8EBC  >>>> 
8DFF  CP (HL) 
8E00  JP Z,$8EBC >>>


I have a very small subroutine to handle the above type of tile check. It occurs elsewhere. The sole purpose of the routine is to leave HL alone.


But a quick method of doing the same as my sub routine is


          original                         change to


8DF7  LD A,($80B2)              Ld a,($80b2)
8DFA  CP (HL)                       cp (hl)
8DFB  JP Z,$8EBC  >>>>       jr z,$8e00


8DFD                                     inc hl 
8DFE  INC HL                        cp (hl)

8DFF  CP (HL)                      dec hl 
8E00  JP Z,$8EBC >>>          jp z,   Butt or $8ebc

Edited by Norman Sword, 13 February 2018 - 09:18 PM.

#13 Norman Sword

Norman Sword

    Advanced Member

  • Member
  • PipPipPip
  • 190 posts

Posted 16 February 2018 - 08:20 PM

This should be under JSW not MM. But I am reluctant to start a new heading.


I extended the headbutt to include the MM collapsing floors. 


The playability of this is restricted to 3 rooms. Hence the white blocking walls/floors added to stop wandering.


Additions:- collapsing floor, in addition to headbutt, gun, 4 logo title screens, and 128 rooms. 


The gun is now disabled in specific rooms.... Note the ammo display disappears for the room when the gun is switched off.


Added some SFX's





Attached Files

#14 IRF


    Advanced Member

  • Contributor
  • 4,106 posts

Posted 17 February 2018 - 04:06 PM

It would be handy in Forgotten Abbey, I hadn't thought of that. The player would have to do it before venturing up to collect the item, if they were to avoid the need to sacrifice a life to escape.


Having thought about it, the headbutt ability wouldn't allow a fix for the Forgotten Abbey problem without further layout changes.  Because once the problematic wall tile has been bashed away, then when Willy jumps off the left-hand end of the conveyor - which he has to do in order to reach the item - he will fall a fatal distance onto the green platform (just above the entrance to the room).


EDIT: Although that could be resolved by enabling 'fall any height' ability for Willy in this room only - which wouldn't allow any undesirable shortcuts to be taken in this particular room.  Perhaps if you have another unused border bit*, it could be used to specify 'infinite fall' on an individual room basis?


(* Border=3 bits, conveyor/ramp directions=2 bits, headbutt=1 bit, gun=1 bit ..... so 1 bit remaining?)



I forgot to mention for my screenshot (two posts above this) that obviously there is an easy way past the obstacle presented by the tunnel with the oncoming Swiss Army Knife - simply by exiting The Bathroom at the top-left! But as I said, I just created the mockup to illustrate an idea.


It's also occurred to me that the kind of puzzle I described above could also simply be bypassed by Willy shooting said guardian!  So your latest file, where the '007' ability can be disabled on a room-by-room basis, would be useful for preventing such a shortcut.

Edited by IRF, 17 February 2018 - 04:30 PM.

#15 IRF


    Advanced Member

  • Contributor
  • 4,106 posts

Posted 20 February 2018 - 10:36 PM

Another potential use for the headbutt feature - if wall and nasty blocks have matching attributes, then you could have composite 'nasty walls' (Fire-Earth) which:


- block Willy's progress (though without harming him) if he tries to walk through them;


- kill Willy if he walks along on top of them, or jumps onto them from above;


- but Willy can safely chip away at them with his head (eventually removing them entirely) if he jumps up and hits them from below!


Which could give rise to some interesting layout possibilities!

#16 Norman Sword

Norman Sword

    Advanced Member

  • Member
  • PipPipPip
  • 190 posts

Posted 21 February 2018 - 01:03 PM

When the nasty(fire cell) is set to the same attribute as a wall then a number of interesting things happen (with no change in code)


A nasty/wall acts as a normal wall. it will not let you pass into the space

Sliding down a nasty/wall we have yet another aspect of the ramp stair code affecting the outcome. The passing through the wall by willies head will kill him.

Walking on a tile that is defined wall/nasty will also kill him




I was investigating another theme. eg. invulnerability.


The code at #961e colours in willies tile as he moves around the screen. It has a check for nasties and kills willy if the area of willy is over a nasty. It also extends the checking to the area below willy for nasties and kills willy if he walks on a nasty.




The code at #8e49 deals with the tiles beneath Willies feet and specifically checks for nasties.


I see no reason for the code at #961e being made to check beneath his feet.

If the attributes of willy are cell aligned then test/ colour in the four tiles. e.g check for nasty/colour in the tile

If the attribute of will is not cell aligned then test/colour in the six tiles


The change is to remove the check specifically for beneath his feet. It is not needed.


This changes two parts of the code


95F8 LD HL,($85D3)

95FB LD DE,$001F  
95FE LD C,$0F         
9600 CALL $961E    
9603 INC HL Move    
9604 CALL $961E    
9607 ADD HL,DE      
9608 CALL $961E    
960B INC HL             

969C CALL $961E  
960F LD A,($85CF) 

9612 ADD A,B           

9613 LD C,A
9614 ADD HL,DE                  
9615 CALL $961E 
9618 INC HL          
9619 CALL  $961e          
961C JR $9637                                ;quick count 38 bytes   




61E LD A,($80A0) 
9621 CP (HL)
9622 JR NZ,$962F 
9624 LD A,C 
9625 AND $0F
9627 JR Z,$962F 
9629 LD A,($80A0) 
962C OR $07 
962E LD (HL),A 
962F LD A,($80BB) 
9632 CP (HL) 
9633 JP Z,$90B6 
9636 RET                                           ;quick count 24  Total 62





; b=the offset for the ramp


      ld  c,2                   ; default colouring height

      ld a,(#85cf)          ; the y pos

      add a,b                ; the y pos + stair offset

     and 14                  ; check for cell aligned

     jr z,cell_aligned     ; if cell aligned then 2 high  

     inc c                      ;else it is 3


     ld de,31                 ;offset to next  


     call colour_me       ;colour left cell

     inc hl                     ; move from left cell to right cell

     call colour_me       ;colour right cell

     add hl,de               ;down a line

     dec c

     jr nz,cell_set_loop ;loop for the height

     jr #9637                ;draw willy                           ;quick count 27



          ld a,(#80bb)         ; nasty

         cp (HL)                  ;is this a nasty

         JP Z,90B6             ;kill if so

         LD A,(#80A0)       ;get the background tile

         CP (HL)                ;is this background 

         RET NZ                ;used so no colouring

        OR #7                   ; set ink white for willy

        LD  (HL),A             ;and colour in

        RET                                                            ;quick count 16 total 27+16=43 


;Which I hasten to add is nothing like the code I use

Edited by Norman Sword, 21 February 2018 - 01:29 PM.

#17 IRF


    Advanced Member

  • Contributor
  • 4,106 posts

Posted 21 February 2018 - 01:26 PM

Would that code allow Willy to jump over a Fire cell at head-height? (I suspect it would.)

#18 Norman Sword

Norman Sword

    Advanced Member

  • Member
  • PipPipPip
  • 190 posts

Posted 21 February 2018 - 01:53 PM

This is similar to the ability to jump over a head height wall object.


Logic say that we can clear the object and not land on it, yet land on it we do,


Therefore I would think the same code layout that says you have landed on a wall, will also detect the nasty and kill you.

Edited by Norman Sword, 21 February 2018 - 01:59 PM.

#19 IRF


    Advanced Member

  • Contributor
  • 4,106 posts

Posted 21 February 2018 - 02:09 PM

But Fire cells effectively behave the same way as Air cells in the Move Willy routine. It's only the Draw Willy routine which means that Fire cells kill him. And if we've changed the way that Fire cells kill him (so that he has to be drawn ON a Fire cell, rather than ON OR ABOVE), then I think it will be possible to clear a head-height Fire cell. In the same way that Willy can jump over an item at head-height without collecting it.

#20 IRF


    Advanced Member

  • Contributor
  • 4,106 posts

Posted 21 February 2018 - 02:53 PM

The cell_set_loop could be used in conjunction with my guardian code rewrite, which draws guardian attributes across more than one medium (whilst preserving the PAPER colour of each cell through which they pass).

That rewrite uses a similar principle of CALLing a subroutine four or six times (depending on whether the guardian is cell-row aligned), and I don't think that the B register is used by the guardian equivalent of the colour_me subroutine.

In fact, it could yield a further efficiency, because if a DJNZ command controls the loop then there would be no need for the DEC C (or in this case DEC B ).

Edited by IRF, 12 March 2019 - 11:16 AM.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users