Free space and code optimisation in "JSW"

[IRF]

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

Edited June 6, 2019 by IRF

[jetsetdanny]

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

[IRF]

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:
http://jswmm.co.uk/topic/185-free-space-and-code-optimisation-in-jsw/page-18?do=findComment&comment=8172

(The SET (HL) might have to be replaced with a RES (HL) to keep Willy running.)  EDIT: I'm not sure about that bit so I've struck it out.

Edited January 15, 2019 by IRF

[IRF]

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

[IRF]

From post 77 in this thread:

 

; 100% elimination of all attribute cell block drawing effects

; permits multiple graphic definition with the same colour (attribute) **

; ** Matthews code will still give stair/ramps ramp/stairs stair/floor etc

 

I think I'm right in saying that the 'multiple graphic definitions with shared colour attributes', made possible in JSW via Norman Sword's approach to expanding the room graphics, would NOT be possible in Manic Miner?

 

Because of the way that the cavern layouts are distributed: each cell is assigned a block type based purely on its colour attribute, so for example if you had crumbling walls, it would be impossible to distinguish between blocks that are intended to use the graphic defined for crumbly and ones that are meant to be drawn using the solid wall graphic definition.

 

Therefore you could only have one graphic for such a combined block type; it would use the graphic of the first block type to appear in the list - see http://skoolkid.github.io/manicminer/asm/8020.html for the order in which block types are considered.

 

However, all the blocks drawn with the shared attribute/graphic would exhibit the behaviour of both crumbly and wall (in the example above). i.e. they would stop Willy walking/jumping through them, but they would crumble away when he stands on them.

[IRF]

Note to self: my shared code for left-right horizontal guardian movement could be optimised further.

 

e.g. Instead of having LD A, (IX+$06) then LD B,A - just do LD B, (IX+$06).

 

Also use a shared command at the end LD (HL),A to update the animation frame (i.e. an earlier jump destination).

 

 

(Temporarily posting this here because on the PC I'm currently using, I can't seem to edit earlier posts.)

[IRF]

 

 

The above approach may be more appropriate for optimising the horizontal guardian movement in Manic Miner (i.e. having a shared set of commands for both left and right movement), since the guardians 'face themselves' in their sprite pages rather than being 'back to back', and as a result there would not be a need to swap the two halves of each sprite page.  I haven't tried it out yet though.

 

 

 

Having thought about the above, I'm not sure if it's feasible to come up with an arrangement that's more byte-efficient than the current one.

 

Firstly, the direction of travel for horizontal guardians would have to be determined from Bit 2 of Byte 04. But there's no easy way of checking when the value in Byte 4 has spilled over past Bits 0-2, other than by checking for the individual values 08 or -01 (#FF). The Carry Flag wouldn't respond in these circumstances.

 

Maybe if all the values for animation frame were doubled (and the 'Draw the horizontal guardians' routine was amended accordingly, with an additional RRCA inserted at #8DD0), then the Half-Carry Flag could be used. But I don't think there are any Z80 instructions (conditional jumps etc) which are determined by the status of the H Flag.

 

You would need to fundamentally change the function of Byte 04 for horizontal guardians - edit all the horizontal guardian data, so that Bits 5-7 holds the animation frame (with Bits 0-4 unused, although perhaps they could be recycled for other purposes?), rewrite the 'Move the horizontal guardians' routine in accordance with my previous post, and then NOP out the three RRCA's in the 'Draw the horizontal guardians' routine at #8DCE-#8DD0.

 

Probably not worth the hassle.

 

To contradict myself again, I managed to get my suggested approach to work in Manic Miner. :)

 

I used three RRCA's at the start of the 'Move the horizontal guardians' routine to rotate the animation frame (loaded up to A) into Bits 5-7, and then three RLCA's at the end of the same routine to rotate the updated frame value back into Bits 0-2, before loading back into guardian Byte 04.  (No need to change 'Draw the horizontal guardians'.)

 

Even with all those additional rotate commands, there are still at least ten spare bytes left over because of the merging of the left-right movement commands!

[jetsetdanny]

Well done, Ian, congratulations! :)

[Spider]

Well done, Ian, congratulations! :)

I can only concur. :)

[IRF]

For the record, in my code which optimises the horizontal guardian movement routine (by using shared code for both left and right movement), there is a further optimisation to be had by replacing:

 

LD A, (IX+$06) / LD A, (IX+$07)

LD B, A

 

with:

 

LD B, (IX+$06) / LD B, (IX+$07)

 

 

EDIT: Now implemented at source.

Edited June 4, 2019 by IRF