Free space and code optimisation in "JSW"

[IRF]

It might have been usable, with some optimisation, if I'd spotted it early enough in the development of WNM-SE. No matter!

Edited January 30, 2017 by IRF

[IRF]

I think the CP #FF at #96A3 could be replaced with an INC A (saving one byte).

 

I previously mentioned some similar savings here:

http://jswmm.co.uk/topic/196-dont-mind-your-head-while-walking-left-bug-fix-for-jsw/?p=5802

 

And I originally got the idea from J.G. Harston's second Pause Bug Fix, as listed here:

http://mdfs.net/Software/JSW/JGH/Docs/Pause.htm

 

(I still think that's the most elegant Pause Bug Fix, even though Jonathan has recently added SkoolKid's more byte-efficient solution to the list.)

[IRF]

There are a few instances in the JSW code where the following sequence of commands are used:

 

LD A, (#0000)

INC A

LD (#0000), A

 

That's seven bytes in total.

 

This can sometimes be replaced with the following four bytes (saving three bytes):

 

LD HL, #0000

INC (HL)

 

e.g. the updates within the Main Loop to the game's internal 'ticker' (#85CB), or to the Music Note Index (#85E1). EDIT: And to the Jumping Animation Counter in Move Willy (1).

 

N.B. This approach couldn't be used in circumstances where the HL register-pair is currently in use for another purpose (e.g. to update the Game Mode Indicator during the course of the 'Draw the items' routine), without bookending with PUSH HL and POP HL (which negates two of the three byte saving).

 

EDIT: in circumstances where the program subsequently does something else with the updated variable, then you'd have to follow the above with LD A,(HL), thus reducing the saving to two bytes.

Edited January 28, 2018 by IRF

[Metalmickey]

thinking about the Moonlight Sonata theme music, there's a lot of repetition there, could there not be a way to make that routine more byte efficient? or has that been tried before?

[IRF]

Any savings you might make, may be eaten up by the extra code required to set up a loop to perform the repetitive bits?

[jetsetdanny]

It's not been tried before, TTBOMK, and I doubt there could be much saving, because the repetition is limited. I mean, you may have five notes (values) which are the same as a little bit later on, and then one note (value) which is different. Even though the five are repeated, say, four times, the one different note following them is always different. So making the sequence of five notes repeat but with the one note at the end different each time would be quite tricky, I think.

 

Please note I'm just writing it off the top of my head to illustrate (what I think is) the problem. The info about five notes and then one note is most probably inaccurate, I'm just using approximate numbers to illustrate the pattern.

 

I'm not sure how much spare space you need, but there is quite a lot of it in the original "JSW". SkoolKid shows most (although not all) of it. In the Special Edition of "Willy's New Mansion" we (meaning Ian and myself) have pushed its use to the limit, I believe, trying to use up every single byte of spare space plus introducing various space-saving optimisations to the original code. "WNM SE" Readme documents it thoroughly, so probably you might find some ideas there if you really need some more free space in your project  :ph34r: .

[Norman Sword]

The number of posts means I have not read most of them.

 

This routine expands the graphics as a room is entered

 

 

ROOM ATTRIBUTE FIX and SPACE SAVER

 

 

org     8d33h

 

; start is 8d33h 36147
; end of this is around 8da6h 36262 (lower since mods)

; end of Matthews code  8dd2h 36306

 

; size is less than 115 bytes     saves 44+ bytes

 

L5E00h                  equ     5E00H           ;ROOM ATTRIBUTES
L7000h                  equ     7000h

convey_len            equ     80d9h
convey_add           equ     80d7h
Ramp_len              equ     80Ddh
Ramp_add             equ     80dBh
Ramp_dir               equ     90Dah
Back_Tile               equ     80a0h
Char_print              equ     9699h      ;969bh  in my assembler wrong address given (label was moved)

 

; note ****
; This routine uses only one call
; NO repeated push/pop due to poor register allocation. (in one example I have seen)
; 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
;
; saves around 44+ bytes

Draw_Room
        ld      de,8000h        ;room definition
        ld      HL,L5E00h       ;5e00h the room attributes
EXPANSION
        ld      b,4             ;four cells per byte
        ld      a,(DE)
exp
        rlca
        rlca
        ld      c,a              ;temp save "a"
        and     3              ; values 00b,01b,10b,11b  (types)
        ld      (hl),a          ; write the type into the cell
        ld      a,c             ;restore "a"
        inc     l
        djnz    exp           ; repeat for the byte (4 cells)
        inc     de
        jr      nz,EXPANSION    ; first 256 done
        inc     h               ; this second check is done twice in the 512 loop
        bit     5,h
        jr      z,EXPANSION

; part 1a)   add conveyor tiles (if any).
        LD      A,(convey_len)
        OR      A
        JR      Z,No_Conveyor
        LD      HL,(convey_add)
        LD      B,A
convey_set
        LD      (HL),5          ; write TYPE 5 =CONVEYOR into this cell
        INC     L                  ; The conveyor animation routine also does inc l/inc e
        DJNZ    convey_set

;part 1b) add ramp tiles (if any)
No_Conveyor
        LD      A,(Ramp_len)    ; the only reference to this data in the whole program
        OR      A
        JR      Z,DRAW_TILES
        ld      b,a
        LD      HL,(Ramp_add)   ;

        LD      A,(Ramp_dir)    ;
        LD      DE,-33          ;primary change here is for clarity
        OR      A
        JR      Z,Ramp_set
        INC     E
        INC     E
Ramp_set
        LD      (HL),4          ;write TYPE 4=RAMP  into this cell
; this does not check for screen bounds (or ramp length)
        ADD     HL,DE
        DJNZ    Ramp_set        ;

