Jump to content


Photo

Willy disassemblies in hexadecimal


  • Please log in to reply
115 replies to this topic

#21 IRF

IRF

    Advanced Member

  • Contributor
  • 3,813 posts

Posted 13 March 2016 - 08:53 PM

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

#22 IRF

IRF

    Advanced Member

  • Contributor
  • 3,813 posts

Posted 13 March 2016 - 09:45 PM

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 by IRF, 14 March 2016 - 08:11 AM.


#23 IRF

IRF

    Advanced Member

  • Contributor
  • 3,813 posts

Posted 13 March 2016 - 09:48 PM

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 by IRF, 14 March 2016 - 08:08 AM.


#24 SkoolKid

SkoolKid

    Advanced Member

  • Contributor
  • 54 posts

Posted 14 March 2016 - 01:06 PM

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.



#25 IRF

IRF

    Advanced Member

  • Contributor
  • 3,813 posts

Posted 14 March 2016 - 01:15 PM

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 by IRF, 14 March 2016 - 01:17 PM.


#26 IRF

IRF

    Advanced Member

  • Contributor
  • 3,813 posts

Posted 14 March 2016 - 01:21 PM

As a suggestion for a tweak to the disassembly, perhaps this page http://skoolkid.gith...y/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 by IRF, 14 March 2016 - 03:17 PM.


#27 jetsetdanny

jetsetdanny

    Advanced Member

  • Contributor
  • 1,913 posts

Posted 14 March 2016 - 05:59 PM

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 by jetsetdanny, 14 March 2016 - 06:00 PM.

  • IRF likes this

#28 jetsetdanny

jetsetdanny

    Advanced Member

  • Contributor
  • 1,913 posts

Posted 14 March 2016 - 06:06 PM

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


  • IRF likes this

#29 jetsetdanny

jetsetdanny

    Advanced Member

  • Contributor
  • 1,913 posts

Posted 14 March 2016 - 06:08 PM

As a suggestion for a tweak to the disassembly, perhaps this page http://skoolkid.gith...y/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.


  • IRF likes this

#30 Spider

Spider

    XOR (HL)

  • Administrator
  • 3,367 posts

Posted 14 March 2016 - 06:36 PM

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)


  • IRF likes this
Changing order to chaos since 1984




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users