IRF

I've noticed it on occasion (in The Bathroom as I recall), but it seemed to be intermittent and didn't happen every time, for some reason?

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

There are probably a few other bits that are 'spare' but which aren't listed in the disassembly 'index'.

I wasn't aware of the 'Cell Graphics Bug' until Stuart brought it to my attention. If you ever do a v.2 of the Bug Fix Edition there are a few other things that we discovered along the way which could be fixed as well (such as a couple of guardians that walk backwards because the Sprite Animation settings are askew, punctuation and justification of screen titles, etc).

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

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

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.

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

Actually Richard, as it happens if The Nightmare Room pixel patterns (for ramp and conveyor) are fixed using the five Pokes above without the generic Graphics Bug Fix in place, then the Graphics Bug doesn't actually kick in in that particular room, as the match between the conveyor attribute byte and a row of pixels in the Water cells doesn't occur. Unless you're working with the mirrored version of Jet Set Willy, where all the layouts and pixel patterns are mirror-imaged left-to-right. In which case the corruption occurs in a very different way - see attached!

The room numbers - when manually entering teleport data, it would be useful to have the room numbers in hex. And 'page containing the sprite data' in the list of entities.

Actually, the pixel pattern of the third row of the conveyor cell is set to 11111111 - the 'missing' byte for the bottom pixel row of the ramp cells - so if that is shifted back by four bytes to 'fill in' the last row of the ramp cell, and the four subsequent bytes all cascaded down by one, it achieves the fix without affecting the last five pixel rows of the conveyor cell (except, of course, that their colour scheme has now been altered for the better by the change to the attribute byte). Stuart has suggested that: "[Matt Smith] was working without a level editor so he probably just miscalculated the address of the conveyor belt graphic when he entered its data." So the fix can be achieved by using just five additional Pokes - but bear in mind that these must be applied on top of the cell-graphics bug fix: POKE 56780, 255 POKE 56781, 2 POKE 56782, 165 POKE 56783, 255 POKE 56784, 90 The same in Hex: POKE ddcc, ff POKE ddcd, 02 POKE ddce, a5 POKE ddcf, ff POKE ddd0, 5a P.S. I should have mentioned when I attached a 'Fixed' screenshot that it is taken from an early build of JSW The Nightmare Edition (complete with fire cells and Nightmare font!), so if you plan to put a screenshot up on the disassembly then to avoid confusion, it would probably be best to apply the above Pokes (and the cell-graphics bug fix) and then take a fresh screenshot.

I think the improved look of the screen speaks for itself, with my argument merely providing corroborating evidence! Stuart came up with Pokes which would fix the conveyor, if you hold fire I'll try and dig them out and come up with one that fixes the ramp cell as well.

