MM/JSW disassemblies: 20160511

[IRF]

Et voila!  Please see attached Zipped files, with an eight-frame vertical Spinning Balls/Atlases/Love-Eggs(?!) guardian implemented in 'On a Branch over the Drive'.

 

I've created two different variants: 'back-and-forth' (animation frames were compiled as per my previous post) and 'round-and-round' (frames 4-7 are based on frames 0-3 respectively, but each is rotated through 180 degrees).

 

As highlighted in my previous post, Bit 7 of Byte 0 of the guardian definition is used in the process.  In fact, you could set that bit to 1 in the guardian definition for Class 3E, if you wanted the guardian to select one of the new sprites as the initial frame of animation, upon Willy's entry to the screen.

8 frame vertical.zip

Edited June 29, 2016 by IRF

[jetsetdanny]

Congratulations on this novelty, Ian! :)

 

I like the round-and-round one better. There is something disconcerting to its movement...  :unsure:

[IRF]

Congratulations on this novelty, Ian! :)

 

I like the round-and-round one better. There is something disconcerting to its movement...  :unsure:

 

I'm not sure this is really a 'novelty' - there must be other examples of JSW games containing eight-frame Vertical Guardians, surely?

 

Andy and I casually inserted one into the (forthcoming) Mini JSW project, without even considering that it might be a novel feature...

