Jump to content


Photo

Undocumented Quirky Features of JSW2


  • Please log in to reply
20 replies to this topic

#11 IRF

IRF

    Advanced Member

  • Contributor
  • 3,624 posts

Posted 04 January 2018 - 03:19 PM

I'd seen the 'single step jumping' effect previously but not really considered it to any great degree. I just tried the Amstrad version of JSW2 out of interest to see this 'effect' (assuming it was there!) and it does not do that :huh: he jumps as you'd expect in that he turns around and jumps fully. Same with JSW1 on that platform.


Sorry Andy, was the above comment in relation to the conveyor behaviour (at the left-hand of the conveyor) in JSW2? I appreciate I've been discussing several different phenomena at once, so it's difficult to keep track!

(P.S. The reference to "that platform" didn't help with my confusion - I presume you're referring to Amstrad as the platform as in hardware, rather than a platform as in standonable room cell!? :-p)

#12 IRF

IRF

    Advanced Member

  • Contributor
  • 3,624 posts

Posted 04 January 2018 - 03:27 PM

I think there's partial dissasembly of the JSW2 engine but not a complete one, its quite complicated I think.


This is the only thing that I could find, courtesy of John Elliott:

https://www.seasip.i...w/jsw2room.html

#13 Spider

Spider

    XOR (HL)

  • Administrator
  • 3,135 posts

Posted 04 January 2018 - 03:35 PM

I think a 'test room' of various block types positioned in both variants would be a way forward to really 'compare' the differences easily ? :unsure: :)
 
I'm aware of the cell differences, well kind of differences, I downloaded both the Linux and Windows versions to check for any documentation changes or differences (accidental differences or updates between .pdfs maybe) but they are the same:
 

JSW2 supports 9 elements rather than the four in JSW48. These are:

• Air

• Water

• Earth

• Fire

• Ramps (both directions)

• Conveyors (both directions)

• Collectable items. You can have up to 16 items per room; there is no separate global limit.


  • IRF likes this
Changing order to chaos since 1984

#14 Spider

Spider

    XOR (HL)

  • Administrator
  • 3,135 posts

Posted 04 January 2018 - 03:39 PM

Sorry Andy, was the above comment in relation to the conveyor behaviour (at the left-hand of the conveyor) in JSW2? I appreciate I've been discussing several different phenomena at once, so it's difficult to keep track!

(P.S. The reference to "that platform" didn't help with my confusion - I presume you're referring to Amstrad as the platform as in hardware, rather than a platform as in standonable room cell!? :-p)

Yes sorry by "Platform" or "Variant" I mean "Machine Type" sorry for any confusion! :D

 

I think I'll try to just say AMS or CPC for the Amstrad versions where appropriate, otherwise best to assume I'm referring to the Spectrum version. :thumbsup:

 

Incidentally a quick cursory look at the BBC Micro versions of JSW1 and JSW2 and he jumps as per the Spectrum JSW1 version, as in a 'full jump'


  • IRF likes this
Changing order to chaos since 1984

#15 IRF

IRF

    Advanced Member

  • Contributor
  • 3,624 posts

Posted 04 January 2018 - 07:42 PM

Looking at Andrew Broad's list of quirky features for JSW2, hitting an overhead Earth block during a jump also alters Willy's Airborne Status Indicator in a different way as well, meaning that he can't fall as far afterwards as he can in JSW1 - although I haven't explored this behaviour yet.

 

I've played around with this now - in JSW2, in addition to Willy not being able to fall as far* after hitting his head on an overhead Earth block during a jump, he also progresses forwards by one animation-frame during the first two time-frames of descent, but then he stops moving horizontally for the rest of his descent.  Whereas in JSW1, his horizontal momentum is completely curtailed when he bangs his head on an overhead Earth block.

 

(*He can only drop to a level that is three cell-rows lower than the apex of his jump without being killed, which is less than the four rows through which he can safely drop if he has head clearance.  In JSW1, hitting his head on Earth actually allows him to fall a greater distance than he could if he made the same jump with head clearance.)


