IRF

Okay, so I was right that you mocked up the images rather than using snapshots, although in doing so your intention was to recreate what is seen on screen!

I'll try and dig one out. I take it you're aware that Willy can walk THROUGH a Fire cell on the edge of a room, while entering the room, BUT ONLY if he keeps the relevant 'walk' button depressed? Apparently it's because the check for nasties doesn't occur during the 'zeroth time-frame' in a room. (It may, or may not, be a related phenomenon to the one you inquired about.)

Re: the former, I presumed you must have 'mocked up' the images in your disassembly to illustrate the point!? They don't resemble what is displayed on the screen during the jump! (Although they do demonstrate the sequence in which the checks/coordinate updates take place.) Re: the latter, would it be a simple affair to rearrange the code so both x- and y- coordinates are updated before the check for Fire cells occurs? Or would that have unintended consequences?

I'll try and do an rzx recording when I get a chance, to demonstrate this. By the way, something else that I've though of - if an arrow is placed before a guardian in the list for a room, and if the arrow's flight takes it into the path of the guardian, then it will kill Willy even if the guardian is NOT White. So to be on the safe side, the arrow should be placed AFTER the guardians in the list.

And another suggestion for your TODO list - you could mention the fact that the 'Don't Mind Your Head' Bug can cause Willy to get stuck inside Earth cells (in at least two places that I can think of, namely Dr Jones... and The Wine Cellar, via The Forgotten Abbey) - forcing the player to abandon the game!

Another observation: In the original game [and with Andrew Broad's suggested alternative patch], both of those routes (when going leftwards) are made considerably easier because the ILB code rapidly speeds up Willy's descent as soon as his head becomes aligned with the Earth cell that sits above the two-cell Air gap into which he is jumping. With my version of the patch in place, the timing of either jump is much more critical, as Willy has to fall at 'normal speed' until he is almost aligned with the gap, before he can proceed forward to land on the 'ledge'. Banyan Tree is particularly difficult (jumping from the ledge between the Cyan Computer Chip and Magenta Gremlin), as he has to 'step back' above the Chip and jump left whilst the Gremlin is still quite high up in the intermediate cavity, in order to safely jump into the gap.

Scenario 1b is actually present in original JSW in The Forgotten Abbey (jumping from the top of the ramp), and allows Willy to subsequently walk through head-height Earth cells and exit directly onto the conveyor in The Wine Cellar. However, if he doesn't keep the left key pressed until he is clear of the Earth cells on the right-hand edge of The Wine Cellar, then he can get stuck (because of the conveyor and the Earth cells above him), meaning the player has to abandon the game! So it's definitely a bug that's worth fixing - at least in terms of preventing him walking leftwards through Earth cells (a bug which also allows Willy to get stuck in the Dr Jones elephant's head in the original game!)