(I'm referring to the Plant Pot in Top Landing; sprites 'borrowed' from Tech Ted.)

 

I only created a quick example to illustrate the point that the highest bit of the first byte of the guardian definition is brought into play for both horizontal [where it determines the guardian's direction] AND vertical guardians...

Edited July 1, 2016 by IRF

[IRF]

Suggestion for a JSW Trivia entry: The way that the three-component Evil Priest Guardian (The Chapel, Priest's Hole, Entrance to Hades) is compiled is sub-optimal.  Three Guardian Classes (Entity Types) are used, whereas it is only necessary to use two - the upper-left and upper-right components could share a Guardian Class, with different Base Sprites selected!

Edited July 5, 2016 by IRF

[jetsetdanny]

A very good suggestion - something which definitely belongs to the Trivia section!

[IRF]

In the JSW disassembly 'Move Willy (1)' routine section, the code at 36508 is described as an entry point that is used to update Willy's attribute buffer location when he is on as Rope.

Whilst that is true, the same section of code (from 36508 to 36527) performs the same function when Willy is falling (it is 'carried on into' from the code that directly precedes it), and also when Willy is jumping (it is called from 36340, or else from 36550 when Willy's head is being ejected from a wall tile).

Perhaps a note could be added to that effect, to clarify things?

 

Also, the routine that starts at #88FC is titled 'Start the Game' in the disassembly, but 99% of the time that it it is called up - via the entry point at #8912 - it does not in fact mark the start of the game, but rather an occasion when Willy enters a new room, or when the room state is reset after Willy has lost a life.  So I wonder if there could be a more comprehensive name for that routine?

Edited July 9, 2016 by IRF

[IRF]

Something else for the Trivia section (or possibly the Bug section?):

The instruction at #8984-8986 has the effect of resetting Willy's 'Rope Status' (to 'Willy is not on a Rope') when he climbs up to the top of a Rope and emerges into the room above.  It needs to do this because the Rope-drawing code doesn't deal with this scenario - the 'Draw the Guardians' routine at #91BE only deals with Willy's exit from a Rope when he falls off the bottom of it, whilst when Willy jumps off a Rope, this is dealt with by the code at #8F8F in 'Move Willy (2)'.

However, #8984 only does 'half a job', because there is another indicator that the program uses to determine whether Willy is on a Rope - Bit 0 of Byte 11 of a Rope's definition.*  That is reset when Willy jumps or falls off a Rope (in the next time-frame, at #9369), but not when he climbs up to the top!  (EDIT: Nor is it reset if Willy loses a life whilst he is clinging to a Rope. e.g. if he is struck by an Arrow.)

This can on occasion give the program the impression that "Willy is not on a Rope, but he is on this Rope!" - with some rather quirky consequences!!  (He said mysteriously...)

(*As I previously reported, the 'Entity buffer' section of the JSW disassembly erroneously states that Bit 7 of Byte 11 is used for this purpose.)

 

EDIT: By way of further explanation, Bit 0 of Byte 11 of a Rope's definition is specific to that particular Rope - a kind of 'This Rope Flag' (for want of a better term) - whereas the Rope Status Indicator is more of a generic indicator.  Thus the 'This Rope Flag' (or perhaps 'Specific Rope Flag' would be a better name) allows the program to make a distinction as to which Rope Willy is on, in a room with multiple Ropes in a modified game.

ADDITIONAL COMMENT: In certain circumstances, the code can be tricked into believing that Willy is on two Ropes at the same time, with yet more quirky effects!

Edited July 13, 2016 by IRF

[IRF]

(Note that in the Manic Miner recording, Willy actually jumps briefly off the top of the screen!)

 

Regarding the above, when Willy jumps off the top of the screen (actually wrapping round to the bottom, as Willy's y-coordinate can't be negative - you can briefly see his head below/within the platform at the bottom of the screen!), it also causes corruption to Room 7: Miner Willy Meets the Kong Beast. See the attached screenshots.

 

This occurs because, in trying to draw Willy at a y-coordinate greater than 224 (#E0), the routine at #927F (that is supposed to draw Willy's sprite to the Occupied Screen Buffer at #6000), over-shoots the bottom of the Screen Buffer Address Lookup Table (#8300-83FF), thus reaching code in the 'The game has just loaded' routine. There it picks up an address (specified at #8404) that corresponds to somewhere in cell-row 6 of page #CC of the code [amongst other addresses, which are mostly in the ROM and are therefore immune from being overwritten, although the stack address at #9CFE - as specified at #8402 - may also be overwritten in the process. I'm not sure whether that would have a detrimental effect on the operation of the program?]

 

The affected addresses are overwritten by some of Willy's sprite's graphic bytes (which are stored in the range #8200-82FF), although the location in Room 7's data to which those graphic bytes are written, means that they are interpreted by the room-drawing code as attribute bytes.

 

More specifically, values of '#3F' and '#F0' are written to #CCCB and #CCCC respectively. The former corresponds to a colour-attribute of 'White Ink on White Paper', hence the solid (non-Bright, non-Flashing) White block.

 

The latter 'F0' corresponds to a colour-attribute of 'Flashing, Bright Black Ink on Yellow Paper'. Because 'F0' also corresponds with a graphics byte specified in the Room 7 data (the top pixel row of the Conveyor tiles), the Cell-Graphics Bug also kicks in, and so the right-hand errant block (at #CCCC) has a non-blank pixel pattern: pixel-rows 0-6 correspond to the 2nd to 8th graphic bytes specified for the Conveyor, whilst the final pixel row of the new block is a graphical representation of the attribute byte for the Nasty 1 tiles (04 - Green Ink on Black Paper).

 

N.B. In terms of Willy's interaction with them, both of the newly-inserted blocks behave as Water cells.

See attached rzx recording.

Edited July 12, 2016 by IRF

[IRF]

In the Entity Buffer at #8100, the description of Byte 9 of the Rope definition should read: "Index of the segment of rope being drawn (0-32)"

 

As opposed to (0-31) which it currently states.

 

As previously discussed, there are actually 33 segments to the Rope, although only Segments 1-32 are drawn using coordinate offsets drawn from the table at #8300; Segment 0 is drawn at the top with no offsets applied.

 

This may seem 'picky', but the detail is quite crucial to understanding how certain quirky features of the code operate!

 

By the way Richard, can I just reiterate what an invaluable resources your disassemblies have been, as I have endeavoured to get my head round the intricate workings of the JSW/MM game engine!

Edited July 13, 2016 by IRF

[jetsetdanny]

By the way Richard, can I just reiterate what an invaluable resources your disassemblies have been, as I have endeavoured to get my head round the intricate workings of the JSW/MM game engine!

 

Same here. Amen!