Jump to content

  •  

* * * - -
Photo

Fixing the item and time reset flicker


One minor but slight annoyance with JSW I have noted is that upon entry to a new screen or after a life loss (in other words when the room is initialised) is that the item and time counters very briefly show their default values, that being 000 items and either 07:00 or 7:00

 

The cause is simply because the routine inside the 'Initialise the room' code does the following:

35185 (#8971h) LD IX,34132 (#8554h) ; Put the string address into IX
35189 (#8975h) LD DE,20576 (#5060h) ; Put the print position (AT 19,0) into DE
35192 (#8978h) LD C,32 (#20h) ; Put 32 into C (the number of characters to print/string length usually)
35194 (#897Ah) CALL 38528 (#9680h) ; Call the routine to print them
The above as explained prints 32 characters of the string read from 34132 (#8554h) and it is displayed "AT 19,0" , the display file address of 20576 (#5060h)

 

The issue here is the string itself at 34132 (#8554h) looks like this by default:

Items collected 000 Time 00:00 m

 

There is no actual need to have the item or time values in here as they are more or less immediately updated to their real values anyway.

 

The best way to demonstrate this 'in action' is to apply infinite lives (35899,0) (#8C3Bh , #00h) and then enter a death loop once at least one object has been collected and the time has moved on from 07:00. Infinite lives are needed simply to provide enough time to observe the effect a few times and the time/item change so you can see the effect.

 

The easiest way for a death loop I find is to simply move down to First Landing, move slightly left down the ramp/stairs and then jump back up. Upon entry to Top Landing he will now immediately hit the cyan guardian, causing an IDS.

 

During this IDS, observe the item count and time. Note they briefly flash back to 000 and 07:00

 

To fix this is very easy. The string at 34132 (#8554h) just needs a small change in that we need to alter "000" to " " and "00:00" to " : ". That is changing the zeros to blank spaces. The chr$ code for "0" is 48 (#30h) and the chr$ code for " " is 32 (#20h) . So the pokes are simply:

 

POKE 34148,32 (old value 48) ... (#8564h , #20h)
POKE 34149,32 (old value 48) ... (#8565h , #20h)
POKE 34150,32 (old value 48) ... (#8566h , #20h)

 

POKE 34157,32 (old value 48) ... (#856Dh , #20h)
POKE 34158,32 (old value 48) ... (#856Eh , #20h)
POKE 34160,32 (old value 48) ... (#8570h , #20h)
POKE 34161,32 (old value 48) ... (#8571h , #20h)

Note the small gap with the last four pokes, this is because we leave the colon time separator alone as it never changes.

With these applied the string now looks like this, compare it to the above one:

Items collected Time : m

 

Now try the 'death loop' again, Remember to collect at least one item and to ensure the time has moved on from 07:00. Although there is a fractional blanking effect, it is preferable to it defaulting to 000 and 00:00 I think. :)

  • IRF likes this



5 Comments

Good thinking, Andy!

 

 


Although there is a fractional blanking effect, it is preferable to it defaulting to 000 and 00:00 I think.

 

I agree. :)   I would add that the whole of the bottom third of the screen is briefly blanked out anyway (see 35160-35172) before the room name/items/time/lives are printed again.  (I'm not sure why that's done; perhaps it's a relic from Manic Miner where you wouldn't want any relic segments of the air bar from the previous cavern being left unerased on the status panel?)

 

 


Items collected Time : m

 

Actually, using your POKES it will briefly say:

 

Items collected    Time   :  am

 

Because you've only blanked out the digits, not the 'a' of 'am'.  I think that's good though, as it would look odder if the 'a' of 'am' flickered off and on, but the 'm' didn't. :thumbsup:

:) I suspect you are correct in that it is a MM relic as such as with JSW there's little need to deal much with the 'status' area as much.

 

Please feel free to edit the article if you wish to alter the time Meridiem*** to include the removal / adjustment of the 'a' or 'p' too.

 

 

***99% sure it is actually meant to be spelt out that way, despite it looking wrong!

    • IRF likes this

I think the fix is alright as it is, I was just pointing out a detail. :-)


I would add that the whole of the bottom third of the screen is briefly blanked out anyway (see 35160-35172) before the room name/items/time/lives are printed again.  (I'm not sure why that's done; perhaps it's a relic from Manic Miner where you wouldn't want any relic segments of the air bar from the previous cavern being left unerased on the status panel?)

 

Further to my comment above, I just tried NOPping out 35160-35172.  The result was that, after Willy lost lives, his 'expired' lives remaining in situ on the status bar - only they were no longer dancing (this was with the in-game music playing).

 

It was strange to see a mixture of 'dancing Willies' (the remaining lives) and, next to them, some 'non-dancing Willies' (the expired lives)!

 

Anyway, this proves the point that it IS necessary for the 'Room Setup' routine to erase the graphical bytes from the status bar, at 35160-72.  (I guess it would only really be necessary to clear the two character-rows where the remaining lives appear, but because of the non-linear layout of the Spectrum video RAM, it is more efficient just to wipe the lot - i.e. the whole bottom third of the screen - and then re-print the 'Items/Time' display line.)

Further to my comment above, I just tried NOPping out 35160-35172.  The result was that, after Willy lost lives, his 'expired' lives remaining in situ on the status bar - only they were no longer dancing (this was with the in-game music playing).

 

It was strange to see a mixture of 'dancing Willies' (the remaining lives) and, next to them, some 'non-dancing Willies' (the expired lives)!

 

Anyway, this proves the point that it IS necessary for the 'Room Setup' routine to erase the graphical bytes from the status bar, at 35160-72.  (I guess it would only really be necessary to clear the two character-rows where the remaining lives appear, but because of the non-linear layout of the Spectrum video RAM, it is more efficient just to wipe the lot - i.e. the whole bottom third of the screen - and then re-print the 'Items/Time' display line.)

 

That is interesting as the 'result' was not something I'd of expected. :D

 

Yes it may be more efficient to just zap those 64 bytes (two rows) however I'd agree. Then again if doing that, you could further say you might as well do another 32 bytes (one row) for the room descriptor too ?

 

Having said that though its already neatly replaced so that row might be pointless to erase at that stage, only exception I can think of here is if something non standard / special (paper colour?) was being done with it.