IRF

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'! ;)

So if I understand correctly, in Norman's latest file the item definitions for Rooms 0-63 are stored at Offsets #80-#FF in pages #A4 and #A5 of the code, whereas item definitions for Rooms 64-127 are stored at Offsets #00-#7F on the same pages? If this was ever developed further with 128 (or 120) fully independent rooms (rather than the new rooms 'shadowing' the original rooms), then may I humbly suggest that a similar arrangement could be put in place to what Andrew Broad did in his game 'Party Willy'. Namely that Rooms 64-127 are located on the far side of Maria, and then an AND #7F gate is inserted in between the two commands at #9422 and #9425 (original addresses) in the 'Draw the items' routine. This has the effect of splitting the game into two halves - the player must complete the first 64 rooms (collect the first 128 items) before they are able to proceed to the second half. For reference: http://www.worldofspectrum.org/pub/sinclair/games-info/p/PartyWilly_TechnicalNotes.txt

Having thought about the above, I'm not sure if it's feasible to come up with an arrangement that's more byte-efficient than the current one. Firstly, the direction of travel for horizontal guardians would have to be determined from Bit 2 of Byte 04. But there's no easy way of checking when the value in Byte 4 has spilled over past Bits 0-2, other than by checking for the individual values 08 or -01 (#FF). The Carry Flag wouldn't respond in these circumstances. Maybe if all the values for animation frame were doubled (and the 'Draw the horizontal guardians' routine was amended accordingly, with an additional RRCA inserted at #8DD0), then the Half-Carry Flag could be used. But I don't think there are any Z80 instructions (conditional jumps etc) which are determined by the status of the H Flag. You would need to fundamentally change the function of Byte 04 for horizontal guardians - edit all the horizontal guardian data, so that Bits 5-7 holds the animation frame (with Bits 0-4 unused, although perhaps they could be recycled for other purposes?), rewrite the 'Move the horizontal guardians' routine in accordance with my previous post, and then NOP out the three RRCA's in the 'Draw the horizontal guardians' routine at #8DCE-#8DD0. Probably not worth the hassle.

The above approach may be more appropriate for optimising the horizontal guardian movement in Manic Miner (i.e. having a shared set of commands for both left and right movement), since the guardians 'face themselves' in their sprite pages rather than being 'back to back', and as a result there would not be a need to swap the two halves of each sprite page. I haven't tried it out yet though.

That would make sense about the mediaeval scrolls. I haven't had time to process the rest of the previous post yet (will do so later).

It's interesting that the second switch doesn't work at all for dispatching Kong, but with the first switch, it's the exact opposite: you don't need to flip it at all, because the opening wall collapses as soon as Willy enters the cavern! None of the above would happen if the Cell Graphics Bug was fixed! It's a rare case where the CGB has a side effect that isn't purely aesthetic!

Did you try to kill the Kong Beast?

POKE #CE5E, #06. There are some strange, indirect, perhaps unexpected side-effects from this one...