Some Jet Set Willy technical questions

[crem]

Hi all,

I've started to work on building tools to generate a walkthrough of JSW (no estimations on timeline yet, and whether I have enough enthusiasm to finish yet; I hope so, although it feels a larger project than MM 🙂 ).

I have a few questions on how to interpret the memory state (I have assumptions for most of those but it would be nice to confirm it).

1. There are 1-byte 0x85CF "Willy's Y location" and 2-byte 0x85D3 "Willy's attribute location in a buffer" variables is the game.
At the beginning of the frame (when PC=0x89AD), is it always true, that memory[0x85D3]=0x5c00+32*(memory[0x85CF]/16)+x_offset?
In other word, can it happen that they go out of sync (on the rope, on the ramp, during the jump, during room transition etc)?

2. Is it true, that [at the beginning of the frame (when PC=0x89AD)], I can ignore/write garbage to 0x85D5 "Jump animation counter" if 0x85D1 "Airborne status indicator" is not 1?

3. To save the resources and not try to press keys when Willy is jumping/falling, in Manic Miner I used the following logic:
a) If before the frame, "Airborne status indicator" is 0, try all input combinations, else only try "no keys pressed"
b) If _AFTER_ the frame, "Airborne status indicator" is 0, also try all other combinations for the previous frame (if didn't try already).
Questions (both for MM where it seemed to work, and in JSW where I hope it to work):
- Is it enough? (e.g. are no special cases like falling onto the edge of conveyor belt etc)
- Maybe there's simpler logic?

4. It looks like "Willy's Y location" is rounded to the multiple of 16 if Willy is on the ramp. How exactly the logic that draws Willy goes then?
"If Willy is in the same cell as ramp and not jumping/falling, move him up depending by the 0x85D2 "Willy's animation frame" value, but if Willy is jumping above ramp, 0x85CF "Willy's Y location" contains true Y position" -- is that understanding correct?

Thanks!

[jetsetdanny]

I like the look of your questions, crem, but unfortunately I'm not able to asnwer them. But there may be some people around here who will 🙂.

[IRF]

I'm not sure I'm able to answer crem's questions with the degree of certainty that he might need.

However, skim-reading them has prompted me to point out that the variables at #85D0 and #85D2 do not get re-initialised at the start of a game.

i.e. When you first load the game, Willy starts off facing the bath tap, at the opposite end of the bath from the tap.  However, after playing a game and starting another one, his facing direction and frame of animation are sometimes different from that initial setup.  That could make a difference (of a few frames) in terms of the possible completion time - small beer in the grand scheme of things, but I just thought I'd mention it.  (Of course, it's not an issue if you load up the game file as the first step in each iteration of your algorithm.)

[Norman Sword]

 Further to the topic of orientation of Willy upon game start. This automatically causes an auto play problem. If willy needs to turn around at game start, you have wasted a whole frame. The start orientation if collecting the bath tap first has a change of one frame between the differences in direction. For playing the whole game one frame will not be detectable unless playing to 1/100 sec style timings. Once the initial room has been played then Willies state from that room onwards is set.  However that initial one state change can/could cause problems. That's  #85d0

The value in #85d2 the animation frame adds another problem

This does pose the question. Do you force the initial state as being the state that is in operation when the game is loaded. 

--------------------------------------------------------------------

Stairs

I glanced at your questions and do wonder why you are concerned about the pixel shift of Willy when on a stair.

When on a stair the game treats him as standing on a platform. If you remove the code for stair displacement. Willy walks up the stairs as a series of steps. He is treated as being on character/tile boundaries and NEVER treated as being displaced from the Character/tile boundary. (jumping is another story). On a stair he is visually drawn shifted to appear as in he is moving diagonally. The game code whilst on a stair  treats Willy as stepping up the stairs one character at a time.  

In a nutshell. If willy is on a platform- The code checks the direction of the stairs For each direction of stair we check the block directly below his feet. For a stair going from left to right upwards /  we check the block beneath his right foot for a stair tile. For a stair going the other way we check the block under his left foot for the stair tile.

If the stair tile/block is present we displace Willy from the vertical (only on the drawing of Willy and this displacement is not saved anywhere)

For stairs /   we use the animation frame and add a displacement of 6/4/2/0 (pixels) for each animation stage
for stairs sloping the other way we add 0/2/4/6(pixels) for each animation stage. 

As stated Willy never code wise moves from the fixed character/tile boundaries- the displacement is an optical trick to make him look like he walks up and down the stairs. 
==========================================================================================================
Addendum the pixel offset is doubled for the YTABLE offset - to move willy down the screen 2 pixels we add 4 to his YTABLE position, since each entry in the YTABLE is 2 bytes.

