IRF

The sunglasses emoji was meant to say "Dec B"!

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 ).

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.

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

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!

That will make the whole screen turn black, won't it? If you only want to disguise Willy's feet under the portal during the decreasing air effect, then instead of having the existing commands (#9071-#9076) which overwrite the cells (addresses #58F3-#58F4) with black INK, you could print a pair of ASCII space characters over that part of the screen's pixel file (set DE=#40F3, C=02, IX=#FE00, then CALL #92BA).

I've just noticed a bug/glitch/inconsistency in the way that the 'Swordfish' routine is executed at the end of the Final Barrier. When Willy enters the portal (unless you're playing in Cheat Mode, of course), his sprite appears above the portal which displays the Swordfish icon. There is also a command which overwrites the attributes of the two cells underneath the portal, in order to disguise Willy's feet (so that he doesn't appear to be in two places at once!) However, once the points start to be ratcheted up as the remaining air supply is counted down, Willy's feet are still visible (in blue INK on black PAPER), because the pixel display for those two cells isn't wiped, only the white INK attribute. **** Incidentally, the green PAPER attribute of the cells occupied by Willy's lower half when he is drawn above the Swordfish would possibly look a bit better if cyan PAPER was used (as is the case for the upper half of his sprite at that point).

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?) 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.

You presumably also need to change the way that #8EBC is CALLed slightly (compared with the existing code), so that if Willy is underneath two wall tiles, both can be bashed away simultaneously. (If it was simply tagged onto the existing subroutine at #8EBC, then the check for the wall tile above Willy's left-hand side would cause a RETURN from the 'Move Willy' routine before it's had chance to 'reverse crumble' the wall tile above Willy's right-hand side.) Nice idea to activate the effect via a spare border bit. :) Does that now mean that all the border bits have been put to good use in your file, or do some remain unused?

Collecting the top-left item in Top Landing in your third file is a nice little puzzle. :-) Presumably the 'headbutt' code works in a similar way to the crumbly code, except that it's executed whenever #8EBC is CALLed, and it goes through the pixel-rows 'in reverse'? **** 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.

Thanks Norman! It's a cool effect! I notice that wall tiles can be headbutted away by Willy jumping sideways against them as well. (EDIT: Sometimes, depending on what height Willy is in the jump when his head hits the wall tile.) You could have a challenge whereby Willy has to quickly remove an overhead wall tile in order to be able to jump over an oncoming horizontal guardian that would otherwise block his progress. EDIT: Kind of like this - see mockup screenshot attached. If Willy keeps walking left then he can't reach the end of the overhead wall in time to jump over the horizontal guardian, but he has time to clear a couple of overhead wall cells beforehand, so that he can do a vertical jump and clear the guardian. Note that the starting position of the horizontal guardian has been moved further left, to allow Willy enough times to chip away at a pair of overhead wall cells eight times and create a hole, before it reaches him. (Note also that in this instance, the adjustment to the guardian's starting position may have consequences for the toilet run, but it illustrates the idea.)

It was just a random idea that popped into my head whilst studying your optimised Crumbly code! 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. EDIT: Obviously we're talking in the context of the wall behaviour having been made symmetrical.

When Willy jumps up and hits his head on an Earth block, he is immediately ejected back down, but it doesn't seem to do him any harm. I guess he has quite a hard head - especially with his hard hat on. This got me thinking about an idea for a new MM cell type - when Willy bounces off a 'Soft Earth' cell from below, a variation on the Crumbly cell routine could be executed, removing pixel-rows from the bottom up, but without the upper pixel-rows moving down into their place - then once all eight pixel-rows have been 'mined away', the cell is replaced with an Air cell. Fits in with the mining theme?

Thanks Norman - silly mistake I made using LD A,(HL) instead of LD A,L (picking up an actual value from the item table, rather than picking up the index pointing at that value). I notice the little optimisation at the end of the item-filter loop as well. :) Hopefully with those edits applied, the 128 room version will work too.

Another caveat - the last item listed in the lower set's room number must not be equal to the first item listed in the upper set's room number modulo 64 (or vice versa), otherwise the item-filtering loop will not terminate and items will jump across the 'set boundary'! So it's probably safest to have the items strictly listed in room number order (although it might be a bit of a pain to set up/edit the item table in that way, so it would be wise to ensure that you're happy with the item distribution throughout the layout beforehand).

