IRF

Richard, Here are another couple of suggestions for the 'Trivia' section of the disassembly: (1) It is possible for Willy to fall a greater distance than the height that usually kills him (4 cell-rows), IF the fall passes through the bottom of one screen and into the next AND IF he hasn't already fallen by more than the safe distance (as indicated by the change in pitch of the 'Willy is falling' sound effect) by the time he has reached the bottom of the first screen. To illustrate the point, position Willy on the ramp in The Orangery, near the top (but not so close that he can jump to the next room above), and jump leftwards. Willy will land fatally on the ramp, having exceeded the safe fall distance. Now walk Willy up to stand on the ramp of Conservatory Roof (effectively the same ramp), and jump left again. The same manoeuvre is survivable because the transition to the screen below 'interrupts' his descent, thus resetting the 'fall counter' (and associated sound effect). (2) If Willy falls off the bottom of a screen, where there is a Fire cell at the top of the screen directly above the point where he is falling, then he dies upon contact with the bottom of the screen (and is reset to his starting position within that screen). (Why this happens exactly is unclear, but possibly the routine that kills Willy if there is a Fire cell in either of the cells directly underneath him, could be 'wrapping round' to check the cells at the top of the screen, whenever he is occupying the bottom two cell-rows? It doesn't occur if there is a guardian at the top of the screen directly above him.) A good example of this effect in action is the right-hand side of Under the Roof, where the front of the 'Nomen Luni aeroplane' occupies the top of the screen and is comprised of Fire cells. In this case the effect is most fortuitous for Willy, as he would otherwise enter an Infinite Death Scenario falling repeatedly down (beyond the safe fall distance) into A Bit of Tree!

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

I suppose it depends on whether you consider the disassembly to be an accurate description of the original JSW code, or a useful tool for future developers of JSW games. It's kind of both, but the former is its primary purpose (it doesn't catalogue the various quirky features of the game code that don't actually manifest themselves in the original game). That said, it's a modest and useful amendment that I proposed. It's Richard's call ultimately. :)

As a suggestion for a tweak to the disassembly, perhaps this page http://skoolkid.github.io/jetsetwilly/asm/8100.html should say at the end: 8140 Terminator 8141 - 8143 Unused (but potentially overwritten if a rope were to occupy the eighth position in the guardian list for a room) Then change the 'Next' link (and the following page, and the reference in the Memory Map) from 8141 to 8144. This would prevent future game developers from using those three bytes that might get corrupted in such a scenario? Or at least, they would have been warned to use those bytes with care! (In the case of TNE it's easily avoided, since it just so happens that there are three unused bytes at the end of the chunk of previously unused code that was recycled for new tune data. i.e. at 81FD - 81FF).

But if a game had used the space from #8141 for a new routine or other useful data, then it might corrupt that? In JSW The Nightmare Edition, that space was used for additional in-game tunes, the first of which is 'In the Hall of the Mountain King'. In fact, that particular tune did get corrupted at some point in the game's development, so I wonder if that or something similar* was the reason? (Danny?) * I say "something similar" as we didn't ever have a room with eight ropes in it a rope occupying the eighth position in the guardian list. (Edit: typo struck out - imagine a room with eight ropes!!)

If inserting two patch vectors per room isn't implemented, as discussed above, then other possible uses for the extra two spare bytes at addresses nnDF and nnE0 in each room could include: All the single byte variables (and a couple of two-byte variables) from #85CB to #85E4 could be shifted into some of these unused addresses within the room data (and the routines which initialise, check and update them amended accordingly), thus freeing up a solid 26-byte chunk. Or you could insert a 'secret' text message across the 128 bytes (64x2) at addresses DF and E0 in each room, which - if the player discovers it buried within the code and puts the whole message together - gives a hint as to how to solve a particularly tricky aspect of the game?! Does anyone have other suggestions, in the pursuit of using up every last byte? :ph34r:

Incidentally, is there an issue with putting a rope as the eighth entity in the list of guardians for a room? As a rope's data extends beyond its own eight bytes, could it corrupt the room layout data for the next screen in the list (most likely the top-left corner)?

I just double-checked and 14 isn't quite enough, but 15 (or 0f in hex - for the record the relevant hex addresses are #9396 and #939a) seems to do the trick. Edit: 14 would probably sufficient to fix the 'bug' if the maximum range of the ropes were reduced a tad, but you'd have to play test all the rope screens to make sure they were still completable (they should be okay in original JSW, but not I suspect in The Nightmare Edition).

I think Matt Smith probably came up with the current setting of 12 based on a suitable distance when the rope is hanging vertically down, and indeed Willy can't jump as high as the top of the screen when the rope is in its central position. However, when the rope is at an angle to the top of the screen that is less than a right-angle, then trigonometry dictates that Willy - in the same position along the rope - is less than 12 pixels from the top of the screen. So the top of the screen becomes reachable via a well-timed jump (i.e. as soon as he stops swinging 'outwards' and before he starts to swing 'back in').

I still managed to jump off the top with it set to 14. I think 15 should do it, although it'd be best if someone independently tested it and came up with the optimal number that stops the jump off the top without setting the height limit too low (which could restrict the gameplay of the rest of the screen).

DF and E0. I haven't checked that this is the case in every single room though.

It might be worth pointing out that the value '80' in 'EE 80' refers to 'Page #80' of the code, which represents the 'Room Definition Buffer' (to which each room's definition bytes - including Offsets #EE and #EF which define the destination address of the current room's Patch Vector - are copied upon entry to a room, via the routine at #8912). i.e. in the example you gave, the values of #C0EE and #C0EF are copied to #80EE and #80EF when Willy enters The Off Licence, so when the Patch Vector points HL at the values stored in #80EE, it is picking up the address specified at #C0EE-EF (this is then refreshed each time Willy enters a new room). Also, I think that each room has a 2-byte chunk AND a 3-byte chunk of unused code in it, so could you have up to two patch vectors per room?

Those are basically rooms where items can be collected by walking into them, without jumping. If Willy has to jump to collect an item (such as in First Landing), or fall onto an item to collect it (such as in Under the Roof), then the game makes a sound in the process, and so the border change doesn't happen. In cases where the border does change colour, it reverts back to its 'correct' colour as soon as Willy jumps or falls, or passes through a Teleporter - or an arrow sets off with the warning noise, or Willy dies, or the music is turned back on - anything that makes a sound basically (except for collecting another item!) Why this happens remains a mystery!

The same screen in The Nightmare Edition - it manages to reinstate Matt Smith's original intention of 'pairing up' the four fire cells and items, whilst making all items collectable without loss of life. The conveyor also has a non-blank pixel pattern too (a slightly modified version of the unused one from The Chapel). :)

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

That would explain why I noticed it happen when I collected the Bathroom tap, but then when I restarted the game and repeated the same action it didn't re-occur. I was playing with my PC on mute, so the in-game music must have been off first time round then when I restarted, the music would have come back on but I didn't notice!

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!