Free space and code optimisation in "JSW"

[Norman Sword]

Expanding on the theme

 

 

; The value in (ix+$05) is only used locally
 

X9278    

;>>9278 LD (IX+$05),$00 

           LD BC,$700            ;-1 B=7 C=0

X927C LD A,(HL)
;>>927D AND $07

;>>927F CP $07 

            INC A                     ;-2
            AND B                   ;-3

X9281 JR NZ,L_9286 
;>>9283 DEC (IX+$05)

            DEC C                   ;-5

L_9286

            LD A,(HL)
;>>9287 OR $07
            OR B                      ;-6

X9289  LD (HL),A
X928A  INC DE 
X928B  LD A,(DE)
X928C  LD H,A 
X928D  DEC H
X928E  LD A,(IX+$06)

            LD B,A                    ;-5
X9291  LD (HL),A
X9292  INC H 
X9293  LD A,(HL) 

;>>9294 AND (IX+$05)
            AND C                      ;-7

X9297  JP NZ,$90B7             ;>>>>> kill Willy

X929A  LD (HL),$FF  
X929C  INC H 
;>>X929D  LD A,(IX+$06)

;>>X92A0  LD (HL),A

            LD (HL),B                 ;-9
X92A1  JP $93B3 

 

 

 

Edited November 7, 2017 by Norman Sword

[IRF]

;>>X929D LD A,(IX+$06)

 

;>>X92A0 LD (HL),A

 

LD (HL),B ;-9

 

 

I believe that the running total of saved bytes at that point should be 10, rather than 9?

 

I think it could also be done without using B (the net byte-saving would be the same). From #928E (rejigged code shown in bold):

 

LD A,(IX+$06)

LD (HL),A

INC H

INC H

LD (HL),A

DEC H

LD A,(HL)

AND C

JP NZ,#90B7 ;>>>>> kill Willy

LD (HL),#FF

JP #93B3

 

The above arrangement would also mean that the arrow is drawn in its entirety at the moment when it hits Willy (whereas in the original code, only the top pixel-row is drawn at the point of death).

[IRF]

Error in Norman Sword's post about the conveyor animation?:

http://jswmm.co.uk/topic/185-free-space-and-code-optimisation-in-jsw/page-8?do=findComment&comment=6105

 

L38163 LD A,(HL) ; Copy a pixel row of the conveyor tile to A

 

Shouldn't that be a LD A,(DE) in the context of the revised logic?

[Norman Sword]

I believe that the running total of saved bytes at that point should be 10, rather than 9?

 

I think it could also be done without using B (the net byte-saving would be the same). From #928E (rejigged code shown in bold):

 

LD A,(IX+$06)

LD (HL),A

INC H

INC H

LD (HL),A

DEC H

LD A,(HL)

AND C

JP NZ,#90B7 ;>>>>> kill Willy

LD (HL),#FF

JP #93B3

 

The above arrangement would also mean that the arrow is drawn in its entirety at the moment when it hits Willy (whereas in the original code, only the top pixel-row is drawn at the point of death).

 

 If the code had been written as

 

Ld a,(ix+$06)

ld (hl),a

inc h

inc h

ld (hl),a

dec h

ld a,(hl)

and c

ld (hl),$ff

jp nz,#90b5   ;>>>> kill willy

jp #93b3

 

Then it might have been a valid point on drawing the arrow

 

Otherwise you have returned and not drawn the arrow shaft. 

 

Byte code is purely a guide. (the count is indicating a trend- nothing more)

Edited November 8, 2017 by Norman Sword

[IRF]

Yes, that's what I meant. (Draw the arrow shaft first before reacting to the Zero Flag.)

In relation to the byte count, I merely meant to point out that you did yourself a disservice!

Edited November 17, 2017 by IRF

[Norman Sword]

Error in Norman Sword's post about the conveyor animation?:

http://jswmm.co.uk/topic/185-free-space-and-code-optimisation-in-jsw/page-8?do=findComment&comment=6105

 

 

Shouldn't that be a LD A,(DE) in the context of the revised logic?

 

 

The listings I have provided are created ad hoc.

 

 

; the version I have currently looks like this. Next week it might be changed again

 

  JR Z,TOTHER

   EX DE,HL

TOTHER

   LD A,(DE)   :>>>>>> the opcode in question

   LD C,(HL)

   RLC A

   RRC C

  CON_DO

  LD (DE),A

  LD (HL),C

  INC E

  INC L

  DJNZ CON_DO

  RET

 

 

But I will go back and change the opcode...

 

The link back to the code, does not provide any means of editing the code.

Edited November 8, 2017 by Norman Sword

[IRF]

That looks like it only rotates the pertinent pair of graphic bytes once per time-frame?

 

Meaning that the Master Bed would visible animate? (Whereas it doesn't in the original game, because the pixel pattern is such that two rotations, in either direction, leave the value of the bytes unchanged.)

 

Talking of making tweaks to the original arrangement, adjusting the number of INC H commands will allow a different pixel-row of the conveyor, at an arbitrary depth beneath the top pixel-row, to act as the counter-rotating element of the conveyor.

[IRF]

The link back to the code, does not provide any means of editing the code.

 

Don't worry, it's here on record now. Thank you for the clarification (and for the original optimisation!)

[Norman Sword]

The reason I only rotate once is simply because I do not like the original animation.

 

When willy or a sprite is animated on a conveyor, the speed the conveyor moves is exactly the same speed as willy moves. (or a standard horizontally moving sprite) 

 

Simple logic dictates that if the conveyor is moving in the same direction as willy and at the same speed then the conveyor is static below willies feet. It then follows that willy should not be animated. He should stay in the same frame and move graciously and serenely along the conveyor without moving a limb. The game does not provide that kind of animation, so my compromise is to move the conveyor at a slower speed to justify the animation.

 

The speed change is also linked to the direction byte. (not listed in the code because it is not part of the original) but in my versions, the direction byte also stores animation status bits. The bits switch on/off animation. 

 

e.g. In this manner/style (done by me, in various edits)

 

bit 5 no animation of the conveyor. Return immediately.

bit 6 no lower animation of the conveyor . point high of register pair  to "0"

bit 7 reverse animate the conveyor (reverse animate, just to confuse) .xor bit with direction bit before testing 

 

By testing a bit in the direction byte. Either HL or DE can be set to point to the ROM. By setting "D" or "H" to 0. This allows the following code to stay the same. But the registers pointing to the ROM will stop the appropriate animation from being shown. 

 

 

The code as used by Matthew can easily be modified to use a consistent check on the direction byte. e.g. ignore all the other bits, which then become available to use. .

Edited November 9, 2017 by Norman Sword

[Norman Sword]

Byte saving.

 

This is something that Matthew does as part of the code to move down the screen from raster line to raster line.

 

ld a,l                    ;line  1
add a,$20           ;        2
ld l,a                    ;       3

and $e0               :      4  
ret nz ; or jr nz (depending on version)

 

I just wonder why the opcode  -and $e0- is used on line 4.

The addition on line 2 - add a,$20 - has set the carry flag for all the conditions that are wanted. The code should be.

 

ld a,l                    ;line 1
add a,$20           ;       2
ld l,a                    ;       3
ret c ; or jr c (depending on version)

 

This save two bytes.

 

Since various mods have been used around this area, The exact condition Carry or no carry, will depend on what else is happening around this code area. 

Edited November 9, 2017 by Norman Sword