Hello Richard, The following doesn't relate specifically to the use of base 10 or hex, but I thought I'd point it out here anyway: In the 'Corrupted Conveyors' section of your disassembly, the conveyor in The Nightmare Room has only been partially fixed by the cell-graphics bug patch. If you study The Nightmare Room layout (see the 'Unfixed' attached image), by looking carefully at the ramp graphic you can see that there is an odd 'air gap' at the base of the ramp cells. This is because the bottom row of pixels is supposed to be the colour-attribute byte for the conveyor cell in that room (bearing in mind that conveyors are drawn immediately after ramps in JSW). In all likelihood the bottom row of pixels of the ramp cell was supposed to be entirely filled in (with White Ink); Matthew Smith must have written the colour-attribute byte for the conveyor cells (00000010) one byte too early in the code (N.B. the colour-attribute byte for a particular cell type is located immediately before the 8 bytes corresponding to that cell type's pixel pattern, and also immediately after the 8 bytes for the pixel pattern of the preceding cell type - which in the case of conveyor cells is ramp cells). That then had a knock-on effect on both the colour attributes and the pixel pattern of the conveyor cell, because all the subsequent bytes that determine each row of the conveyor's pixel pattern were shifted one row upwards. With the top row of pixels being misinterpreted as the colour-attribute byte for the conveyor, giving rise to the awful flashing Green/Cyan colouration (which doesn't look good even with the cell-graphics bug fix in place). However, if you look at the attached 'Graphics Fully Fixed' screenshot, you will see that this 'misplaced attribute-byte bug' has been fixed. You can observe that: The bottom pixel row of the ramp (the 'air gap') has been filled in, so that now the ramp cells are all White except for an arrangement of Black pixels that exactly matches the pixel pattern that is seen in the adjacent Earth cells (so that the Ramp cells seamlessly 'blend in' with the Earth cells, as is often the case throughout the JSW layout e.g. Master Bedroom, Back Door, The Drive, The Bridge); What was previously the pixel pattern of the ramp's bottom row (00000010) has instead now been interpreted (correctly) as the colour-attribute byte for the conveyor (it translates as non-flashing Red Ink on Black Paper). The colour scheme of the conveyor now looks much better than either the 'Before' or 'After' conveyor graphics (as displayed in the 'Corrupted Conveyors' section of your disassembly); The byte that was previously (erroneously) taken as the conveyor's colour-attribute byte (10100101 - which translates as Flashing Cyan Ink on Green Paper), has been shifted to become the upper pixel pattern of the conveyor cell; All the following pixel rows in the conveyor cell have as a consequence been cascaded down by one row. The conveyor cell now looks much better; notably, you can see that the first and third rows of the conveyor cell have matching pixel patterns (except that the third row is inverted: 01011010); Note that it is the pixel patterns in the first and third rows of conveyor cells that give rise to visible animation. And in the previous conveyor graphic for The Nightmare Room (even with the cell-graphics bug patch in place), the first and third rows were either both entirely unfilled in or both solidly filled in - the cell is also flashing so it's hard to tell which of those two is the case - but either way the effect was that there was no animation visible in the conveyor graphic. But now that all the pixel rows have been shifted down by one row, with the top row being filled in by 10100101 (previously misinterpreted as the horrible Cyan/Green colour scheme), and the third row its inverted equivalent (01011010), you can see visible animation in both first and third rows. Stuart Brady and I came up with this further fix for both the ramp and conveyor cells in The Nightmare Room, and we are convinced that their pixel patterns and colour schemes are now in accordance with what Matthew Smith intended way back in 1984.

No entry for The Nightmare Edition yet?

We've reached 100 downloads... Not bad for the first week!

Enjoy! Oh, and good luck!!! ;)

I've just realised that I shouldn't have posted that comment in this public area of the forum, but hopefully it acted as a cryptic teaser of The Nightmare Edition's imminent release, rather than giving too much away...

In fact, any White guardians can collect items (try placing one in Back Stairway in the path of the 'spinning coin').

Oh, another thing - the hex version of the disassembly isn't fully in hex - the entity definitions (I think this is an equivalent term to Guardian Classes?) are listed in decimal. It would be handier for comparison with JSWED if they were numbered in hex. e.g. Entity definition 49 as listed in the disassembly (Yellow Chef) is Guardian G31 in JSWED. [49 in decimal = 31 in hex.] Although I appreciate it would require a lot more manual work to alter all the entries in the list of entry definitions and the mentions of them in the page for each room!

Hello SkoolKid, May I also suggest that the 'White-seeking missile' entry in the Trivia section mentions the fact that arrows can collect items, and also makes it more explicit that if an arrow hits a White guardian, then this is fatal to Willy. (The implications of an arrow hitting a White rope are pointed out, but not a White guardian in explicit terms.) Neither of these things occur in the original JSW layout, but they are useful to know about if you are designing your own layouts or modifying the original!

Normal Willy?

As I texted to my missus last night from my works do: "Im In Go Messy Christmas!" (Was supposed to be 'Ho Ho Ho Merry Christmas!" - bloody predictive text!! :D )

I just noticed this and thought I'd point out that there's already a screen called 'Under the MegaTree'. This room is under 'Under the MegaTree'!

I just had a look at that, the crucial jump seems to be at 10:17 (after which you abandoned trying to get the top left item in Out on a Limb). Did you try the trick of jumping up on the spot then holding down left and jump simultaneously before he lands, to execute a left jump without first stepping forward by one pixel?