Free space and code optimisation in "JSW"

[jetsetdanny]

The room you are referring to is "The Network Port" (21) in his game "ZX Willy the Bug Slayer" (which has the game engine modified further in relation to his first three games, creating what has become known as "Geoff Mode II"). Geoff offered the following disassembly of the PV which does the trick:

 

; room 21 [Network Port]

9933 21DA80 LD HL, #80DA ; stair direction
9936 3AD385 LD A, (#85D3) ; Willy-s x-coord
9939 E61F AND #1F
993B FE10 CP #10 ; in right-hand half?
993D 3003 JR NC, #9942 ; stairs go left if so
993F 3601 LD (HL), #01 ; otherwise right
9941 C9 RET
9942 3600 LD (HL), #00
9944 C9 RET

 

This PV has also been applied in the room "The River of No Return" (03) in the Special Edition of "Willy's New Mansion", which has two ramps going in opposite directions. To quote from the Readme, "In fact, they are Water-conveyor-ramps thanks to setting the same attributes for Water, conveyor and ramp cells. They use the pixel pattern defined for Water cells, which has been carefully selected, so that their form sits well, visually, in ramps that slope in either direction, and so that they do not display any visible conveyor animation."

Edited April 8, 2017 by jetsetdanny

[IRF]

Char_print              equ     969bh

 

        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

Looking at the above, I believe your Char_print should be pointing at #9699, rather than at #969B, because you've made use of the fact that B is already assigned a value of 08 in the 'Print a single character' routine (at #9699).

 

(An efficiency which Matthew could have made use of with the CALL command at #944E in the 'Draw the items' routine, but he didn't.)

(Also, Geoff Mode could have made use of a similar efficiency, but didn't.)

Edited April 10, 2017 by IRF

[IRF]

This doesn't really fall into the category of 'code optimisation', rather it relates to optimisation of the speed of the game:

 

It strikes me that there is an inefficiency in the part of the Main Loop (in both JSW and MM) which checks the teleport keys (WRITETYPER/6031769).

 

Currently, the program checks if the 'activator' key ('9' for JSW, '6' for MM) is being pressed before it checks whether the teleport key counter has reached the appropriate value to allow the teleport function to be activated.

 

Wouldn't it be more efficient to switch that around, and check the value of the teleport key counter first?  Then in circumstances where it hasn't reached the right value, the program would jump to the next pass through the Main Loop, without having to perform operations relating to '6-0' keypresses.  (Which might be being used as movement keys, thus needlessly causing both checks to take place during the 'teleport' part of the code.)

Edited April 11, 2017 by IRF

[Spider]

It would and it would be better (and how I'd do it) as you simply check the flag first (or the first key!) then if that's "no" there is no point going any further. :)

[Norman Sword]

(An efficiency which Matthew could have made use of with the CALL command at #944E in the 'Draw the items' routine, but he didn't.)

(Also, Geoff Mode could have made use of a similar efficiency, but didn't.)

 

What is the point in this statement. You could have done this and didn't, anyone could have done it and didn't. Your statement is pointless.

[Norman Sword]

My code permits me to re write Matthews game in as small a space as possible.

 

I have running in 48k a version of his code with 102 rooms that runs faster. What has your byte by pedantic byte achieved?

Edited April 11, 2017 by Norman Sword

[IRF]

What is the point in this statement. You could have done this and didn't, anyone could have done it and didn't. Your statement is pointless.

The whole point of this thread, when Daniel Gromann set it up, was to identify places in the original JSW code where efficiencies could be made. (In the context of several ongoing projects being worked on at the time, which could - and indeed have - benefited from such efficiencies.)

 

At #944C, Matthew defined B=08, and then at #944E he CALLed a late entry point into the 'Print a single character' routine, namely #969B. If instead he had CALLed #9699, then the two-byte command which defines B in the item-drawing routine would have been unnecessary.

 

Furthermore, Geoff Eddy's alternative room-drawing code effectively replicates the latter part of the item-drawing code, when it could have just CALLed #9699 (as indeed your alternative room-drawing routine does).

 

I listed them here as potentially-useful optimisations for prospective game designers.

[Norman Sword]

without quoting others who have posted posting on this topic

 

JSW2:-     General ignorance posted by this group concerning this game.

 

JSW2 does not compress any of its code., and does not run with compressed code.

 

On the other hand JSW runs with compressed data. the same as JSW2

 

Your scope of ignorance on this subject is why as a group you miss the bigger picture. You are spending so much time on trivia, so much time on conjecture. No one knows what Matthew might or meant to achieve. Because he defined graphics does not indicate he was definitely going to use them. Conjecture on your part. 

[Norman Sword]

You are quoting thing just for the sake of quoting. It does not illustrate anything. 

[IRF]

My code permits me to re write Matthews game in as small a space as possible.

 

I have running in 48k a version of his code with 102 rooms that runs faster. What has your byte by pedantic byte achieved?

I could point to numerous examples in various recent projects, where implementing a small code efficiency (sometimes a single byte) has facilitated the introduction of specific modifications, which otherwise couldn't be implemented without significant rejigging of the code.

 

Furthermore, as a novice programmer, I have often taken on the challenge of getting chunks of code to 'fit' into the available space, as puzzles to be solved in their own right. And the process has been very much of a learning curve for me, enhancing my knowledge of the workings of the JSW game engine and of the Z80 instruction set.