MM/JSW disassemblies: 20160511

[IRF]

P.P.S. Another thought that was sparked by the previous one:

The cells in Rescue Esmerelda containing ramps have byte value suggesting they are occupied by Water cells. Which of course, they are. This screen and others (most notably Out on a Limb) have multiple Water-Ramps, achieved by matching the attributes for Water and Ramp cells.

This is something that the JSW disassembly doesn't mention. There is an entry covering Conveyor-Ramps aka Escalators (e.g. The Chapel - see 'Slippery Slopes' in the Trivia section), but no mention of the Water-Ramps as far as I am aware?

Edited May 24, 2016 by IRF

[IRF]

the routine at 36203 is ordered such that conveyor attributes (and then ramp attributes) overwrite all the attributes that were previously laid out on the screen buffer

 

Curiously, the order in which ramp and conveyor attributes are laid out is the opposite to the way in which their pixel patterns are drawn, meaning that if a ramp intersects a conveyor, the cell where they cross has the same pixel pattern (with animation) as the conveyor, but the colour-attribute of the ramp (and so the same underfoot behaviour as a ramp).

 

EDIT: The above refers to what you see 'in-game'. In JSWED, the ramp pixel pattern (unanimated) is drawn, rather than the conveyor pixels.

 

(Sorry Richard, I think I've veered off-topic!)

Edited May 25, 2016 by IRF

[jetsetdanny]

Scrap that, the routine at 36203 is ordered such that conveyor attributes (and then ramp attributes) overwrite all the attributes that were previously laid out on the screen buffer, 

 

If I understand your point correctly, I would add that you realise this when working in JSWED: often when you delete a conveyor or a ramp (let's say, working on a room which you didn't design yourself), you suddenly see that there were Earth or Water cells beneath it. My first instinctive reaction to it was: How come?, until I realised that ramps and conveyors "supersede" the other types of cells without actually "overwriting" them.

[IRF]

If I understand your point correctly, I would add that you realise this when working in JSWED: often when you delete a conveyor or a ramp (let's say, working on a room which you didn't design yourself), you suddenly see that there were Earth or Water cells beneath it. My first instinctive reaction to it was: How come?, until I realised that ramps and conveyors "supersede" the other types of cells without actually "overwriting" them.

I spotted the Earth cells 'behind' the conveyor in Esmeralda as I was studying the raw data for the room layout in the disassembly! (Whilst trying to figure out a POKE to add an extra Earth cell below the conveyor.)

Edited May 14, 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)?

[IRF]

Another suggestion for the disassembly:

The POKE that fixes the 'uncollectable item' in Conservatory Roof (the rightmost item) does not fix the fact that Willy has to sacrifice a life in order to collect the leftmost item in that room.

A simple single-POKE fix for this is to extend the green platform to the left of the conveyor by one cell leftwards: POKE 60269, 1

EDIT: Sorry, having playtested this you would also have to 'delay' the Red guardian by shifting its starting position rightwards by one cell, otherwise Willy couldn't jump over it in time without hitting a fire cell: POKE 60401, 21

Still, it only takes two POKES (on top of the Software Projects one that removes the rightmost fire cell) to make this screen completable without loss of life.

 

However, see the following link for a more satisfactory visual fix which, by shifting all the fire cells and items along to the left by one cell (and rejigging a couple of platforms), manages to keep them all paired up (as per the original screen), whilst ensuring that all four items can be collected without losing a life:

http://jswmm.co.uk/topic/65-conservatory-roof-changes/?p=4310

 

That would take quite a few POKES, although it should be within Richard's ten-POKE limit: four to shift the items individually, three to move the fire cells (room cell attributes are grouped in blocks of four per byte) and three to rearrange the water cells near the bottom (ditto).

 

EDIT: Let's see, these should do it:

 

POKE 42421, 30

POKE 42422, 24

POKE 42423, 27

POKE 42424, 21

POKE 60229, 195

POKE 60230, 12

POKE 60231, 48

POKE 60269, 4

POKE 60270, 16

POKE 60285, 1

Edited May 24, 2016 by IRF

[IRF]

I notice that in his disassembly, Richard has managed to identify the precise cause of the bug (or quirky feature?) whereby a Fire cell at the top of the screen can kill Willy if he drops off the bottom directly underneath:

http://skoolkit.ca/disassemblies/jet_set_willy/reference/bugs.html#longDistanceNasties

I had got as far as surmising that it's something to do with the check for Fire cells, underneath the 2x2 square of cells occupied by Willy, somehow wrapping around from the bottom of the screen to the top.

