MM/JSW disassemblies: 20160511

[IRF]

Another little suggestion for a tweak:

 

http://skoolkid.github.io/jetsetwilly/asm/7000.html

 

Perhaps you could mention that the Empty Room Screen Buffer is updated every time-frame by the routine at:

http://skoolkid.github.io/jetsetwilly/asm/94F9.html

(to reflect the animation of the conveyor)?

 

This is the only way in which the Empty Room Screen Buffer is updated in JSW (except when moving between rooms, obviously).  It's different in Manic Miner, where as well as conveyor action, crumbling cells and Kong Beast switches are redrawn on the Empty Room Screen Buffer - and the relevant entry in the MM disassembly does already refer to these updates.

[IRF]

In Move Willy (1) of the JSW disassembly, at #8E39 the check determined by an AND #0E command is described as "Does Willy's sprite occupy six cells at the moment?"

 

Now, when Willy is on a ramp (not cell-aligned), you would think that yes, his sprite does occupy six cells.  But the check still gives a negative response, and the program proceeds through to #8E3D instead of jumping to #8E62.

 

This is, of course, because what we see is Willy's sprite drawn at his true y-coordinate, whereas the check at #8E39 is looking at his pixel y-coordinate stored at #85CF (which isn't adjusted to account for his precise position on a ramp).

 

Therefore I believe that the wording accompanying the command at #8E39 needs to be re-worded (although I'm not sure exactly what words should be used to clarify the matter!)

 

Possibly the references in the subsequent entries to cells "below Willy's sprite" might need tweaking too (if he's on a ramp, the cells being pointed at may partially contain his legs!)

Edited June 15, 2016 by IRF

[IRF]

JSW disassembly Rope animation table #8300:

 

"For a given rope animation frame F (0<=F<=54), the 32 entries from F to F+31 inclusive (one for each segment of rope) in each half of the table are used; thus the batch of entries used 'slides' up and down the table as F increases and decreases."

 

That should read "from F to F+32" - the first segment of the rope is Segment 0, so there are 33 in total, not 32.

[SkoolKid]

JSW disassembly Rope animation table #8300:

 

"For a given rope animation frame F (0<=F<=54), the 32 entries from F to F+31 inclusive (one for each segment of rope) in each half of the table are used; thus the batch of entries used 'slides' up and down the table as F increases and decreases."

 

That should read "from F to F+32" - the first segment of the rope is Segment 0, so there are 33 in total, not 32.

In which case the zero bytes at 8356 and 83D6 - currently marked as unused - are in fact used. Which also means that when the rope is the leftmost or rightmost extent of its swing, the last segment is not drawn in the correct place (the bytes at 8356 and 83D6 should probably be 3 and 4 respectively). Which is a bug.

 

Is this actually the case? Investigation needed!

[IRF]

In which case the zero bytes at 8356 and 83D6 - currently marked as unused - are in fact used. Which also means that when the rope is the leftmost or rightmost extent of its swing, the last segment is not drawn in the correct place (the bytes at 8356 and 83D6 should probably be 3 and 4 respectively). Which is a bug.

 

Is this actually the case? Investigation needed!

 

No, they are used.  Segment Zero doesn't have an offset applied to it - it is at the top of the screen, in the same horizontal position regardless of the value of the Rope Animation Frame.  Bytes #8300 and #8380 are picked up to determine where to draw Segment 1 when the Rope Animation Frame is at 0.

 

It was initially my understanding that the last of the non-zero bytes in each half of the table were unused - until I realised that the Segment Counter increments to 32, not 31!

Edited June 16, 2016 by IRF

[IRF]

Richard,

 

I notice you've picked up the point about the Nightmare Room conveyor having its attribute and graphic data placed incorrectly in the code. The solution to which is to shift bytes 56780-56788 forward by one byte to 56781-56789.

 

However, perhaps you could also make the point that if the byte that 'falls off the end' (from 56789) is rotated back to occupy 56780, then it also fixes the visual appearance of the ramp cells (filling in the 'air gap' at bottom of the ramp)?

 

One more thing on the above - Stuart Brady deserves the credit in the Changelog for spotting the phenomenon in the first paragraph, not me.

 

Although I do get the credit for the point in the second paragraph, so if you decide it's worthy of mention in the disassembly, then 'Very Corrupted Conveyor' could have a joint credit!

 

Oh, and one more point of trivia: with the bytes all in the right place, the Cell Graphics Bug doesn't kick in in the first place in The Nightmare Room, because the correct attribute byte for the conveyor doesn't match any of the screen's preceding graphics bytes!

[SkoolKid]

No, they are used.  Segment Zero doesn't have an offset applied to it - it is at the top of the screen, in the same horizontal position regardless of the value of the Rope Animation Frame.  Bytes #8300 and #8380 are picked up to determine where to draw Segment 1 when the Rope Animation Frame is at 0.

 

Isn't that a contradiction? If only segments 1-33 have x- and y-offsets applied to them, and the bytes at 8300/8380 are used for segment 1, then the bytes at 8356/83D6 are unused - and the text as it stands now is correct: entries from F to F+31 inclusive.

[IRF]

Segment 0 is drawn at the top of the screen, in the cell-column determined by the second byte of the Rope specification for the screen.

 

Segment L has horizontal and vertical offsets applied according to F+L.

 

F ranges from 0 to 54.

 

L ranges from 1 to 32.

 

So F+L ranges from 1 to 86.

 

And there are 86 usable entries in each half of the table!

Edited June 16, 2016 by IRF

[SkoolKid]

I'm really confused now! Let me put the questions another way.

 

1. How many pairs of x- and y-offsets are used to draw the rope during each animation frame: 32 or 33?

 

2. Is the pair of offsets at 8300/8380 used?

 

3. Is the pair of offsets at 8356/83D6 used?

[IRF]

32 offsets during each animation frame.

 

#8300/8380 are used.

 

#8356/83D6 are not.

 

Think of it like this: there are 32 'lengths' of rope, and 33 points separating them (32 dots on the screen).  The first 'length' spans between Point 0 (top of screen) and Point 1.  The 32nd and final 'length' spans between Point 32 and 33.