Free space and code optimisation in "JSW"

[IRF]

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

In between the commands that are currently at #8C3B and #8C3C, do:

 

RLCA

ADD A, #A0 #9E

LD L, A

LD H, #50

LD DE, #9800 [points DE at 32 contiguous NOPPED out bytes]

LD C, #00

CALL #9456

 

Then there is no need to wipe the bottom third of the screen at room refresh (i.e. you may delete #8958-#8964 entirely).

 

Nor is there a need to print the Items/Time character row at each room refresh, as long as that is done once at the start of the game (i.e. the code currently at #8971-#897C can be cut and pasted somewhere after #88FC but before #8912).

 

N.B. If the standard 'Infinite Lives' POKE is applied (#8C3B, #00 or POKE 35899,0 in decimal), then I suspect that when Willy is killed, the right-hand life on the status bar might disappear briefly and then reappear - as if that life is magically regenerated! Which might be quite a nice effect!

Edited November 12, 2017 by IRF

[IRF]

The above intervention in the 'Lose a life' routine is actually one byte longer than the code which it makes redundant at #8958-64.

 

However, replacing the LD C, #00 with a LD C,E command (E is defined as zero by the previous LD DE) will make the change 'globally byte-neutral'.

[Norman Sword]

Have you tried this out?

 

As far as I can tell you are one willy out, and need to change the offset added ($a0) to ($9e)

[IRF]

No I haven't tried it out yet, and yes I think you might be right about me being one Willy out. The problem would become evident immediately upon testing of course.

 

I was going to do a DEC A before the RLCA, but forgot, and in any case using ADD #9E would be more byte-efficient.

[IRF]

Norman, I recall you querying the need to print the 'remaining lives' Willies during every pass through the Main Loop, if they aren't dancing (because the in-game music isn't playing). I would infer from this that perhaps you have a check of the Music Flag in the Main Loop, and that you only CALL the routine at #898B if that flag is raised (or should that be lowered?)

But if that's the case, then you presumably also need to have a CALL to #898B from the 'Room setup' routine? (Because all the status bar pixels are wiped as part of the Room setup routine.)

Well, if the approach which I outlined in my post from earlier this afternoon works okay (admittedly I haven't tried it out yet!), then such a CALL to print the current number of lives at each room refresh would no longer be necessary?

EDIT: Although you would have to CALL it at the very start of the game, from #88FC. (Unless the in-game music is always initialised to be on at the start of each game.) 

[Norman Sword]

Using an assembler and ditching the constraints of Matthew's FIXED layout. I had changed every reference and had a running version before I passed any comments. Yes I deleted the 3 calls to dance/score/time. I deleted the screen clear and moved the attribute set up to before the room set up. It took less than a minute to do.

 

It played havoc with two other routines that I have which is the room cheat mode. (in my version the rooms are displayed animated, with no willy)

I also have a proper DEMO mode the plays through all the screens.

 

It must have take a good two minutes to implement the changes. 

 

 

I would say there is a very high likelyhood that implementing the changes as you outlined, in the manner you have explained. would indeed result in an outcome that fulfils its need.

 

My only comment is the usage of the Title screen data as a source for the sprite clearing data.

[IRF]

 

My only comment is the usage of the Title screen data as a source for the sprite clearing data.

 

It could be anywhere that there are 32 contiguous zero bytes in the code.

[Norman Sword]

I ditched the title screen very early in this current disassembly. Which is why I mentioned the title screen data. I do not have such an area of data,

 

If I was aware of any 32 byte area of data that was below $c000 then I can bet I would delete it and implement code to replace it.

 

I manually delete the last willy with a simple djnz loop. 

 

I also tried just filling the attributes, no easier so went back to manually deleting willy.

 

The code I am messing with has at the moment no aim or purpose. I am editing this data just out of curiosity.

Edited November 11, 2017 by Norman Sword

[IRF]

I manually delete the last willy with a simple djnz loop.

 

Not quite so simple though surely? Because of the non-linear way that the graphic bytes are distributed on the screen. In order to erase pairs of bytes from 16 consecutive raster lines, wouldn't you end up having to partially replicate the routine at #9456 anyway?

 

In looking elsewhere for 32 contiguous zeroes, I was wondering whether perhaps you could point DE at #5B00, the top of the stack, since all of page #5B holds zeros by default, and the stack pointer should never reach anywhere near that far! Would there be an unforeseen danger in that?

 

(N.B. There's a whole chunk of hundreds of unused addresses in the ROM, which would be ideal for the purpose, but unfortunately they're filled with #FF rather than #00.)

 

Another option I'm considering is, instead of just erasing the expired lives, print over them with a bespoke 16x16 graphic indicating their demise. The code which animates the remaining lives wouldn't touch such graphics, I believe.

Edited November 11, 2017 by IRF

[Norman Sword]

replicate the sprite routine?

 

The further I change routines and add my own routines the more likely I will have need for a routine that does the simple task of moving HL to the next raster line. (it is a big chunk of the sprite routine)

so I write a routine called NEXT_RASTER that does exactly what it says on the label

 

I use it to draw the logo, I use it to draw the sprites, in fact if I know a routine will draw more the eight raster lines, then I will call next_raster

 

Calling a routine instead of having the code in-line is inherently slower. But look at the usage of IX in the willy sprite routine and compare the time with a call to just move to the next raster and return. (it is comparable)

 

Plus all the in-line routines are removed to a simple call.

 

It was also a deliberate ploy when developing new routines and generally just pushing my luck (experimenting) that I need to be certain that sprite/arrows anything that moved on the screen was constrained to the bounds of the screen.

 

So I force NEXT_RASTER to comply with only returning VALID screen addresses. So if a sprite wanders off the bottom of the screen it will wrap around and emerge on the top , thereby not crashing the machine......Which is what the Y-table is meant to be used for. But in this game it is rarely used for that purpose. 

 

It is also easy to add lots of checks for screen bounds, in the experimental stages, which can be removed once the routine has been debugged.

Since all the routines use the constraints it makes finding faults so much easier. (The game still runs with junk on the screen)

 

 

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

 

In Jsw I think there are 3 separate sprite routines. 

 

1) merge and test collision     $9456 c=mode

2) write                                   $9456 c=mode 

3) merge with no collision check  $9668

 

 since you now use a flag to detect collision, and the routine does not abort.  You can delete the third sprite routine. which is the one that draws willy onto the screen around $9670:  (also draws the toilet)

 

e.g. at $9670 change to

 

ld c,Flag     

jp sprite_draw ;$9456

 

you can delete all code up to $9680

 

:this is space verses speed.

 

I have split the two functions defined by The "C" register, so I actually use TWO independent routines, which individually are faster than the combined....  

 

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

 

I do all the sprite drawing in a different way. e.g. The LD c,flag has been ditched. 

 

 

Re-stack. 

Using the bottom of the stack would be a handy form of debug. It would alert you to stack overflow and also screen overwrites.

Edited November 11, 2017 by Norman Sword