Willy disassemblies in hexadecimal

[SkoolKid]

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!

Ah, I see what you mean. Yes, the images are 'mocked up' in that sense, but then so is every other image in the disassembly. (And every image in the MM/SD/BTS/CSC disassemblies too.)

 

Have you played our JSW The Nightmare Edition? There's a static guardian (with filled-in pixels only one cell-column deep) on the far right-hand side of The Off Licence - if you can get that far!!

I started playing it, and I have to admit I soon gave up! Does the WRITETYPER cheat work, by any chance? :)

[SkoolKid]

Richard,

 

Please see the attached, starting position is The Forgotten Abbey.  I performed the manoeuvre twice - the first time, I kept 'left' depressed (walking against the flow of the conveyor) so Willy was able to escape the situation.  The second time, I let go of 'left' after entering The Wine Cellar, and so Willy got stuck!

 

In Dr Jones..., if you manoeuvre Willy to be standing three cells above the 'tusk' item, and walk left, then he gets stuck inside the elephant's head!  (N.B. This is the case in the original JSW, but in the Bug Fix 2015 Edition it has been prevented by removing some of the Water cells inside the 'head', allowing Willy to drop out of that row of cells.)

Thanks for the RZX. I didn't think of trying to get onto the floor tile in The Forgotten Abbey before entering The Wine Cellar!

 

I'll have to give the Dr Jones manoeuvre a try some time...

[IRF]

And my own investigations have confirmed that value of 15 as the minimum. I've already written up the bug description, and it includes an explanation of why 15 is the minimum value.

 

Is it something like 12/cos(?), where 12 is the value that prevents Willy jumping off the top when the rope is hanging vertically down [and is the value of the bytes in question in the original game code], and ? is the angle by which the top of the rope deviates from the vertical, at its point of maximum swing?

Edited April 25, 2016 by IRF

[IRF]

I started playing it, and I have to admit I soon gave up! Does the WRITETYPER cheat work, by any chance? :)

I'm afraid that all the Writetyper code was reused for 'higher' purposes...

Edited April 24, 2016 by IRF

[IRF]

Richard,

 

In the Trivia section of the JSW disassembly, the 'Ropes for Beginners' guide is very useful (i.e. how to climb up, based on the direction of the rope's swing and Willy's facing direction).

 

I was thinking that maybe you could also include a 'Ramps for Beginners' guide, explaining how exactly Willy can jump through, rather than onto a ramp. i.e. Starting at which frame of animation allows him to jump through?  Perhaps with an explanation of the mechanics of jumping through ramps?

 

And on that subject...

 

No, I'm pretty sure I intended the images to reflect exactly where Willy is drawn - instead I must have mistakenly assumed that he's drawn at the coordinates where the nasty tile check takes place.

 

I think it would be fairly simple to rearrange the code so that both coordinates are updated before the check takes place - no idea about unintended consequences, though!

 

I'm wondering if one such unintended consequence might be to prevent Willy from being able to jump through a ramp?  (I'm not sure about that though.)

Edited April 25, 2016 by IRF

[IRF]

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!

 

Regarding the phenomenon highlighted in bold, I've now realised that the scenario in which it occurred involved a static guardian adjacent to a ramp.  And the reason for this quirky behaviour is down to the routine at 38344.

 

There is a section of code in that routine at 38372 which calculates Willy's true pixel y-coordinate if he is on a ramp.  However, that section of code is bypassed if the Airborne Status Indicator is non-zero.  So if the 'Jump' key is kept depressed, the vertical position of the bottom of Willy's sprite is aligned with the top of the ramp cell on which he lands.  So he appears to briefly 'bounce' a few pixels above the exact position of the ramp beneath him.

 

And hence Willy can jump safely away from certain guardians located adjacent to a ramp (as long as the guardian's filled in pixels don't coincide with those of Willy when he is at the lowest point in his jump), whereas if 'Jump' isn't depressed, the program draws Willy at his exact vertical position (based on his precise horizontal pixel position on the ramp), which then can mean the same guardian's pixels do coincide with Willy's, and he dies!

 