Edited by IRF, 04 January 2018 - 07:56 PM.


#16 Spider

Spider

    XOR (HL)

  • Administrator
  • 3,135 posts

Posted 04 January 2018 - 08:37 PM

There was something a bit odd in a MM variant I noted a while back but forgot about it, but I don't think its relevant here even though its a 'quirky' thing, I'll try to find out what/why and post a new topic about it over the next few days.


  • IRF likes this
Changing order to chaos since 1984

#17 IRF

IRF

    Advanced Member

  • Contributor
  • 3,624 posts

Posted 07 January 2018 - 12:41 AM

I believe that the difference in the JSW2 jumping behaviour may arise because in each time-frame of a jump, the check for a solid underfoot platform (to curtail the descent phase of a jump) takes place before Willy's y-coordinate is incremented downwards.*

Whereas in the JSW1 game engine, he is moved downwards during a jump before the check for underfoot behaviour takes place. That, I believe, is the fundamental reason why Willy can jump into supposedly solid blocks.

So really, it is the JSW1 jumping that is the illogical and quirky behaviour - Willy shouldn't be able to jump up onto a two-block high wall (such as you get in 'Banyan Tree') unless he takes several steps back from it before taking the jump. I'll try to create a few frame-by-frame screenshots later to illustrate exactly why that is the case.

 

I have created four screenshots (attached) to illustrate one of the differences between the jump mechanics in the JSW1 and JSW2 game engines.

 

Willy is making a jump over a head-height pillar of Earth blocks in 'Tree Top'.  He starts his jump from the position shown in the screenshot named 'Tree Top Jump 1'.

 

In 'Tree Top Jump 2', Willy is on the descent and is exactly one vertical increment above the top of the upper solid block.

 

With the original JSW1 game engine, the screenshot 'Tree Top Jump 3a' shows what happens in the next time-frame - Willy lands on the top of the tree trunk, one frame of animation short of going over the edge.

 

With the JSW2 game engine (or in this case, the JSW1 engine hacked to behave like JSW2), the screenshot entitled 'Tree Top Jump 3b' shows the 'alternative reality' behaviour - in the next time-frame after the second screenshot was captured, Willy has been moved along by an increment vertically downwards but also one increment horizontally [in this case leftwards].  Therefore he overshoots the top of the tree trunk, and in subsequent time-frames (not shown in the attached), he proceeds with the descent part of his parabolic jump trajectory, dropping down on the far side of the solid blocks.

 

This explains why Willy gets 'stuck in the hole' in the JSW2 'Bathroom' test file that I uploaded earlier in this thread.

Attached Thumbnails

  • Tree Top Jump 1.png
  • Tree Top Jump 2.png
  • Tree Top Jump 3a.png
  • Tree Top Jump 3b.png


#18 Spider

Spider

    XOR (HL)

  • Administrator
  • 3,135 posts

Posted 07 January 2018 - 01:42 PM

That does make logical sense to me. :)


  • IRF likes this
Changing order to chaos since 1984

#19 Norman Sword

Norman Sword

    Advanced Member

  • Member
  • PipPipPip
  • 124 posts

Posted 07 January 2018 - 02:42 PM

What Logic dictates and what actually happens.

.

.

The black squares represent wall tiles

.
.
Left block diagram: part 1: willy occupies the red squares and is trying to move upward and left. All checks to the left indicate that the two blues squares are free but the lower square contains a wall (black square). movement left is blocked. Movement vertically is free. So willy moves upward.

.

.

Middle block diagram: Part 2: willy at this point is cell aligned and still moving upward and left. The orange squares are checked and found to be free. Willy is moved left and upward into the squares.

.

The arc of his flight moves onward till we arrive at picture 3

Right block diagram: Part 3: willy is cell aligned and wants to move left and downward. The question here is are the cells/squares in green free to move into. The answer being yes. Willy should be moved across the cell boundary into the green squares.

