MM/JSW disassemblies: 20160511

[IRF]

Richard has recently updated his JSW and MM disassemblies. Amongst other interesting additions, he has made a useful distinction between the 'Start the Game' routine, and the 'Initialise the Current Room' entry point into that routine:

 

http://skoolkid.github.io/jetsetwilly/asm/88FC.html

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

Edited January 5, 2017 by IRF

[Spider]

Richard has recent updated his JSW and MM disassemblies.  Amongst other interesting additions, he has made a useful distinction between the 'Start the Game' routine, and the 'Initialise the Current Room' entry point into that routine:

 

http://skoolkid.github.io/jetsetwilly/asm/88FC.html

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

Yes I noticed this just a couple of days ago. :) I keep an offline copy for reference of them (the decimal ones)

[IRF]

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).

I think I should correct myself there - that doesn't sound right! If a cell's value in the attribute buffer is set to match the current room's Ramp attribute byte, then the pixel pattern for Ramp should also be drawn to the corresponding address in the screen buffer - at least initially.

 

However, in subsequent time-frames, the first and third graphic bytes of the cell where the Ramp and Conveyor intersect, will be overwritten by the first and third pixel-row of the Conveyor's cell-graphic, due to the application of the 'Move the Conveyor' routine. Therefore the cell will take on a 'hybrid' appearance, assuming the Conveyor pattern in the first and third pixel-rows, but retaining the Ramp pattern in the second, and the fourth to eighth pixel-rows.

 

The exception would be if the Ramp intersected at the leftmost cell of the Conveyor, in which case the entire Ramp should be visually unaffected (apart from displaying animation in the pertinent Ramp cell), but the first and third graphic byte of the Ramp will overwrite the first and third pixel-rows along the entire length of the Conveyor! (With all other pixel-rows of the Conveyor being unaffected.)

 

That's because the 'Move the Conveyor' routine picks up the appropriate graphics from the cell at the pre-defined left-hand end of the Conveyor (even if that cell has since been overwritten, because Ramp attributes are distributed across the attribute buffer after Conveyor attributes), and then the routine copies those rotated graphic bytes rightwards across the rest of the predefined Conveyor length.

Edited January 22, 2017 by IRF