(N.B.  The same trick cannot be performed with a Fire cell located adjacent to a ramp, because death by Fire cell isn't pixel-based.)

 

The same check 'Is Willy Jumping?' in the routine at 38372 also explains why Willy can appear to 'hover' above a ramp, if he keeps the 'Jump' key depressed when he is walking up the ramp underneath an overhead Earth cell.

 

The attached rzx recording demonstrates both of these phenomena, as well as the fact that Willy can walk up a ramp through an overhead Earth cell (as there is no check in the code for overhead Earth cells when Willy is walking up a ramp).  This effectively makes walking up the ramp a one-way route, because when he tries to return back down, he is stopped by the check for Earth blocks adjacent to him!

 

It's also worth mentioning that he can walk down a ramp through an Earth cell at the bottom of a ramp (this is not shown in the attached rzx, but you can see it in action in the original JSW, by walking down the ramp in On Top of the House!)  That's because the check for Earth cells at the level (y+2) doesn't take place when he's cell-row aligned.  (Otherwise he wouldn't be able to walk along Earth cell platforms; it also explains his ability to jump through Earth cells if he encounters them when he's cell-row aligned at a certain animation frame, as your MM disassembly 'Bugs' section demonstrates.)

Ramp jump test.rzx

Edited May 2, 2016 by IRF

[SkoolKid]

Is it something like 12/cos(?), where 12 is the value that prevents Willy jumping off the top when the rope is hanging vertically down [and is the value of the bytes in question in the original game code], and ? is the angle by which the top of the rope deviates from the vertical, at its point of maximum swing?

No, there's no trigonometry involved. :) Here's the explanation I've included in the bug description:

 

"The number 15 here determines the highest segment of rope that Willy can reach (originally 12). At segment 15, Willy's y-coordinate never goes below 25 while he's on the rope, and is adjusted down to 24 (see 36782) when he jumps off, which is too far from the top the room (the maximum height Willy can jump is 20 pixels). At segment 14, Willy's y-coordinate never goes below 23 while he's on the rope, but is adjusted down to 16 when he jumps off, which is close enough to the top of the room to be able to jump through it."

 

You can see the full text in the git commit:

 

https://github.com/skoolkid/jetsetwilly/commit/99733c6c4708b86b9c58f2369934d02a43ee7c1b

[IRF]

Okay, but I'm sure the reason that Willy's y-coordinate never goes below 25 at segment 15, relates back to fundamental mathematics!?  Although I appreciate that it's not linear, but subject to discrete jumps of 8 pixels, so basic trigonometry is perhaps too simplistic.  Still, my crude trig-based calculation yielded the same result!

 

If the game engine were to be amended such that the swing of the rope extended further than it does, then with Willy holding onto segment 15 of the rope, he may be brought within jumping reach of the top of the screen!  Because the angle of the upper part of the rope's deviation from the vertical would be greater than it is at the moment, so his y-coordinate might drop below 24 (meaning it is 'rounded down' to 16).

Edited April 25, 2016 by IRF

[IRF]

No, there's no trigonometry involved. :) Here's the explanation I've included in the bug description:

 

"The number 15 here determines the highest segment of rope that Willy can reach (originally 12). At segment 15, Willy's y-coordinate never goes below 25 while he's on the rope, and is adjusted down to 24 (see 36782) when he jumps off, which is too far from the top the room (the maximum height Willy can jump is 20 pixels). At segment 14, Willy's y-coordinate never goes below 23 while he's on the rope, but is adjusted down to 16 when he jumps off, which is close enough to the top of the room to be able to jump through it."

 

You can see the full text in the git commit:

 

https://github.com/skoolkid/jetsetwilly/commit/99733c6c4708b86b9c58f2369934d02a43ee7c1b

 

One further thought - would it be worth mentioning here:

 

"The number 15 here determines the highest segment of rope that Willy can reach (originally 12)"

 

where 0 represents the top of the rope.  i.e. the segment count is from the top downwards?

 

Otherwise the casual reader may think that the POKES enable Willy to reach a higher part of the rope (15 being a higher number than 12)!

[Spider]

And my own investigations have confirmed that value of 15 as the minimum. I've already written up the bug description, and it includes an explanation of why 15 is the minimum value.

 

Great. :)