Edited March 29, 2021 by Norman Sword
additional text (concerning jumping) for clarity

[IRF]

7 hours ago, crem said:

3. To save the resources and not try to press keys when Willy is jumping/falling, in Manic Miner I used the following logic:
a) If before the frame, "Airborne status indicator" is 0, try all input combinations, else only try "no keys pressed"
b) If _AFTER_ the frame, "Airborne status indicator" is 0, also try all other combinations for the previous frame (if didn't try already).
Questions (both for MM where it seemed to work, and in JSW where I hope it to work):
- Is it enough? (e.g. are no special cases like falling onto the edge of conveyor belt etc)
- Maybe there's simpler logic?

I think I know what you're saying here (you tell the algorithm not to press movement keys if AIRBORNE does not equal zero), and yes I think there is a special case in JSW that will confound that.

If Willy jumps or falls onto a rope [but not if he gets picked up by a rope when he is walking or standing still], then Airborne may hold a non-zero value, which only gets actively reset to zero at the point where he jumps off the rope, falls off the bottom end or climbs up into the room above.

So if you told your algorithm not to bother trying to press any movement keys unless AIRBORNE = zero, then Willy might get stuck on a rope.

Edited March 27, 2021 by IRF

[IRF]

7 hours ago, crem said:

1. There are 1-byte 0x85CF "Willy's Y location" and 2-byte 0x85D3 "Willy's attribute location in a buffer" variables is the game.
At the beginning of the frame (when PC=0x89AD), is it always true, that memory[0x85D3]=0x5c00+32*(memory[0x85CF]/16)+x_offset?
In other word, can it happen that they go out of sync (on the rope, on the ramp, during the jump, during room transition etc)?

There's a subroutine at #8E9C which is called to automatically ensure that attribute and pixel y-coordinates stay in sync when Willy is jumping/falling/on a rope.

https://skoolkid.github.io/jetsetwilly/asm/8DD3.html#8e9c

In up/down room transition, Willy's attribute coordinates and pixel y-coordinate are manually adjusted, one after the other.  Ditto for when Willy moves along from one ramp cell to the next (though visually Willy is drawn on a ramp as Norman describes, unless he's jumping through the ramp).

[IRF]

7 hours ago, crem said:

2. Is it true, that [at the beginning of the frame (when PC=0x89AD)], I can ignore/write garbage to 0x85D5 "Jump animation counter" if 0x85D1 "Airborne status indicator" is not 1?

Yes, I think that's true - the value of the Jump Counter is only used during a jump, and it is always set to zero at the start of a jump (at the same time that AIRBORNE is set to 1).

[IRF]

8 hours ago, crem said:

4. It looks like "Willy's Y location" is rounded to the multiple of 16 if Willy is on the ramp. How exactly the logic that draws Willy goes then?
"If Willy is in the same cell as ramp and not jumping/falling, move him up depending by the 0x85D2 "Willy's animation frame" value, but if Willy is jumping above ramp, 0x85CF "Willy's Y location" contains true Y position" -- is that understanding correct?

The only thing I would add to Norman's explanation is that "moving Willy up" (as per the phrase in bold in the above quote) might be a misleading way to consider it.  When the vertical position of his sprite whilst on a ramp is adjusted, an adjustment is made to his pixel y-coordinate by adding a certain value (depending on his current frame of animation).  So in that sense his y-coordinate is increased.  However, the effect on the screen is to draw his sprite lower down - because y=0 at the top of the screen - and so Willy is actually moved down, not up, in terms of where you see him.

[crem]

  

On 3/25/2021 at 6:48 PM, Norman Sword said:

crem I  might be stating the obvious. 

The variables being monitored in Manic Miner. I will assume you also modify Manic Miner with the following change in code.

87AB    LDIR    ;<<<<< SET #87AB=0 , #87AC=0
RESTORE WITH #87AB=#ED #87AC=#B0

87D1    LDIR  ;<<<<< SET #87D1=0, #87D2=0
RESTORE WITH #87D1=#ED, #87D2=#B0

 

This change in the code will double the speed of the program. It will loose the game display whilst it plays. But I do not believe you watch the game being played at hyper speed trying to find the quickest path.

Now I'm trying to speed up JSW emulation (and don't care what's displayed in the screen).
Do I understand it correctly, that it's safe to remove LDIR at addresses #89FE, #8A2F and #8B10, but not the ones at #89B9 and #89C4?

(addresses taken from https://skoolkit.ca/disassemblies/jet_set_willy/hex/asm/89AD.html and https://skoolkit.ca/disassemblies/jet_set_willy/hex/asm/8B07.html)

[IRF]

Yes.