I have inserted the above (11 bytes) into the Main Loop (replacing the redundant 'Screen Flash Counter' code in the attached file), which has resolved the last remaining 'structural' problem with the patch. There is still plenty of scope for the patch to be made more byte-efficient, though. Or indeed, other options considered (such as Andrew Broad's suggestion). New Bug Fix Final.z80

There does seem to be a mismatch between Willy's 'physical presence' (the room cells that take on his attributes), and where his sprite is drawn on the screen. Certainly during jumping - if you take the 'Through the Wall' illustrations in the Bugs section of your Manic Miner disassembly, they certainly do give a better representation of how he interacts with the various room elements. However, if you study Willy's jumping by pausing the game at each time-frame during a jump, his sprite appears on screen at a higher y-coordinate (during the descent from the highest point of the jump), than is shown in your illustrations. e.g. When Willy is cell-row aligned in his 'left-facing animation-frame 0', whilst directly above a Fire cell (and he would be killed, save for a certain part of the code, which instead allows him to fall into the adjacent Earth block). If you watch that sequence in-game, his sprite at animation-frame 0 is several pixels above the Fire cell, and at the next time-frame his sprite is sitting directly above the Earth block and he has cleared the Fire cell altogether - by that point he's in 'left-facing animation-frame 3' and occupying the next pair of cell-columns. So it appears illogical, watching his sprite, why he should then fall into the Earth block!? EDIT: Perhaps this explains why Willy can land on certain guardians and jump safely away IF the player keeps the jump key depressed; whereas landing in the exact same spot kills Willy if the player has let go of the jump key!

Going further into 'quirky territory' (which is admittedly rather off-topic for a thread that started off trying to eliminate a quirk!), it would be possible to devise a bit of code, analogous to that at 36540, but which had the opposite effect! i.e. if Willy becomes cell-row aligned (only occupying two rows) with his legs occupying an Earth cell (i.e. he has just jumped up and through an overhead Earth block, and is nearly at the top of his jump), then the code could rapidly adjust his y-coordinate upwards by one cell-row, depositing him on top of the Earth block! This would effectively allow him to jump to a normally unreachable height! (Three rows above his starting point.). A new kind of Superjump!!

To illustrate the point in bold, please see the attached file (my Bug Fix is in place in this one!) I've inserted a Black static guardian into the Earth cell above the 'ledge', so that the guardian is colouring in the Earth block (and the ones adjacent and above), but the two horizontal rows of Black pixels in the guardian's sprite are placed such that there is no 'pixel coincidence' with the Earth block (and so no Infinite Death Scenario upon start-up!) Willy can jump rightwards and land on the ledge safely, illustrating that his sprite doesn't truly enter the Earth blocks at any point in the jump. However, if you wander down the ramp to the left and jump through the Innocent-Looking Block (which contains the same Guardian with the same 'parallel lines' sprite, just lowered down accordingly to be embedded within the ILB), then Willy is killed - as his sprite enters the Earth cell causing his pixels to collide with the guardian's pixels! (N.B. If Willy walks up to stand adjacent to the right of the ILB, his sprite turns Black (because he is within the lower guardian's 2x2 'square of influence), but he is of course blocked from walking leftwards into the block due to the patch, so he can't be killed in that way.... Unless, that is, the previous game was abandoned at a certain point mid-jump; I've not fixed that aspect yet!) New Bug Fix pixel test.z80

See attached - a single 'leafy' Water cell has been added under the end of the middle Earth block platform in Under the MegaTree. If Willy walks forward two animation-frames from his starting position when the game is first loaded, turns round (so he's facing left with his legs together) and jumps leftwards, then the quirk under discussion allows him to access the 'Forbidden Holy Ground' in At the Foot of the MegaTree! EDIT: The other attached file illustrates the point I made a couple of three posts back about Emergency Generator. Jump rightwards from the starting point and Willy can exit to Priest's Hole. (However, if he jumps to the top of the stack first, then he can't make the jump.) P.S. Obviously, these files are based on the 'unfixed' game engine! overhead jump under megatree test.z80 emergency gen test.z80

Andrew, am I right in thinking that this is the quirk that allows Willy's sprite to pass leftwards through an Earth block at leg-height? EDIT: I don't so much mean leg-height, but the Earth block is lower than head-height by the time he starts to pass through it (his hat at least is projecting above the top of the Earth block). Immediately beforehand, he is cell-aligned both horizontally and vertically - he is in (left-moving) animation-frame zero, adjacent to a single-height Earth block, with the upper half of his sprite occupying the same cell-row as the block, and he is still in the 'ascending' part of his jump. There is no check for an Earth cell adjacent to his head on the left, and so nothing to prevent his onwards horizontal motion. But then in the next time-frame, as well as having moved 'into' the Earth block [although again, there is no pixel-insertion into the block at this stage, as he's in left-moving animation-frame 3 in which only the right-hand of the cell-columns he occupies has filled-in pixels], he has also moved up by one increment in the jump. As a result, the top-left cell occupied by Willy's sprite [which by now occupies three rows of two cells] does NOT contain an Earth cell*, so the 'ILB' code at 36540 that normally dumps him downwards in these circumstances does NOT kick in, and his jump carries on upwards - with his legs entering the Earth block. (* Assuming it's a single Earth block that we're considering, or at least only a single-row Earth platform - I think Willy can jump through the middle Red platform in Under the MegaTree, for example.)

I've just added the above point to post #3, but I thought it worth emphasising in case people don't notice the edit.

That's another possibility I suppose, although it's a bit more 'in defiance of the natural laws of physics'. When Willy jumps onto a ledge underneath an Earth block, his 'physical presence' (2x2 cell) is only inside the Earth block for a single time-frame, before being ejected one cell-row downwards (by the same bit of code that causes the ILB effect, at 36540). Furthermore, at that instant he is in animation-frame 0 (when moving right; or 3 when moving left), so his filled-in sprite only occupies the 'back column' of his 2x2 cell, and there is no pixel overlap with the Earth block. As a result, it looks like he has just been caught by the edge of the ledge - which he has, but without the patch in place he doesn't end up there because the physics of jumping moves him on both horizontally and vertically in each time-frame. **************** Note that in Emergency Generator in the classic game, he can pass through the Earth cell 'ledge' underneath the top-right cavity, if he jumps from a lower position within the right-hand chimney stack (i.e. from one or two cell-rows down, but not from the top of the Water cell stack). But then there is nothing to catch him as he falls through the Earth cell, so he still falls to his death (or possibly hits the vertical column of Fire cells?) However, if there was an Earth block located immediately to the left of the uppermost Fire cell (underneath the existing 'ledge'), then he would get caught by it, and end up standing inside the 'ledge' Earth cell (probably in his 'legs together frame of animation). He could then jump straight up by one cell-row, and walk right to emerge in Priest's Hole!

There is a residual problem with the Bug Fix. See the attached rzx recording, with starting point set to the Swimming Pool. You will see that at the start of the game, Willy is blocked from walking through an Earth cell at head height in either direction. He then jumps onto the rope (presumably catching onto it when the Jumping Animation Counter has reached a value of either #0c, #0f or #11), and climbs up to emerge in The Orangery. He can then walk left or right through Earth cells at head height - because the Jumping Animation Counter still retains a value that means the Move Willy (3) routine bypasses the check for Earth cells at head height (on either side of Willy). Finally, he jumps up and down on the spot, after which he cannot walk left or right through the head-height Earth cells (because jumping resets the Jumping Animation Counter to zero, and then it progresses through to a value of 18 at the end of the jump - not a value which causes the CP (HL) command to be bypassed in the code). This all happens within the same game, without restarting (although it doesn't happen every time Willy jumps onto the rope; it depends what stage he has reached in the jump when the rope intercepts him). So initialising the Jumping Animation Counter at #85D5 to zero at the start of every game wouldn't necessarily iron out this latest 'crease'. However, I was thinking that a bit of code in the Main Loop might do it, as follows: Load up the Airborne Status Indicator at #85D1. Check: is it '1' (meaning that 'Willy is jumping')? If not, then reset the Jumping Animation Counter at #85D5 to zero. (But if the Airborne Status Indicator does have a value of 1, then the command which resets the Jump Counter to zero is bypassed via a relative jump.) What do you think?

Actually, he might be able to do that with the 'perfect patch' in place (i.e. the patch as it is now that I've corrected it), if the game is restarted whilst he's in mid-jump (and the jump counter remains at a certain value). Ditto when walking left! With the 'imperfect patch' (as it was before I 'fixed the fix'!), he could probably have walked rightwards* through an Earth cell at leg-height, provided there was no Earth cell underneath it! *(But only rightwards, because I only cocked up the 'Move right' element of the new code.)

Question: on the toilet dash, the code at around #8A06 "sets Willy's animation frame at 85D2 to 1 or 3 if Willy is running to the toilet or already has his head down it; this has the effect of moving Willy at twice his normal speed as he makes his way to the toilet". But doesn't he display animation frames 0 and 2 when he's on the toilet dash? (i.e. The two 'intermediate' frames, so it looks like he's gliding without moving his legs at all.)

Further to the above, I also reckon that if an arrow were to pass through Willy's head when he's in such a state (non-White head), then he wouldn't be harmed. (Although other guardians would kill him if his head collided with them, because collision-detection for all other guardians is pixel-based.) Oh, and I have seen similar behaviour displayed before in other circumstances - namely, when Willy's starting position is set such that it 'wraps around' the edge of the screen...

Technical query: As a result of the way that I have implemented the patch, the command at #90A1-90A3 has been placed after the commands at #90A4-90A6. Is there any reason why this would be a problem? #90A1-90A3 ... LD A, (#80B2) - loads the attribute of the current room's Earth cell to the A register. #90A4 ... OR A - doesn't appear to change the value of A (but according to the Manic Miner disassembly's description of the equivalent instruction, it 'clears the carry flag for subtraction'). #90A5-90A6 ... SBC HL, DE - 'subtract with borrow' (which directs the HL register to the cell above the one it was previously considering). The reasons that I have swapped the commands around in the patch are: (1) so that #90A4-90A6 isn't bypassed by the new code when the Jump count is at certain values - which had caused the previously reported 'glitch'; (2) if the command at #90A1 (setting the A register to the value of the Earth cell attribute) were kept in situ, then in the new code at #9700 the value of A would be overwritten by the current value of the Jumping animation counter at #85D5, and so upon jumping back to the existing code at #90A7, the check CP (HL) - 'Is there an Earth block in the cell pointed to by HL?' - would be comparing the current attribute of 'HL' against the wrong value of 'A'. (i.e. the value of the jump counter instead of the attribute byte defined for the room's Earth cell). EDIT: I suppose if transposing the two chunks of code #90A4-90A6 and #90A1-90A3 is potentially a problem (the 'A' in 'OR A' is making me a bit nervous!), then the LD A, (#80B2) command could be inserted twice. (i.e. once in its original location, and again immediately prior to the CP (HL) check.) FURTHER EDIT: In the end, the above didn't seem to cause a problem, so I left it as was (with the LD A command after the SBC). I don't think the OR A command (or subsequent SBC) does anything with the value of 'A'; its purpose is just to clear the carry flag, as the MM disassembly points out.

I've fixed the 'glitch' in the attached file, as far as I can tell! (EDIT: Although I haven't yet tested whether Willy can still jump rightwards and get caught by the ledges, I don't see why he won't be able to.) The mistake I had previously made was that the commands at #90A4-90A6 were being skipped, when the Jumping Animation Counter was set to certain values. (The Jumping Animation Counter is normally brought to a value of 18 at the end of a jump, but if the game is abandoned mid-jump then it can be left at a lower value, until Willy makes a jump in the next game which resets it to zero.) As a result, when Willy tried to walk rightwards across a cell boundary, the command at #90AA was setting his coordinates in the attribute buffer to one cell-row lower than they should be. This was manifested in the physics of his left-right movement being altered - the 'check for Earth blocks' code was then picking up cells located one row lower than the ones they were supposed to be testing. [incidentally, this might have allowed him at that stage to walk rightwards through an Earth cell at head height, although I didn't test that]. It also manifested itself in the coordinates of the cells that took on Willy's colour attributes, being one row lower than they should have been. However, the cells in which Willy's sprite was drawn did NOT drop by one row, curiously enough. (This caused his head to take on a different colour to his legs!) Anyway, I've fixed it in the attached file, by moving the commands at #90A4-90A6 prior to the call to the new code at #9700 (code that checks the value of the Jump counter). As it happens, this is the approach that I had already taken for 'Willy is moving left' - because I had to insert new code to check for Earth cells at head height in that direction [such a check being absent in the original game], and so the way in which I did that did not bypass the equivalent commands. Hence the asymmetry in the earlier file! Just to be on the safe side, it might be worth inserting an 'Initialise the Jumping animation counter to zero' command into the 'Start the Game' routine. (The code probably needs optimising anyway!) One more thought (again I haven't tested this) - if an item is 'imbedded' in between Earth cells below Willy's feet then it's normally uncollectable. I believe that due to the previous 'glitch' in this patch, it might have been possible for Willy to collect such an item, without actually falling onto it - because his 'White' attributes would have projected downwards into the Air cell containing the item! (And conversely, an item at head-height beyond the next cell boundary to the right couldn't be collected by walking into it, because Willy's head would have turned non-White at the point he crossed the cell boundary!) New Bug Fix Properly.z80

Glitch variant 3 attached. Now Willy can be killed by the right-most Crab (Fire cell), even though it's buried two cell-rows below Willy, if the previous game was abandoned mid-jump (leaving the value of the Jumping Animation Counter at a value that causes part of the Move Willy code to be bypassed). Bug Fix Glitch 3.rzx