IRF

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

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

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!

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

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

Thanks Andy, I'll have a play later. I wonder if I increase the value of 35682 (#8B62) from zero, to anything up to #FF, can I increase the delay further by a factor of up to 256(!)?

Do you know a command that would have the effect of causing such a delay? EDIT: As it happens, over in a PM I've just been discussing the 'DJNZ' command. It works on the 'B' register. I'm now wondering if that was inserted after the register 'B' had been set to a high value (such as #FF), with the operand of the DJNZ set to itself, then maybe it could cause quite a delay? e.g. at 35343, insert 'LD B, #FF. Then at 35345, 'DJNZ 35345'. The command at 35345 would then take the value of B (which would be initialised to #FF each time the program passes through the main loop) and decrement it by one, then jump back to itself and keep decrementing B until it reached a value of zero, before proceeding with the rest of the program?

Question: Is there a way of seriously slowing down the JSW game engine, so that one can study the exact pixel placement of Willy at each stage during a jump? i.e. so the screen image is effectively still for a few seconds during every frame of animation? I was thinking some sort of command could be placed in the Main Loop which delays things? Placing him in a field of Water cells whose pixels consist of a grid of horizontal and vertical lines will also help with this task.

[Pedantry alert!] I've just noticed an error (I think) in the disassembly. The entry at #8820-8827 is described as "Copy the attribute bytes for the top two-thirds of the title screen from 9800 to the attribute file". In fact, the LD BC command at #8823 copies the attribute bytes for the entire title screen from #9800 AND #9A00, as determined by the operand #0300. (So it sets the attributes for the bottom third of the title screen, as well as for the playing area.)

If you don't mind having a shorter Title Screen tune - or none at all - then up to 99 bytes could be available for other purposes where the Title Screen tune is currently located in the code (#85FB to #865D). The value 'FF' at #865E terminates the playing of the music on the title screen (and progresses the program to the screeching noise/scrolling message), so if you are shortening the music, then the 'FF' should be located to just after the shortened tune code (or to #85FB in the case of having no Title Screen tune).

Danny, I was helped by advice from Stuart which I found in an old message of his: "So here it is again, the fix for the block-graphics bug, only this time I have pasted my fix into SkoolKid

Danny, Just to let you know, I have succeeded in inserting the Main Patch Vector into the Main Loop. However, this was more of an academic exercise - as previously discussed, it is more byte-intensive to rely on direct jumps back from each room-specific patch vector, rather than call commands. So, unlike the Cell Graphics Bug Fix (which is best applied directly into its host routine, if that can be achieved by consolidation), there is a sound 'bytes management' reason why the Main Patch Vector should be applied as a separate sub-routine.

For instance, there is a routine in JSW described in the SkoolKit dissasembly as 'Draw the rope, arrows and guardians in the current room'. But as well as being bookended by chunks of code that set up the drawing loop, there are three significant subsections that deal with, in turn: (1) horizontal and vertical guardians; (2) arrows; (3) ropes. I have been referring loosely to e.g. the 'draw an arrows subroutine'. If that isn't technically a 'subroutine' (because it isn't called up from elsewhere), then what should I be calling it?

Thank you for that clarification Andrew. Is there a word or phrase that we should be using, to avoid confusion, when referring to a subsection of code within a particular routine (i.e. not a 'subroutine' called up from elsewhere)?

Possibly a rope's data is overwriting it? Or do you have the 'adjacent ropes patch' in place?

To be clear, the 'border special effects' aren't actually present in original JSW, and the program already retains the border colour for the room in question.

Thanks for the credit, Danny! Just to be pedantic, the word 'end' is missing there, I think?