IRF

Maybe keep it in the back pocket for a while? Let's see what the other guys think (Andy, Danny?)

I'll second that!

Did you complete the game in time?

There's a legitimate, but very convoluted reason for that! I'm glad you've provided a rationale though - he hasn't found his sea legs yet! :D Meanwhile, I suppose you're all at sea looking for that last item...

Is that when he's walking down the ramp into (or rather, onto) the sea?

That being the Hades one, I'm guessing?

Sorry, that's what I meant - the clock changes colour at 11:30.

So the clock's started flashing? :excl:

Which two? Watch the time limit...

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!