.

But in part 3 JSW has a specific check, that affects the outcome:-
Willy is falling and the code (listed) below checks for what is beneath his feet. Even though at this point willy will not actually enter both of the squares that are checked below his feet. Willy is moving diagonally downward, and he moves both vertically and horizontally across cell boundaries. The check below does not move horizontally across the cell boundary and checks directly beneath Willies feet. (this is a bug)

.

*** Note the problem is due to incorrect horizontal cell checking.

.

This incorrect cell check, stops the jump and Willy lands on the wall.

.

The complete Jet Set Willy RAM disassembly 20171113
© 1984 Software Projects Ltd. © 2017 Richard Dymond.
Created using SkoolKit 6.1.
.
If we get here, then Willy is standing on the floor or a ramp, or he's falling, or his jumping animation counter is 13 (at which point Willy is on his way down and is exactly two cell-heights above where he started the jump) or 16 (at which point Willy is on his way down and is exactly one cell-height above where he started the jump).

8E36 LD A,($85CF)      Pick up Willy's pixel y-coordinate from 85CF

8E39 AND $0E              Is Willy either on a ramp, or occupying only four cells?
8E3B JR NZ,$8E62       Jump if not
8E3D LD HL,($85D3)    Pick up Willy's attribute buffer coordinates from 85D3
8E40 LD DE,$0040       Point HL at the left-hand cell below Willy's sprite
8E43 ADD HL,DE
8E44 BIT 1,H                Is this location below the floor of the current room?
8E46 JP NZ,$94D2       If so, move Willy into the room below
8E49 LD A,($80BB)      Pick up the attribute byte of the nasty tile for the current room from 80BB
8E4C CP (HL)               Does the left-hand cell below Willy's sprite contain a nasty?
8E4D JR Z,$8E62         Jump if so
8E4F INC HL                 Point HL at the right-hand cell below Willy's sprite
8E50 LD A,($80BB)      Pick up the attribute byte of the nasty tile for the current room from 80BB (again, redundantly)
8E53 CP (HL)               Does the right-hand cell below Willy's sprite contain a nasty?
8E54 JR Z,$8E62         Jump if so
8E56 LD A,($80A0)      Pick up the attribute byte of the background tile for the current room from 80A0

8E59 CP (HL)               Set the zero flag if the right-hand cell below Willy's sprite is empty

8E5A DEC HL               Point HL at the left-hand cell below Willy's sprite

8E5B JP NZ,$8ED4      >> Jump if the right-hand cell below Willy's sprite is not empty
8E5E CP (HL)               Is the left-hand cell below Willy's sprite empty?
8E5F JP NZ,$8ED4      >> Jump if not
8E62 LD A,($85D1)     Pick up the airborne status indicator from 85D1
8E65 CP $01               Is Willy jumping?
8E67 JP Z,$8FBC        Jump if so
.

The above logic flaw is why he lands on a wall, that his parabolic arc should have permitted him to cross.
.

Note also that this flaw extends into the checks for nasties (which kill). And results in Willies inability to jump nasties at head height.

.

 

. 2nd diagram might improve clarity. (willy outline is not indicative of animation frame)

Attached Thumbnails

  • willy tiles1.jpg
  • block3.jpg

Edited by Norman Sword, 09 January 2018 - 03:25 PM.


#20 Norman Sword

Norman Sword

    Advanced Member

  • Member
  • PipPipPip
  • 124 posts

Posted 07 January 2018 - 02:53 PM

This is also probably the bug the lets Willy move into the floor/wall tile when jumping right into the wall gap (next to the priest) in the "First Landing" . Again the check for beneath his feet incorrectly checks the tiles beneath his feet and not the tiles his feet are about to land on.

Like so many other parts of the code, other checks can/could prevent this.


Edited by Norman Sword, 07 January 2018 - 08:16 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users