Jump to content
Jet Set Willy & Manic Miner Community

MM/JSW disassemblies: 20160511


SkoolKid

Recommended Posts

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 by IRF
Link to comment
Share on other sites

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)

Link to comment
Share on other sites

  • 2 months later...

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 by IRF
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.