; NOW EXPAND AND OVERWRITE/DELETE THIS DATA

;L5E00H holds the  TYPES in each cell THIS WILL BE OVERWRITTEN BY THE TYPES attribute from its definition
; THE GRAPHICS WILL ALSO BE EXPANDED TO THE COPY SCREEN
;part 2) expand the room definition into a graphic and attribute definition
DRAW_TILES
        ld      ix,L5E00h       ;start of the TYPE DATA:-  CHANGED as each one is read TO COLOUR DATA
        ld      de,7000h       ;graphic buffer where the graphics will be drawn
loop
        ld      a,(ix)              ;get THE TYPE from its cell

        LD      B,A              ;calculate the graphic (tile)
        ADD     A,A
        ADD     A,A
        ADD     A,A
        ADD     A,B             ; 9 bytes per graphic entry

        LD      HL,Back_Tile
        LD      C,A
        LD      B,0
        ADD     hl,bc           ; the first byte is the graphic (tile) colour

        ld      a,(hl)             ;  the TILES colour attribute
        ld      (ix),a             ; overwrite its type in the attribute buffer with the graphic attribute
        INC     IX                ; next source (attributes/type/cell)
        inc     hl                 ; move from graphics attribute to the graphics definition
        ld      c,d                ; temp save d
        call    Char_print
                ; (what the routine at char_print does)
                ;char_print
                ;       ld      b,8
                ;draw_me
                ;       ld      a,(hl)
                ;       ld      (de),a
                ;       inc     hl
                ;       inc     d
                ;       djnz    draw_me
                ;       ret
; calculate the next char
        ld      a,d               ;save modified d
        ld      d,c              ;restore d
        inc     e
        jr      nz,loop
        ld      d,a             ;reload the modified d
        cp     high(L7000h+1000h)    ; 80h  defined this way for clarity
        jr     nz,loop
        ret

Edited November 26, 2018 by IRF

[Norman Sword]

;In the above I mentioned the conveyor animation

 

 

org     38137

;animate conveyor

:skoolkit comments

L38137  LD HL,(32983)
z38140  LD A,H
z38141  AND 1
z38143  RLCA
z38144  RLCA
z38145  RLCA
z38146  ADD A,high (7000h)      ;112
z38148  LD H,A
z38149  LD E,L
z38150  LD D,H
z38151  LD A,(32985)     ;Pick up the length of the conveyor from 32985
z38154  OR A                 ;Is there a conveyor in the room?
z38155  RET Z               ;Return if not
z38156  LD B,A              ;B will count the conveyor tiles

 

;>added
;>code from here is moved

 

        INC     H
        INC     H                  ;point hl to third graphic row

 

z38157  LD A,(32982)    ;Pick up the direction of the conveyor from 32982 (0=left, 1=right)
z38160  OR A                 ;Is the conveyor moving right?

 

;>changed                      ;z38161 JR NZ,L38182    Jump if so

 

        jr,z,L38163       ;** changed from the incorrect L38316

 

:>added
        ex      de,hl

 

;The conveyor is moving left. (or right)
L38163  LD A,(DE)       ; Copy a pixel row of the conveyor tile to A
z38164  RLC A             ;Rotate it left twice
z38166  RLC A

 

;>deleted

 

                        ;z38168 INC H
                        ;z38169 INC H

 

z38170  LD C,(HL)       ;Copy this pixel row to C
z38171  RRC C           ;Rotate it right twice
z38173  RRC C
L38175  LD (DE),A       ;Update the first and third pixel rows of every conveyor tile in the screen buffer at 28672
z38176  LD (HL),C
z38177  INC L
z38178  INC E
z38179  DJNZ L38175
z38181  RET

 

;The 1 added instruction and slight change in logic flow

;removes the need for the code below 9 bytes shorter

;>deleted
                        ;The conveyor is moving right.
                        ;L38182 LD A,(HL)       Copy the first pixel row of the conveyor tile to A
                        ;z38183 RRC A            Rotate it right twice
                        ;z38185 RRC A
                        ;z38187 INC H              Point HL at the third pixel row of the conveyor tile
                        ;z38188 INC H
                        ;z38189 LD C,(HL)       Copy this pixel row to C
                        ;z38190 RLC C            Rotate it left twice
                        ;z38192 RLC C
                        ;z38194 JR 38175        Jump back to update the first and third pixel rows of every conveyor tile

;-------------------------------------------------------------------------------------------------
;

Edited April 4, 2018 by IRF

[IRF]

jr,z,L38613

I presume that should read "Jr z, L38163"? (Jumps forward by one byte to skip the EX HL, DE command.).

EDIT: That should have read EX DE, HL.

 

That would be a usefully-placed optimisation in Manic Miner, as it would allow the insertion in situ of a test of the Conveyor length ("Is it zero? If so, RET"). Thus allowing a cavern to have no Conveyor animation without corrupting the screen.

 

(In the existing MM code, if you don't have a Conveyor in a cavern, then you have to insert a 'hidden' one, at least one byte in length, within an Air cell. Because the routine that animates the Conveyor interprets a Conveyor length of zero as a length of 256 bytes!)

Edited November 20, 2017 by IRF

[IRF]

; note ****

; This routine uses only one call

; NO repeated push/pop due to poor register allocation. (in one example I have seen)

; 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 Geoff Eddy's games may take a similar approach.  Certainly there's a room in which there are two ramps, drawn in opposite directions.

 

However, getting both ramps to behave as they should in terms of Willy's movement along them (and the pixel-height at which he is drawn whilst on a ramp) requires a Main Loop Patch Vector approach, to vary the Ramp Direction Byte in the room buffer as Willy's horizontal coordinate changes within the room.

Edited October 2, 2017 by IRF