Jump to content


A total rewrite of JSW in 48k using Matthews core code

  • Please log in to reply
52 replies to this topic

#51 IRF


    Advanced Member

  • Contributor
  • 3,692 posts

Posted 16 January 2018 - 03:57 PM

IRF, on 25 Oct 2017 - 12:06 PM, said:

The 'extending/retracting' platform at the top-left of The Bathroom reminds me of the moving platform in one of the Geoff Mode patches (in 'Willy Takes a Trip's room 10: 'A Quiet Corner to Rest in'), except that in The Bathroom it has 'asymmetrical logic':

- After the Geoff Mode moving platform has been moved along by a cell-column in either direction, the room cell which it has just vacated is restored with an Air block;

- In Norman's The Bathroom, the cells to the right of the platform are reverted to Air as the platform retracts leftwards, but when the platform is extending rightwards, the cells to the left of the rightmost end of the platform remain as floor/Water cells.

Norman Sword replied:

A quick explanation of terms

Master screen. Where the basic screen, minus sprites etc. is drawn

Working screen. The master screen is copied here and the sprites added

Real screen. Where the working screen is copied and is visible to the player

Moving a one cell platform left or right, takes up very little effort or code. Because the rooms are redrawn from the master Attribute copy, and the master screen copy on each game loop. Any additional graphics etc. written just to the working copy screens will be deleted on each game loop, by the copying from the master to the working screens. Thus to move a single square requires just writing to the working screen a single graphic on each loop.

Rather than work on the working copy screens. The platform data was written to the master screens. And as above writes just one graphic either a background (erase) or a platform (write) after any necessary delay. The code was written to have expanding contracting floors and not a single moving block.

NOTE the difference in action, it looks the same, but the first method has to write the graphic on each and every game loop. The second method only writes when there is a change. The accumulative addition of unneeded code is a major factor in the speed of game play.

I meant to reply to this earlier but forgot. The Geoff Eddy patch which draws a single moving block (disassembly below) does actually work on the Master Screen, rather than the Working Screen, and so it does have to erase the previous block's position after it has moved. However, it does both of those things during every game loop anyway, which seems like it could be a waste of effort (causing a needless slowing down of the game), based on what you said above.

The reason that the block has to be drawn to the Master Screen and not the Working Screen, is because the Patch Vector subroutine is CALLed from the Main Loop after Willy has been moved during each time-frame. So at the point in time where the 'Move Willy' routine tests for a solid platform underneath Willy's feet, the moving block would not yet exist if it was being created at the Working Screen level.

10 (A Quiet Corner to rest in)
You'll have seen what happens here, no doubt.

B9CE 085F DEFW #5F08 ; important address: middle of screen
B9D0 ED5BCEB9 LD DE, (#B9CE) ; get hold of it
B9D4 21A080 LD HL, #80A0 ; start of gas block data
B9D7 CDC897 CALL #97C8 ; print it

B9DA 3ACB85 LD A, (#85CB) ; timer
B9DD CB7F BIT 7, A ; if it's > 127
B9DF 2801 JR Z, #B9E2 ; then invert it so that
B9E1 2F CPL ; A goes from 0 to 127 and back
B9E2 FE60 CP #60 ; make sure that A
B9E4 3802 JR C, #B9E8 ; is always between
B9E6 3E60 LD A, #60 ; #60 and #20
B9E8 FE20 CP #20 ; so that the block
B9EA 3002 JR NC, #B9EE ; waits for a bit at each end
B9EC 3E20 LD A, #20 ; of its travels

B9EE CB3F SRL A ; divide A by 4 so that
B9F0 CB3F SRL A ; the block moves slowly enough
B9F2 5F LD E, A ; to be walked on
B9F3 21B280 LD HL, #80B2 ; print it
B9F6 CDC897 CALL #97C8
B9F9 ED53CEB9 LD (B9CE), DE ; and save its location

#52 IRF


    Advanced Member

  • Contributor
  • 3,692 posts

Posted 26 February 2018 - 02:35 PM

typical block move



LD BC,1024


Change to



LD A,1024/32


I think the references to 1024 in the above should read 512? (Number of attributes/cells in the playable screen.)

N.B. The source post from which the above quote is taken is correct in stating that the number of graphic bytes in the playable screen is 4096.

#53 IRF


    Advanced Member

  • Contributor
  • 3,692 posts

Posted 11 May 2018 - 10:33 AM

In this version ropes can be specified for position and length. It will also be noted that the ropes do not pick up willy when they pass though an object. It is permissible for other sprites to cross the ropes path. It is also permissible for ropes to collide with each other.


I would hazard a guess that the way that was achieved was by modifying the rope-drawing code, so that collisions are detected in the same way as the arrow-drawing code. i.e. a pixel-collision has to take place when a segment of rope is drawn AND the attribute of the cell within which that rope segment is being drawn also has to have a white INK setting?

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users