Jump to content


Free space and code optimisation in "JSW"

233 replies to this topic

#231 IRF


    Advanced Member

  • Contributor
  • 3,506 posts

Posted 06 March 2018 - 11:54 PM

I noticed that there are several parts of the JSW code which effectively replicate the same function - namely using the table in page #82 of the code to point HL at the appropriate address for drawing various moving entities onto the pixel display and/or pixel buffer.


So I have rewritten several parts of the code to allow a shared routine to be CALLed (with various entry points) which handles the table at page #82, and saves quite a few bytes (I would estimate about 30-40, all told) in the process:


Entry point from ‘Draw Arrows’/’Draw Guardians’ (Input: B = pixel y-coordinate, C = byte containing x-coordinate):



AND #80


OR #5C




Entry point from ‘Draw Willy’ (Input: B = pixel y-coordinate, A = byte containing x-coordinate):






Entry point for Foot on ‘Game Over’ Screen (Input L = y-coordinate, C = #0F):


LD H, #82

LD A, (HL)



LD H, (HL)



; HL now points at pixel-buffer coordinates (#6xxx); for guardians and arrows, D also points at high byte of attribute-buffer coordinates.




Further code changes to facilitate the above:


In ‘Game Over’, replace the code at #8C71-#8C7F with LD L, A followed by LD C, #0F, then a CALL to the appropriate entry point above and finally a RES 5, H command (adjustment made in order to draw to addresses #4xxx instead of #6xxx).


In ‘Draw Arrows’, the CALL to the above makes the existing commands at #926A-#9277 and #928A-#928C redundant.  The command at #9267 needs to be adjusted to write the arrow y-coordinate to B instead of E, that is then followed by a command to write the arrow x-coordinate to C; then CALL the above; after the CALL have LD E, L; finally, the references to HL at #927C, #9286 and #9289 should be replaced with DE.


In ‘Draw Guardians’, #91D6 writes guardian y-coordinate to B instead of E, follow that with a command which writes guardian byte 02 to C; CALL the above; after the CALL have a PUSH HL then LD H, D; after that, NOP out everything up to (but not including) #91EB; and replace #9220-#922D with POP HL.


[The next two steps rely on the ‘Draw a Sprite’ routine at #9456 having been subject to an earlier rewrite of mine, so that it draws the room’s whole complement of guardians (or Maria), and reacts to any collision after RETurning back to the main guardian-drawing routine.]


In ‘Draw Willy’, after the existing code up to and including #963A, the A register holds Willy's y-coordinate; after that insert LD B, A and LD A, (#85D3), then CALL the appropriate entry point above; #9660-#967F is then redundant; simply point DE at Willy's graphic (the appropriate animation frame, or the Flying Pig if necessary), then set LD C, #01 and JUMP to #9456.


In ‘Draw the Toilet’, replace #95B4-#95BA with LD C, #01 and LD HL, #68BC, then at #95BB change the destination of the CALL to #9456.




The only place where the original code employing the table at #8200 remains unchanged, and I have made no attempt to use the above 'shared subroutine' approach, is within the 'Draw a Rope' routine - I think it would be too complicated to unravel the segment-drawing loop (and it would probably not yield any byte-savings).

#232 jetsetdanny


    Advanced Member

  • Contributor
  • 1,868 posts

Posted 07 March 2018 - 08:19 AM

Thanks a lot, Ian, this optimisation may come in very handy when one needs some spare bytes! :)

#233 IRF


    Advanced Member

  • Contributor
  • 3,506 posts

Posted 09 March 2018 - 01:15 PM

Some changes in logic in the Main Loop which could save a few bytes:

- In between the existing commands at #89CC and #89CE, insert a JR Z, #89E9. Change #89CE and #89DE to unconditional CALLs. Then the commands at #89D9 and #89DC become unnecessary (net saving of three bytes).

- Possibly the three byte command at #89E1 can be done away with too, if the commands at #89E4 and #89E6 are relocated prior to #89CE (the CALL to Move Willy). I would need to check that though, especially if another efficiency that I identified has been implemented:
(The SET (HL) might have to be replaced with a RES (HL) to keep Willy running.)

#234 IRF


    Advanced Member

  • Contributor
  • 3,506 posts

Posted 09 March 2018 - 01:47 PM

Thinking about it, that latter change might mean that Willy is moved and drawn one more time before Game Mode 3 kicks in. Which wouldn't be too much of a problem is he is running towards the toilet, but might mean that he loses a life if he falls into the toilet as part of the end sequence? Area for investigation...

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users