Pokes for Fixing the Cell Graphics Bug in JSW

[IRF]

I thought it would be good to have a standalone topic for easy reference, containing the Pokes in Hex (EDIT: and in Decimal) that fix the Cell Graphics Bug.  The credit for most of these goes to Stuart Brady (AKA Zub), although I had a bit of input into fixing the ramp/conveyor pixel patterns and conveyor attribute byte in The Nightmare Room.

 

I'm not sure if this should be in the 'Remakes' section of the forum or elsewhere; I can relocated it if necessary.  However, I thought this might be the best place as it is highly advisable for anyone developing a game/remake using the JSW game engine to apply these Pokes, to prevent their intended cell graphics from being corrupted in an erratic manner!

 

The Cell Graphics Bug fix (a generic patch to the game engine) is achieved using the following sixteen Pokes:

 

POKE 8d54, 06

POKE 8d55, 06

POKE 8d56, cd

POKE 8d57, bb

POKE 8d58, 93

POKE 8d59, 59

 

POKE 93bb, 11

POKE 93bc, 08

POKE 93bd, 00

POKE 93be, be

POKE 93bf, 23

POKE 93c0, c8

POKE 93c1, 19

POKE 93c2, 10

POKE 93c3, fa

POKE 93c4, c9

 

EDIT: The above, in decimal:

 

POKE 36180, 6

POKE 36181, 6

POKE 36182, 205

POKE 36183, 187

POKE 36184, 147

POKE 36185, 89

 

POKE 37819, 17

POKE 37820, 8

POKE 37821, 0

POKE 37822, 190

POKE 37823, 35

POKE 37824, 200

POKE 37825, 25

POKE 37826, 16

POKE 37827, 250

POKE 37828, 201

 

An additional fix, specific to The Nightmare Room (where we believe Matthew Smith's intended attribute byte for the conveyor was misplaced in the code, as the bottom pixel row of the ramp cells; this had a knock-on effect on the colour scheme and pixel pattern of the conveyor, even with the Cell Graphics Bug fix in place), can be achieved using the following five Pokes:

 

POKE ddcc, ff

POKE ddcd, 02

POKE ddce, a5

POKE ddcf, ff

POKE ddd0, 5a

 

EDIT: The above, in decimal:

 

POKE 56780, 255

POKE 56781, 2

POKE 56782, 165

POKE 56783, 255

POKE 56784, 90

Edited March 11, 2016 by IRF

[IRF]

I've just noticed from Skoolkid's disassembly that part of the Cell Graphics Bug Fix (and in The Nightmare Edition, some other code) overwrites the following routine that was left unused in the original JSW:

 

http://skoolkid.github.io/jetsetwilly/asm/93BB.html

 

It is strange that Matthew Smith went to the effort to write, but never used this routine, as judging by the description of it (pasted below), it would appear to resolve another bug in the game - namely that if a Guardian with Bright set to ON is inserted onto a screen with a non-black background, then the 'shadow' of the Guardian is visible as it moves around the screen, taking on the Bright ON colour of the screen background.

 

"This routine is not used, but if it were, it would set the INK colour for a 3x2 block of cells, maintaining the PAPER, BRIGHT and FLASH attributes of the current room background. It is identical to the code at 36447 in Manic Miner that is used to set the attributes for a vertical guardian."

 

N.B. We resolved this bug in The Nightmare Edition in a different (perhaps less satisfactory) way, simply by ensuring that the Brightness was set to OFF for all Guardians present on screens with non-black backgrounds.

Edited March 15, 2016 by IRF

[Spider]

I would only (guess) its present as a 'left over' from Manic Miner the same way 'AIR' is present in JSW as well as the unused screen colour cycling effect in the middle of the main loop.

 

Having said that, we could call this routine at some point to see the effects ;) :)

[IRF]

Are there Bright Guardians on non-Black screens present in Manic Miner, without the 'bright shadow effect' occurring?

 

Do you think Matt Smith never got round to calling up that routine in the rush to get JSW finished, even though it was present in the code?  It would be nice to be able to have Bright Guardians throughout the layout.  (For example, to fix the bug in TNE, all instances of the Red Flying Pig had to be turned non-Bright, even where it appears on Black screens such as The Hall, because there is one instance of that guardian class on a non-Black screen, i.e. in Emergency Generator.)

Edited March 1, 2016 by IRF

[Spider]

It would not show if the air was 'BRIGHT' too. :)

 

There are no 'bright' guardians on a non-black background that I can see. Some of the black background might be 'bright' but I'd have to double check that.

 

I know what you mean the same as 'Up on the battlements' or 'I'm sure I've seen this before' the guardian there is bright on blue so you see it.

 

I would speculate it was an oversight in JSW really as MM does not exhibit this. :)

[IRF]

It would not show if the air was 'BRIGHT' too. :)

 

But then there's a knock-on effect where you have to set the likes of ramps (where the paper colour tends to be the same as for the air) to Bright as well, and it starts to get complicated (with the 'Matching Colour-Attribute' feature potentially kicking in expectedly, etc).

[Spider]

:D Probably best to avoid too much bright if its no on a black paper background then. :unsure:

 

EDIT... Although as known it *can* cause some odd and interesting side effects sometimes :D

Edited March 1, 2016 by Spider

[IRF]

:D Probably best to avoid too much bright if its no on a black paper background then. :unsure:

 

EDIT... Although as known it *can* cause some odd and interesting side effects sometimes :D

 

It's setting the Air's Ink colour to something other than Black that really causes odd effects though...

[IRF]

N.B. I've updated the first post in this topic with the Pokes in decimal.

[IRF]

I've just noticed from Skoolkid's disassembly that part of the Cell Graphics Bug Fix (and in The Nightmare Edition, some other code) overwrites the following routine that was left unused in the original JSW:

 

http://skoolkid.github.io/jetsetwilly/asm/93BB.html

 

It is strange that Matthew Smith went to the effort to write, but never used this routine, as judging by the description of it (pasted below), it would appear to resolve another bug in the game - namely that if a Guardian with Bright set to ON is inserted onto a screen with a non-black background, then the 'shadow' of the Guardian is visible as it moves around the screen, taking on the Bright ON colour of the screen background.

 

"This routine is not used, but if it were, it would set the INK colour for a 3x2 block of cells, maintaining the PAPER, BRIGHT and FLASH attributes of the current room background. It is identical to the code at 36447 in Manic Miner that is used to set the attributes for a vertical guardian."

 

N.B. We resolved this bug in The Nightmare Edition in a different (perhaps less satisfactory) way, simply by ensuring that the Brightness was set to OFF for all Guardians present on screens with non-black backgrounds.

 

To answer my own question above, having thought about it, the unused routine would just put a different constraint on the game.  If the Brightness of Guardians was set in the game engine by the Brightness setting of the Air cells in each room (which I think is the way that the alternative routine works), rather than Brightness being set individually for each Guardian Class, then it would mean that all guardians on a given screen would have to be either Bright or non-Bright.  That would mean you couldn't have, as you can with the current game engine, a mixture of Bright and non-Bright guardians on a single screen (which causes the shadow effect on non-Black screens, but is fine on screens with Black backgrounds).

 

And that would probably on balance impose greater limitations than the existing set-up, in terms of the variety of colour schemes for guardians in the game (given that most rooms - certainly in original JSW - tend to have a Black background, where the 'shadow effect' doesn't show up).

Edited March 15, 2016 by IRF