'Don't Mind Your Head (While Walking Left)' Bug Fix for JSW

[IRF]

Here's a surprise for you all. Check out the attached file. The starting point is The Wine Cellar. Try to collect the item!

UPDATE: I noticed a minor 'glitch' in my first attempt at the bug fix, so I've deleted the file that was attached to this post. Please scroll down to post #8 in this thread, to get the updated file, in which I've sorted the problem! (N.B. The starting point in the updated file is The Beach, but it's not too far to wander to The Wine Cellar to test it out.)

FURTHER UPDATE: See also the discussion in post #12 of this thread (on the next page to this) - there's a further imperfection that requires fixing.

 

FINAL UPDATE: The code changes for the final version of this patch are documented later on in this thread:

 

http://jswmm.co.uk/topic/196-dont-mind-your-head-while-walking-left-bug-fix-for-jsw/page-4?do=findComment&comment=5588

 

The file now attached here is a copy of original JSW with the patch inserted as per the code changes in the above link.

Earth cell symmetry restored.TAP

Edited January 13, 2017 by IRF

[Spider]

This is the 'fix' of the check for his head being in the way of an earth cell when moving/jumping yes ? :)

[IRF]

Sort of. Unlike previous fixes, this patch doesn't render The Wine Cellar impossible.

Obviously the single item in the attached is impossible to collect, but that's because I've inserted a head-height Earth cell, precisely to demonstrate the point that I've fixed the bug which previously allowed Willy to walk leftwards through an Earth cell at head height.

However, you can see that it is possible to jump between the Earth cell platforms! i.e. onto ledges that are situated underneath Earth cells.

If you climb up the Water ladder that I've inserted to the right of Willy's starting point, in order to access the next level up, then you'll also see that this is a symmetrical fix. I've turned the right-hand Water cell platforms into Earth cells, but Willy can jump across safely whereas he wasn't able to before. For example, he can now access the exit from 'Emergency Generator' to 'Priest's Hole'! (Not to any avail though; he still can't climb down the East Wall.)

I've also tested jumping over the Barrel Guardian in 'Ballroom East', and crossing 'The Banyan Tree' in both directions (very tricky but doable, except in The Nightmare Edition because of a strategically-placed Fire cell!), and even jumping over the Bad Apple Guardian in 'At the Foot of the MegaTree' in The Nightmare Edition. All fine!

With the fix, Willy can also jump into cavities that are two cell-rows high and sited one or two cell-rows above his starting position. I've created a 'ladder' at the top of the right-hand chimney stack in Emergency Generator for you to test this out! (Navigate the starting position there to try it.) Jumping into a cavity that is one cell-row high is impossible though, as it should be (previously Willy could jump leftwards into such a cavity due to the bug).

It is also impossible for Willy to jump into a cavity that is two cell-rows high that is sited at a height lower than his starting position (again, this is how it should be; once he has dropped to a position that is lower than the start of his jump, then he is no longer jumping but falling, and has lost all horizontal momentum).

The quirkophiles amongst you will be pleased to know that other 'quirky features' such as jumping into Earth cells at leg-height, jumping through Innocent-Looking Blocks at head-height, and jumping through a 'standonable' cell that is adjacent to a Fire cell, are all still in operation! There are a few random blocks scattered around Emergency Gen which are handy for illustrating these.

EDIT: I would also add that it fixes the bug whereby Willy can jump leftwards through an overhead Earth cell, and also the bug that allows him to walk up a ramp leftwards through an Earth cell at head-height.

However, it doesn't stop him from walking (in either direction) up a ramp through an Earth cell that is located above his head. (There is no check in the code for Earth cells above Willy's head when he's walking up ramps. Or for that matter, Earth cells in the row beneath Willy - hence he can walk into the Earth cell at the bottom of the ramp in On Top of the House.)

Edited May 20, 2016 by IRF

[jetsetdanny]

Well done, Ian!  :)

 

Will you document the fix later on (the modifications to the code)?

[IRF]

Well done, Ian!  :)

 

Will you document the fix later on (the modifications to the code)?

 

I'll try and do a detailed description at some point, but in a nutshell the new code is inserted at #9700, called up from the 'Move Willy (3)' routine, and involves checking the 'Jumping Animation Counter' variable at #85D5, and comparing it against various values (which correspond with instances during a jump when Willy is descending, and is one increment away from being cell-row-aligned).

 

