Willy disassemblies in hexadecimal

[IRF]

I think Matt Smith probably came up with the current setting of 12 based on a suitable distance when the rope is hanging vertically down, and indeed Willy can't jump as high as the top of the screen when the rope is in its central position.

 

However, when the rope is at an angle to the top of the screen that is less than a right-angle, then trigonometry dictates that Willy - in the same position along the rope - is less than 12 pixels from the top of the screen. So the top of the screen becomes reachable via a well-timed jump (i.e. as soon as he stops swinging 'outwards' and before he starts to swing 'back in').

[IRF]

I just double-checked and 14 isn't quite enough, but 15 (or 0f in hex - for the record the relevant hex addresses are #9396 and #939a) seems to do the trick.

 

Edit: 14 would probably sufficient to fix the 'bug' if the maximum range of the ropes were reduced a tad, but you'd have to play test all the rope screens to make sure they were still completable (they should be okay in original JSW, but not I suspect in The Nightmare Edition).

Edited March 14, 2016 by IRF

[IRF]

Incidentally, is there an issue with putting a rope as the eighth entity in the list of guardians for a room? As a rope's data extends beyond its own eight bytes, could it corrupt the room layout data for the next screen in the list (most likely the top-left corner)?

Edited March 14, 2016 by IRF

[SkoolKid]

Incidentally, is there an issue with putting a rope as the eighth entity in the list of guardians for a room? As a rope's data extends beyond its own eight bytes, could it corrupt the room layout data for the next screen in the list (most likely the top-left corner)?

I don't think it would be a problem. The rope's buffer would extend beyond the entity buffer at 8100 into the first and third bytes of the unused area that follows at 8141. It wouldn't corrupt the layout of any other room.

 

See also The encroaching rope.

[IRF]

I don't think it would be a problem. The rope's buffer would extend beyond the entity buffer at 8100 into the first and third bytes of the unused area that follows at 8141. It wouldn't corrupt the layout of any other room.

 

See also The encroaching rope.

 

But if a game had used the space from #8141 for a new routine or other useful data, then it might corrupt that?

 

In JSW The Nightmare Edition, that space was used for additional in-game tunes, the first of which is 'In the Hall of the Mountain King'.  In fact, that particular tune did get corrupted at some point in the game's development, so I wonder if that or something similar* was the reason?  (Danny?)

 

* I say "something similar" as we didn't ever have a room with eight ropes in it a rope occupying the eighth position in the guardian list.  (Edit: typo struck out - imagine a room with eight ropes!!)

Edited March 14, 2016 by IRF

[IRF]

As a suggestion for a tweak to the disassembly, perhaps this page http://skoolkid.github.io/jetsetwilly/asm/8100.html should say at the end:

 

8140 Terminator

8141 - 8143 Unused (but potentially overwritten if a rope were to occupy the eighth position in the guardian list for a room)

 

Then change the 'Next' link (and the following page, and the reference in the Memory Map) from 8141 to 8144.

 

This would prevent future game developers from using those three bytes that might get corrupted in such a scenario?  Or at least, they would have been warned to use those bytes with care!  (In the case of TNE it's easily avoided, since it just so happens that there are three unused bytes at the end of the chunk of previously unused code that was recycled for new tune data. i.e. at 81FD - 81FF).

Edited March 14, 2016 by IRF

[jetsetdanny]

I don't think it would be a problem. The rope's buffer would extend beyond the entity buffer at 8100 into the first and third bytes of the unused area that follows at 8141. It wouldn't corrupt the layout of any other room.

 

See also The encroaching rope.

 

But if a game had used the space from #8141 for a new routine or other useful data, then it might corrupt that?

 

In JSW The Nightmare Edition, that space was used for additional in-game tunes, the first of which is 'In the Hall of the Mountain King'.  In fact, that particular tune did get corrupted at some point in the game's development, so I wonder if that or something similar* was the reason?  (Danny?)

 

* I say "something similar" as we didn't ever have a room with eight ropes in it a rope occupying the eighth position in the guardian list.  (Edit: typo struck out - imagine a room with eight ropes!!)

 

It's not impossible, I believe. You *could* have eight ropes in the same room  ;) .

 

And no, the corruption of the in-game tune at some development points in "TNE" was not related to the ropes in any way. It was due to mistakes in the code determining the tunes for certain rooms.

Edited March 14, 2016 by jetsetdanny

[jetsetdanny]

I don't think it would be a problem. The rope's buffer would extend beyond the entity buffer at 8100 into the first and third bytes of the unused area that follows at 8141. It wouldn't corrupt the layout of any other room.

 

See also The encroaching rope.

 

This is certainly true about the original, unmodified game engine. However, JSWED offers the possibility of applying John Elliiott's "new adjacent ropes patch", which eliminates the need to have a blank guardian in the guardian list after a rope. In other words, you can have a "regular" guardian after a rope in the guardian list, including another rope, I believe. So theoretically you can have a room with eight ropes.

 

John Elliott once explained to me that the patch "relocates a couple of bytes of rope state to within the rope's guardian table entry, rather than the following guardian's entry." So the question arises whether applying the patch would protect the addresses 8141-8143 from *ever* being overwritten by ropes, even if a rope is the last guardian in the guardian list.

 

It's a question to John, I guess. It would be interesting to know the answer for sure for future projects  :) .

[jetsetdanny]

As a suggestion for a tweak to the disassembly, perhaps this page http://skoolkid.github.io/jetsetwilly/asm/8100.html should say at the end:

 

8140 Terminator

8141 - 8143 Unused (but potentially overwritten if a rope were to occupy the eighth position in the guardian list for a room)

 

Then change the 'Next' link (and the following page, and the reference in the Memory Map) from 8141 to 8144.

 

This would prevent future game developers from using those three bytes that might get corrupted in such a scenario?  Or at least, they would have been warned to use those bytes with care!  (In the case of TNE it's easily avoided, since it just so happens that there are three unused bytes at the end of the chunk of previously unused code that was recycled for new tune data. i.e. at 81FD - 81FF).

 

I agree with this. Moreover, if John Elliott's "new adjacent ropes patch" protects these bytes from being overwritten, this could be mentioned, too, if it falls within Richard's "policies" of supplying additional information.

[Spider]

It's not impossible, I believe. You *could* have eight ropes in the same room  ;) .

 

And no, the corruption of the in-game tune at some development points in "TNE" was not related to the ropes in any way. It was due to mistakes in the code determining the tunes for certain rooms.

hmm I think eight rope would be a bit on the excessive side. Its JSW not JSHunchback after all ;) :)

 

I agree with this. Moreover, if John Elliott's "new adjacent ropes patch" protects these bytes from being overwritten, this could be mentioned, too, if it falls within Richard's "policies" of supplying additional information.

 

I'm kind of sat on the fence on this. :) I'd like to see it but it sort of falls outside the scope of the 'normal' game code, unless I have misunderstood ? (which is quite likely)