Jump to content
Jet Set Willy & Manic Miner Community

Idea for a new cell type in Manic Miner


IRF

Recommended Posts

Code at $8ebc

 

          change to             original

8EBC  call Butt               LD A,($85CF)
8EBF  ld a,($85CF)       ADD A,$10
8EC0
8EC1                             AND $F0
8EC2   ADD A $10
8EC3                             LD ($85CF),A
8EC4  AND $F0
8EC5
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)
8ED3 RET

 

; 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
8E9E LD L,A
8E9F XOR A
8EA0 RL L
8EA2 ADC A,$5C
8EA4 LD H,A
8EA5 LD A,($85D3)
8EA8 AND $1F
8EAA OR L
8EAB LD L,A
8EAC LD ($85D3),HL
8EAF RET

 

; a very vague Butt routine

Butt:

        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

Butt2

       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

      ret

 

;==========================================================================================

 

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
Link to comment
Share on other sites

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  >>>> 
8DFE  INC HL 
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

8DFC

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
Link to comment
Share on other sites

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

 

 

 

 

COLLAPSE_FLOOR.TAP.tap

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

 

YET

 

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   

 

and

 

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

 

 

 

becomes

; b=the offset for the ramp

95f8

      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

cell_aligned

     ld de,31                 ;offset to next  

cell_set_loop

     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

 

colour_me

          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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.