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

[IRF]

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

B9FD C9 RET

 

[IRF]

typical block move

 

 

 

LD HL,COPY

 

LD DE,SCREEN

 

LD BC,1024

 

LDIR

 

 

 

Change to

 

 

 

LD HL,COPY

 

LD DE,SCREEN

 

LD A,1024/32

 

CALL BLOCK32

 

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.

[IRF]

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?