Free space and code optimisation in "JSW"

[IRF]

I was thinking that in the routine which animates the conveyor, maybe the code at #9507-#950B should come before the code from #94F9 to #9506?

 

Otherwise, in rooms that have no conveyor, the program needlessly calculates the pixel-buffer addresses for the start of a non-existent conveyor.

 

I'm not sure whether swapping the code round as suggested above would cause a perceptible increase in execution speed (in conveyor-less rooms), but as you say, slowdown is accumulative.

Edited November 9, 2017 by IRF

[Norman Sword]

re conveyor:-

 

MOVE_CONVEYOR:                         ;L94F9

LD A,(CONV_LEN)

OR A
RET Z
LD B,A

 

The test for length is the first test I do in that routine

The next test I do is the bit that declares if the conveyor is animated or not. (not part of Matthew's routines)

 

Speed slow down is accumulative. But sometimes the code can be as sloppy and slow as needed. This normally occurs when a single event has been triggered and the game can practically stop whilst the event happens. E.g. You can increase the length of item collection sound by a considerable degree. Even to the extent of being able to see the slow down on the screen. The player will not mind as this is part of his reward.

 

On the other hand that pesky clock is printed on each game loop along with the items collected text. This type of slowdown is caused by not bothering to update on an update only basis, and because the game has to have additional code to display the text on each new room. Easier to just print on each loop.

 

The speed increase by moving the test from the near the middle of the conveyor routine to the beginning  might be around 20 to 80 t-states. (depends how much code) On the other hand going back to the clock print routine. around 150 t-states per letter .  so if it prints 6 letters that's 900 t-states per game loop to print text that has not changed.

 

I will always attempt to go for the faster or shorter routine. Normally one is the same as the other. But sometimes you need to look at why something is being done, and perhaps not rewrite it. But redesign it.

 

 

Re conveyor- The code I list tends to be the easiest edit I can do that follows the original layout . so if it has all the line numbers and references to line numbers then it is a quick edit. (and probably not tested by me)

Edited November 9, 2017 by Norman Sword

[IRF]

The other day, following your previous comments on the matter, I was thinking about ways that would allow for the clock and item count to be printed only at the point when those elements actually need to be updated.

 

If the text of the pertinent character line wasn't printed (with default '0's for the time and item count - see #8971-897C) each time the room is refreshed, then you wouldn't have to regularly overwrite the '0's.  That character line could be printed once, at the start of the game (after #88FC, but prior to the 'Room setup' entry point at #8912).  You would also need to print the initial values for the time and number of items at that point.

 

But there is also a bit of code which wipes all the pixels from the bottom third of the screen whenever the room is refreshed (see #8958-8964).  I tried removing that completely from the 'Room setup' routine, which only had one drawback - it meant that when Willy loses a life, the remaining lives carry on dancing, but the expired life was still shown (unanimated) on the status bar*.

 

I thought that could be quite a cool effect, to distinguish the static, expired lives from the living, dancing ones - except that of course none of the lives dance if the in-game music isn't playing.

 

So I'm considering a couple of options:

 

- Enforce the animation of the remaining lives even if the music isn't playing (by tying the animation to the 'game clock' variable #85CB, instead of the 'music note index' at #85E1);

 

- Every time Willy loses a life, erase the four character squares corresponding to the life that has just been lost (via an intervention at #8C3B).

 

 

[*N.B. In Manic Miner, there may also be an issue with the air supply bar - if the program doesn't wipe the entire bottom screen-third, then the full length of the air supply character-row may need to be erased at 'cavern refresh', before the appropriate amount of air for the current cavern is drawn in.]

Edited November 9, 2017 by IRF

[IRF]

after #88FC, but prior to the 'Room setup' entry point at #8912.

 

Actually - note to self - the code at #88FC-#8906 really belongs at the start of the 'Display the title screen and play the theme tune' routine (next to the code which initialises the item count to zero).

[IRF]

The code I list tends to be the easiest edit I can do that follows the original layout . so if it has all the line numbers and references to line numbers then it is a quick edit. (and probably not tested by me)

 

Yes, I'm getting the hang of your 'modus operandi' now!

[Norman Sword]

re clock update

 

I moved the print the clock status line into a subroutine. I then changed the clock up date routine to finish by calling the clock print subroutine.

the original code does this the other way round. (the abort to time over needs to include the clock update)

 

I moved the print dancing willies into a subroutine: because of the problem you have also experienced on not clearing the data

 

I moved the room update code into another subroutine. On room update it clears the screen then draws the room and updates various other routines. e.g.

 

The room is updated, but before returning

CALL DISPLAY_LIVES ; updated because lives might be lost and the number of willies displayed will be different
CALL SHOW_CLOCK ; clock must be updated it is only shown on time change
CALL SHOW_ITEMS ; only updated on item collection

Edited November 9, 2017 by Norman Sword

[IRF]

Actually, instead of the clock update code editing the ASCII values at addresses #857F-84, and then the contents of those addresses being printed to the display file (to overwrite the zeroes in the 32-byte message that is printed separately from #8554-8573) - couldn't the clock update code just edit the ASCII values of the addresses #856D-72, which are embedded within the 32-byte message?

 

Ditto with the item count update code - instead of editing the addresses #857C-E (which are then copied over to the display file separately, again to overwrite zeroes), the routine at #93D1 could just work directly on #8564-66.

 

With the game initialisation code setting both the start time and item count directly within the 32-byte message as well.

 

Then when the Room setup routine printed that character line, it would be writing the correct values instead of zeros. It would make things a lot simpler! (Unless there's some reason that I haven't thought of which would preclude this approach?)

Edited November 9, 2017 by IRF

[Norman Sword]

Off hand can see no problem with that approach in JSW. In MM the score can overflow its allocated space. So needs to be separate.

 

It also removes the annoying update flicker when a new room is entered.

 

 

 

[IRF]

That alternative approach should save a few bytes as well.

 

(#857C-84.)

Edited November 9, 2017 by IRF

[Norman Sword]

Re clock update:

 

;                      01234567890123456789012345678901     ; text for position *1
L8554 DEFM "Items collected 000 Time00:00:00"     ; This data is directly changed by item collection and time

 

L857F equ     L8554+24     ; references to the old data, changed to reference directly the data above                                       

L857C equ     L8554+16     ; as above

 

 

;L857C DEFM "000"          ; This data is deleted 

;L857F DEFM " 7:00:00"   ; This data is deleted

 

 

I have just tried the simple equate change and deleted the other clock update.

I have also now added the item equate as well, and deleted the item update  

This works... for data on the status line L8554

 

 

I was experimenting with differing clock formats

so Clock data is different and in a different position

 

NOTE *1 . The position find is not displayed on this forums page, due to this forum using proportional fonts.

                 The assembler uses a fixed size font.

Edited November 9, 2017 by Norman Sword