However, the 'missing link' in terms of the explanation is that the Attribute Buffer for the occupied room (i.e. occupied by guardians, items and Willy) at #5C00, is immediately followed in the code by the Attribute Buffer for the empty room (i.e. the room without guardians, items or Willy - but, crucially, WITH the Fire cells) at #5E00.

Whilst it can be quite a useful bug in terms of preventing Infinite Death Scenarios, I wonder if hypothetically this could be fixed by pointing the check for Fire cells to the Empty Room Attribute Buffer at #5E00 instead of the Empty Room Screen Buffer Occupied Room Attribute Buffer at #5C00?

Any thoughts?

Edited May 23, 2016 by IRF

[IRF]

Oops, typo corrected!  (I was getting ahead of myself, with a half-formed answer to my own question in my own head as I typed - on which more later!)

Edited May 23, 2016 by IRF

[IRF]

I notice that in his disassembly, Richard has managed to identify the precise cause of the bug (or quirky feature?) whereby a Fire cell at the top of the screen can kill Willy if he drops off the bottom directly underneath:

 

http://skoolkit.ca/disassemblies/jet_set_willy/reference/bugs.html#longDistanceNasties

 

I had got as far as surmising that it's something to do with the check for Fire cells, underneath the 2x2 square of cells occupied by Willy, somehow wrapping around from the bottom of the screen to the top.

 

However, the 'missing link' in terms of the explanation is that the Attribute Buffer for the occupied room (i.e. occupied by guardians, items and Willy) at #5C00, is immediately followed in the code by the Attribute Buffer for the empty room (i.e. the room without guardians, items or Willy - but, crucially, WITH the Fire cells) at #5E00.

 

Whilst it can be quite a useful bug in terms of preventing Infinite Death Scenarios, I wonder if hypothetically this could be fixed by pointing the check for Fire cells to the Empty Room Attribute Buffer at #5E00 instead of the Empty Room Screen Buffer Occupied Room Attribute Buffer at #5C00?

 

Any thoughts?

 

To answer my own question, I think it could just cause more problems than it solves!

 

If the check for Fire cells was applied to the Empty Room Attribute Buffer, then it should still correctly pick up Fire cells within the room, but if Willy's sprite occupied the bottom two cell-rows (i.e. as he's falling off the bottom of the screen), then the check for Fire cells underneath him will probably wrap beyond the bottom of the screen to the Screen Buffer (for an occupied room) at #6000 (which contains the pixel patterns of all the room elements and all the entities within the room).

 

Therefore the check for Fire cells will probably pick up the top pixel-row of the cell that lies in the uppermost cell-row directly above Willy.  So if that cell happens to contain something (not necessarily a Fire cell!) whose first graphics byte (i.e. top row of pixels) matches the attribute byte for the Fire cells in that room, then the program will interpret that as if Willy has landed on a Fire cell, and kill him!

 

Any room element (Earth/Water/Ramp cells) at the top of the screen could potentially cause such a match, giving rise to a 'misdiagnosis' that Willy has stood on a Fire cell!

 

It could even occur if an (uncollected) item lies at the top of the screen, whose first pixel-row matches the colour-attribute of the Fire cells.  (N.B. such a match does actually exist in Tree Root, although the items aren't at the top of that screen.)

 

Or if a horizontal guardian happened to pass along the top of the screen, through the pertinent cell, such that the top pixel pattern of the portion of the guardian that instantaneously occupies that cell, matches the Fire cells' colour-attribute at the precise moment just before Willy drops off the bottom of the screen, then it could also trigger a positive check for a Fire cell 'beneath' him and kill him!

Edited May 24, 2016 by IRF

[IRF]

I think the fact that Willy can walk DOWN a ramp into an Earth cell (as in On Top of the House in the original game) is worth a mention in the JSW disassembly.

 

It happens because the routine that checks for Earth blocks when he's trying to walk across a cell boundary, doesn't check for Earth blocks lying two cells below the top of his sprite when he is only occupying two cell-rows (see 36901 / 37012).

 

Which is obviously a good thing when he's standing on two Earth cells (otherwise he wouldn't be able to walk along Earth platforms at all!), but it means that when he's got an Earth cell and a Ramp cell beneath him, the Ramp cell takes precedence when he's walking down.

I've just had a thought - if we were to try to come up with a 'fix' for the above, we'd have to be careful not to implement it in such a way that prevents Willy from walking down the ramp into The Swimming Pool (i.e. through the Water cells - which in this case really do justify that name!)

 

Or for that matter, walking down the Ramp from West Wing Roof to West Wing.

Edited June 25, 2016 by IRF