Extrapolating for a 128 room game (again, I've not tried this out yet!): Items have to be sorted into room number order beforehand (i.e. by the game designer, manually in the hex editor). Or at very least, all of each room's items must occupy adjacent entries in the item table, and entries for Rooms 0-63 must all come before entries for Rooms 64-127. This is the new 'Item Filtering' routine, CALLed from the Room Setup code - the first part © Norman Sword: LD BC,(#A3FE) ; #A3FF = total number of items as before, also start of items for Rooms 0-63 ; #A3FE = start of items for Rooms 64-127 LD A,(#8420) ; current room number AND #40 JR Z,lower_set LD B,C ; adjust B and C for LD C,#00 ; upper set of rooms/items lower_set: LD L,B LD H,#A4 filter_loop: LD A,(#8420) XOR (HL) AND #3F JR Z,match_found INC L LD A,L CP C JR NZ,filter_loop ; EVERYTHING FROM HERE ONWARDS IS THE SAME AS FOR THE 64 ROOM VERSION IN THE PREVIOUS POST ; If we get here, then we have been through all the item table entries, and there are no items (collected or uncollected) to consider in this room: LD A,#C9 LD (#93D1),A ; disable the Item-drawing routine whilst Willy is in this room RET match_found: LD A,(HL) LD A,L LD (#93D2),A ; value used to initiate the item-drawing loop in this room find_last_item loop: INC L LD A,(#8420) XOR (HL) AND #3F JR Z,find_last_item ; If we get here, then HL is pointing at the first item for the next room: LD A,(HL) LD A,L LD (#9452),A ; value used to terminate the item-drawing loop in this room ; Now restore the first byte of the Item-drawing routine: LD A,#21 LD (#93D1),A ; enable the Item-drawing routine whilst Willy is in this room RET ------------ Then the item-drawing/collecting routine (#93D1, CALLed from the Main Loop) needs to be amended in accordance with Norman's post: http://jswmm.co.uk/t...age-6?do=findComment&comment=8871 with minor additional amendments as follows: 93D7 BIT 6,(HL) ; has the item under consideration been collected yet? 93D9-DF NOP x 7 93E0 JR Z,#944F ; if so, then consider the next item for this room (or terminate the loop if we've already considered all this room's items)

Taking up the idea in this post: http://jswmm.co.uk/topic/184-guardian-aura-bug-fix/page-5?do=findComment&comment=8867 This is for a 64 room game, and beware that I haven't tried it out yet! Items have to be sorted into room number order beforehand (i.e. by the game designer, manually in the hex editor). Or at very least, all of each room's items must occupy adjacent entries in the item table. This is the new 'Item Filtering' routine, CALLed from the Room Setup code: LD A,(#A3FF) LD L,A LD H,#A4 filter_loop: LD A,(#8420) XOR (HL) AND #3F JR Z,match_found INC L JR NZ,filter_loop ; If we get here, then we have been through all the item table entries, and there are no items (collected or uncollected) to consider in this room: LD A,#C9 LD (#93D1),A ; disable the Item-drawing routine whilst Willy is in this room RET match_found: LD A,(HL) LD A,L LD (#93D2),A ; value used to initiate the item-drawing loop in this room find_last_item loop: INC L LD A,(#8420) XOR (HL) AND #3F JR Z,find_last_item ; If we get here, then HL is pointing at the first item for the next room: LD A,(HL) LD A,L LD (#9452),A ; value used to terminate the item-drawing loop in this room ; Now restore the first byte of the Item-drawing routine: LD A,#21 LD (#93D1),A ; enable the Item-drawing routine whilst Willy is in this room RET ------------ Then the item-drawing/collecting routine (#93D1, CALLed from the Main Loop) needs to be amended in accordance with Norman's post: http://jswmm.co.uk/topic/184-guardian-aura-bug-fix/page-6?do=findComment&comment=8871 with minor additional amendments as follows: 93D7 BIT 6,(HL) ; has the item under consideration been collected yet? 93D9-DF NOP x 7 93E0 JR Z,#944F ; if so, then consider the next item for this room (or terminate the loop if we've already considered all this room's items)

Thanks Norman! That seems quite a lot simpler than the original routine!

There's a perfect asymmetry about it, because it's actually a LD L,A that has to be deleted at the start, but a LD A,L that must be inserted at the end!

I think you need to NOP out the LD L,A at #93D6 as well (otherwise whatever value A retains from its previous use will be copied to L!) Less importantly (I'm being pedantic now!), that should probably read "ld b,c ;set b=upper key offset". **** Off-topic (or rather, even more off-topic!): I meant to ask - how do you keep track of when all the pixel-rows have been cleared from a crumbly? Does a temporary variable count down the number of rows deleted (until the variable reaches zero), or does the subroutine check the status of all eight rows in each time-frame?

This should allow the old version with a possible 256 items: 943E LD A,D 943F RLCA 9440 RLCA 9441 RLCA 9442 AND #08 9444 ADD A, #60 9446 LD D,A 9447 PUSH HL 9448 LD HL, #80E1 944B CALL #9699 944E POP HL 944F INC L 9450 LD A,L 9451 CP #00 9453 JR NZ, #93D7 9456 RET

I made an error in the above, now struck out. Also, in terms of fitting in the additional command LD A,L - if the LD A,(HL) at #943E is replaced with a LD A,D then one fewer RLCA command is needed at #943F-42, which frees up one byte in close proximity to #9450.

You could apply the same principle - i.e. at the Room Setup stage, update two variables which bookend the 'Draw the items' routine - to extend this idea from one of your earlier posts (on the subject of reducing 'overheads'): If both the 'start search' and 'stop search' offsets were determined at Room Setup, then the length of the item-drawing loop would be fixed for each room, eliminating any need to search for an item-room match during execution of the Main Loop. (Thus reducing overheads and speeding up the game?) EDIT: In its simplest form (for a 64 room game), the above would require two additional steps: 1) Sort the item list into room order, as per your quote above; 2) Take the existing code at #93D7-#93E1, and separate off the two checks which are currently performed simultaneously - the check for room numbers to go into a new 'item-filtering' subroutine called from Room Setup, whilst the check of whether each item has been collected yet (to determine whether to draw or collect it) would be retained in its current location. (N.B. This is a classic case of a trade-off between byte-efficiency versus speed of execution.) The new 'item-filtering loop' at Room Setup would search for the first room number match in the item list, and use the corresponding item index to define the initial value of L at #93D4. (Incidentally, that could just be a direct LD L,#00 command, ditching the following LD L,A.) When the 'item-filtering loop' subsequently finds a room number which doesn't match, then go back one item and use that item index to overwrite the operand of the newly-inserted CP #00 operation at the end of the item-drawing loop (as suggested by Norman, but I think he forgot to insert a LD A,L beforehand, because COMPARE operations always test the A register?) To handle a room with no items, if no matching entry in the item table (whether for a collected or uncollected item) is found for the room Willy is about to enter, then the 'item-filtering loop' could overwrite the address #93D1 with a RET command. That would then have to reinstated with its proper value every time a room number match (collected or uncollected) was detected by the item-filtering subroutine of the Room Setup routine. **** Furthermore, the above could be combined with Norman's optimised 128 rooms item-handling code. The values stored at #A3FE-FF could determine the start and end points of the 'item-filtering loop' (to decide which half of the items are to be considered, based on Bit 6 of the room number), and then the item-filtering loop could in turn define the start and end points of the item-drawing loop, as per the suggestion above.

Ah, so my previous interpretation (i.e. a maximum of 128 items in each set of 60 rooms) wasn't quite right. You could have, say 60 items in the first set of 60 rooms, and 196 items in the second set of 60 rooms, if you wanted to. One small query regarding this excerpt: I believe the labels should read: ; b=lower_key offset ; c=upper_key offset ? (Because the LD BC, (#0000) command is 'little-endian' in its operation.)

This element in the 'Jet Set Mini' entry (the part in brackets) is not necessarily true: "One room, otherwise inaccessible, can be reached by using the Writetyper cheat (the player will get killed repeatedly on entry)." It is quite possible to enter 'Cheating?' without being killed upon entry, depending on whereabouts Willy enters that room. In fact, it's possible to then use Writetyper to teleport back out again, but Willy will be yellow (and therefore unable to collect items) for the rest of the game! **** It's worth noting that your screenshot and Pavel's map show the two different room names for the Attic! On the other hand, neither of you have captured the occasional appearance of Maria at the helm of the 'ghost ship' in 'At the Beach'! ;)