Norman Sword Posted February 13, 2018 Report Share Posted February 13, 2018 (edited) Code at $8ebc change to original 8EBC call Butt LD A,($85CF)8EBF ld a,($85CF) ADD A,$108EC08EC1 AND $F08EC2 ADD A $108EC3 LD ($85CF),A8EC4 AND $F08EC58EC6 call $8E99 CALL $8E9C see the routine below8EC9 LD A,$028ECB LD ($85D1),A8ECE LD HL,$85D08ED1 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 point8E9E LD L,A8E9F XOR A8EA0 RL L8EA2 ADC A,$5C8EA4 LD H,A8EA5 LD A,($85D3)8EA8 AND $1F8EAA OR L8EAB LD L,A8EAC LD ($85D3),HL8EAF 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 February 14, 2018 by Norman Sword IRF, Spider and jetsetdanny 3 Quote Link to comment Share on other sites More sharing options...
Norman Sword Posted February 13, 2018 Report Share Posted February 13, 2018 (edited) 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 February 13, 2018 by Norman Sword jetsetdanny, Spider and IRF 3 Quote Link to comment Share on other sites More sharing options...
Norman Sword Posted February 16, 2018 Report Share Posted February 16, 2018 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 IRF, Spider and jetsetdanny 3 Quote Link to comment Share on other sites More sharing options...
IRF Posted February 17, 2018 Author Report Share Posted February 17, 2018 (edited) 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 February 17, 2018 by IRF Spider 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted February 20, 2018 Author Report Share Posted February 20, 2018 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! jetsetdanny and Spider 2 Quote Link to comment Share on other sites More sharing options...
Norman Sword Posted February 21, 2018 Report Share Posted February 21, 2018 (edited) 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,A9614 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 $0F9627 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 February 21, 2018 by Norman Sword Spider and IRF 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted February 21, 2018 Author Report Share Posted February 21, 2018 Would that code allow Willy to jump over a Fire cell at head-height? (I suspect it would.) Spider 1 Quote Link to comment Share on other sites More sharing options...
Norman Sword Posted February 21, 2018 Report Share Posted February 21, 2018 (edited) 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 February 21, 2018 by Norman Sword Quote Link to comment Share on other sites More sharing options...
IRF Posted February 21, 2018 Author Report Share Posted February 21, 2018 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. Spider 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted February 21, 2018 Author Report Share Posted February 21, 2018 (edited) 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 March 12, 2019 by IRF Spider 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.