Then I inserted a check for Earth cells at head-height when Willy is moving left (analogous to the existing one in the code for Earth cells at head-height when he's moving right), to restore the symmetry to his movement.

 

I also relocated the 'Kill Willy' routine from #90B6 to #96F4, which I initially did to find space to be able to insert a 'lesser' fix within the Move Willy (3) routine.  However, in the end I had to put the new code elsewhere and jump to it anyway, so in hindsight I should have left 'Kill Willy' where it is.

 

The new code is far from efficient as there was plenty of space at #9700 to insert it (so for example there are lots of absolute jumps rather than relative ones).  Thus there is plenty of scope for you to put your optimisation skills to good use!

Edited April 22, 2016 by IRF

[IRF]

I've just noticed that there's a slight glitch with the fix.

 

If the game is ended abruptly while Willy is in mid-jump (by pressing SHIFT+SPACE), then sometimes when the next game is restarted, Willy cannot walk rightwards across a cell boundary.  He can walk leftwards across a cell boundary though, until he's tried and failed to walk right, at which point he gets stuck within the two cell columns that he is occupying, as if invisible Earth cells on either side were keeping him there.

 

I observed the above when he was stood on the right-hand side of The Beach, with a 'deep' block of Earth cells beneath him.  However, if there is a row of Air cells underneath the surface he is standing on (i.e. if he's on a platform that is only one row deep, such as the left-hand platform in The Beach), then he falls through the floor when he tries to walk rightwards along the platform across a cell boundary!  (That doesn't happen if he walks leftwards though, but if he then turns round and walks right then it happens as soon as he tries to proceed from Animation Frame 3 to Animation Frame 0.)

 

Finally, during this period of 'misbehaviour' (from the point at which he is first stopped in his tracks or briefly whilst he's falling through the floor), his head takes on the colour of the Air Ink (so it's normally invisible except in a non-Rope room, where Air Paper and Air Ink colours are mis-matched).

 

It's easy to bring this strange behaviour to an end though - just hit the jump key!

 

When the phenomenon occurs, it seems as though his colour attributes are located one cell-row beneath where his sprite is drawn.  And his physical presence must be one cell-row below his sprite too, hence he is stopped from proceeding by the blocks, or falls through a single-row platform.

 

I think that it only happens if the game is abandoned at a point when the Jumping Animation Counter has reached one of the values that the new code checks for (12, 15 or 17; #0C, #0F or #11 in hex), in order to decide whether to allow Willy to move left or right past the cell boundary to be caught by a 'ledge'.

 

Whenever Willy jumps, the command at #8F97 resets the Jumping Animation Counter to zero, hence jumping brings the behaviour to an end.  This also means that if we're confident that the strange behaviour only occurs when re-starting the game (after the previous game has been abandoned mid-jump), then the simple fix would be to initialise the Jumping Animation Counter (#85D5) to zero at the start of every game.

 

However, I'm concerned that there may be circumstances during a game when the Jumping Animation Counter might be left at a value that triggers the strange behaviour. e.g. when Willy jumps onto (or off) a ramp to (or from) an 'intermediate' (i.e. not cell-row aligned) y-position?  Or perhaps when Willy jumps off a rope, or he jumps onto a rope and climbs up to emerge in the the next room (without performing another jump, which would reset the jump counter to zero)?

 

Also, I wonder if it might be occurring because I've made some error in the way in which I've implemented the fix, so perhaps someone could 'mark my homework', so to speak, especially with regards to whether I've moved the code about correctly (i.e. are relative jumps still in order, etc)?

 

It's strange that it's only triggered (at least initially) when Willy walks right, not left.  That in particular makes me wonder whether I've made an error - because the fix is notionally the same in both directions - although having said that, there is an inherent asymmetry about how the coordinates are assigned in the Move Willy routine, with (x,y) being the coordinate of the top-left cell that Willy is occupying.

 

EDIT: I've created a couple of .rzx files (attached) which illustrate the two variations of the glitch.

Bug Fix Glitch 1.rzx

Bug Fix Glitch 2.rzx

Edited August 1, 2016 by IRF

[IRF]

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

[IRF]

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

Edited April 22, 2016 by IRF

[IRF]

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.

Edited August 1, 2016 by IRF

[IRF]

 

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

 

 

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

 

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

Edited April 22, 2016 by IRF