IRF

I look at the arrangement of characters in those lists of rooms and I see sprites! Page 2 is a sailboat! :blink: :lol:

Willy enters the 'toilet dash' as soon as he reaches the foot of the bed, regardless of whether he walks or jumps to reach that point. His getting stuck on the bed is caused by the bed's Conveyor action 'cancelling out' Willy's automatic urge to run rightwards (there's an XOR command involved). The fact that the 'P' key doesn't release him from this predicament is probably a 'bug' (although Danny might disagree!). I guess the pillow is a Fire cell because there were no other cell types available when Matt Smith designed the room!

April Showers and The Belfry are rooms 61 and 62 in TNE (I can't recall which one is which off the top of my head).

Thanks John. It looks like my guess was spot on! I presume the lower 'unused Bits' of Guardian Definition Byte 0 are used for defining higher values of the Guardian Type? (i.e. beyond the standard horizontal/vertical/rope/arrow.)

I'd be interested to know exactly how the adjacent ropes patch does work. Here's my best guess, without studying the relevant code: As I understand it, one of the 'regular' 8 bytes for the rope definition is unused in the original game, which is rather inefficient - perhaps you used that (Byte 6) for the 'Index of the segment of rope being drawn' (which populates Byte 9 in the original game)? Then the only other thing that would need to be shifted, to prevent an 'overspill' into the next guardian's definition data, is a single Bit of Byte 11, which in original JSW is used as an indicator of whether Willy is on the rope (as in this particular rope - otherwise the Airborne Status Indicator, which tells you whether Willy is on a rope, could do the job!) Perhaps you reassigned this function to one of the unused Bits of Byte 0 of the rope definition?

If you walk along the top of The Hall in the Bug Fixed Edition you should hear the 'collect' noise when you get to the right place. :)

I thought the point of moving it to The Hall was to make it reachable and therefore collectable! (Even though it's still invisible!) Here's another example - the (multiple) invisible items in The Nightmare Room, in JSW The Nightmare Edition. They are all collectable! As long as Willy (or something else with White Ink) moves to occupy the cell that they occupy, then they're sucked up! EDIT: I've just had an idea - a slow, Inkless White Guardian could pass through an out-of-reach item towards the end of its traverse of its range, causing a seemingly uncollectable item to be 'auto-collected'. (Said guardian would incidentally be harmless to Willy, and wouldn't even discolour his sprite if he passed through it, so the sudden disappearance of the item would be most mysterious!) Incidentally, pixel collision isn't necessary for item collection - I've witnessed an item that only occupied the lower pixel-rows of its cell, being collected by an arrow that passed through the same cell but which didn't actually touch the item! (In contrast, I've observed an arrow pass through a cell occupied by Willy's sprite without killing him - because he was on a ramp at the time, the arrow sailed over the top of his head and no pixel collision occurred!)

The lack of infilled pixels didn't stop Willy collecting it when it was relocated to The Hall though?

If you teleport into the right-hand side of the adjacent wall, then you can collect the item at your leisure! I think the Conservatory Roof one is impossible, even with a rapid teleport in-and-out, because the check for Fire cells occurs before the check that picks up items in the Main Loop of the code! However, if you POKE an arrow into that room at the right height, it will pick up all four items for you! (Because arrows are White, and any White Ink entity can collect an item!)

I'd suggest that Writetyper was very much an intended Easter Egg though - he can't have written it into the code by accident!! I think Andy might be right though, that if you leave climbing the East Wall until last (that being the only route which requires you to pass through The Attic - if you use the shortcut from Esmeralda to the Ballroom), then you can complete the game without using Writetyper.

Another little suggestion for a tweak: http://skoolkid.github.io/jetsetwilly/asm/7000.html Perhaps you could mention that the Empty Room Screen Buffer is updated every time-frame by the routine at: http://skoolkid.github.io/jetsetwilly/asm/94F9.html (to reflect the animation of the conveyor)? This is the only way in which the Empty Room Screen Buffer is updated in JSW (except when moving between rooms, obviously). It's different in Manic Miner, where as well as conveyor action, crumbling cells and Kong Beast switches are redrawn on the Empty Room Screen Buffer - and the relevant entry in the MM disassembly does already refer to these updates.

I should add that the leafy platforms on the far left-hand side of A Bit of Tree are just for aesthetic purposes, to give the top of the tree a nice shape, but are Forbidden Holy Ground - Willy can't jump onto them without falling a fatal distance. Thus Willy cannot exit leftwards from that screen (or indeed from Banyan Tree, because of the Fire cell 'steps').

Most of those 'quirky features' are mentioned in the Bugs and Trivia sections of SkoolKid's JSW disassembly: http://skoolkit.ca/disassemblies/jet_set_willy/index.html I would add a couple of comments: The 'High Jump' entry covers the 'magnetic head' phenomenon (if you keep jump depressed when on a ramp, the code that determines Willy's exact y-coordinate when he's on a ramp is bypassed - if he happens to have an Earth cell above him then he can appear to 'hover'!) If Willy were to fall down on the right-hand side of Under the Roof then he would enter an Infinite Death Loop, so the 'bug' (which is caused by the fact that there are Fire cells at the very top of the screen, directly above where you are trying to get him to drop off the bottom) is actually quite a useful artefact of the code!

These screenshots are from the Micro (12 room) JSW game that accompanied Andy's 'loader builder' guide. I thought they deserved a bit of an airing, since we did something a bit different with The Banyan Tree pair of screens (progress further up and beyond to Under the Roof was forbidden!) It provides a nice little puzzle (Willy has to go 'up and over' to collect the upper Banyan Tree item), it allows the Bit of Tree Bird guardian to have a wider flight path, and it means that the Blue 'Water' cells are restricted to the tree's root system, which seems more logical than the classic screen arrangement!

I'll take back the elements of my musings that are highlighted in red above - prior to the check for Fire cells in the Main Loop, the Occupied Room Screen Buffer will have been refreshed, and so the data in the range #6000-#601F [the top pixel-row of the playing area] will NOT, at that stage, contain any graphic bytes associated with guardians or items - which aren't drawn until later on during the current pass through the Main Loop. However, for the record I still believe it would be possible for the top pixel-row of Water, Earth, Ramp or Conveyor cells, located in the top cell-row, to potentially match the attribute byte of Fire cells and therefore kill Willy in the manner described above - if the sub-routine at #961E were redirected in the way that I suggested (i.e. to check for Fire cells in the Empty Room Screen Buffer, rather than in the Occupied Room Screen Buffer). Furthermore, the room's conveyor animation (if a conveyor were to be present in the top cell-row of the screen, directly above where Willy is trying to drop off the bottom) could also cause the top pixel-row of the conveyor to re-align and thus cause a byte-match with the Fire cell attribute byte - even if the initial (unrotated) conveyor's first graphic byte didn't cause such a match. The updated conveyor pixel pattern is written to the Empty Room Screen Buffer by the routine at #94F9, so at the next pass through the Main Loop, the 'screen refresh' [copying Empty Room Screen Buffer to Occupied Room Screen Buffer] retains the latest conveyor graphic. (N.B. As far as I can tell, conveyor animation is the only thing in JSW that causes updates to the Empty Room Screen Buffer within a room - apart from 'quirky' spillovers from the Occupied Room Screen Buffer caused by Invalid Arrows and vertically wrapped-around guardians - so-called 'Trails of Havoc'.) *********** ANYWAY, there is a simpler way to prevent the 'Long-Distance Nasties' bug from occurring (although there isn't space for it within the main routine without shuffling code): After Willy's pixel y-coordinate is picked up by the command at #960F, simply compare its value with 224 (#E0) and if it is equal to (or greater than?) that, then jump forward in the code to #961C. And as I previously pointed out, it's questionable whether this is a bug that should be fixed, given that it has its uses for game designers in preventing bigger problems (such as avoiding IDS drops off the bottom of screens).

Typo alert Richard: Willy's rope status (on or off) seems to be determined by Bit 0 of Byte 11 of the rope definition, not Bit 7 of Byte 11 as stated in the 'Entity Buffer' section of your disassembly: http://skoolkit.ca/disassemblies/jet_set_willy/buffers/gbuffer.html http://skoolkit.ca/disassemblies/jet_set_willy/asm/37310.html#37590 By the way, I hope you don't mind these occasional comments and suggestions? Your disassemblies are fantastic resources, and hugely helpful in gaining an understanding of the code. If I come across as pedantic it's only because I believe that 'tweaks' such as this could help readers who follow after me to gain a similar level of understanding!

Regarding vertical guardians, perhaps it is worth an entry in the Trivia section that they can extend beyond their upper permitted bounds (i.e. the highest set value for their y-coordinate, corresponding to the lowest extent of their traverse down the screen). This can occur if the length of their range (the difference between their upper and lower bounds) isn't exactly divisible by the 'speed' of the guardian (i.e. the vertical increment of the guardian in each time frame). It is more common, therefore, with fast vertical guardians. However, it doesn't happen at the lower extent of their bounds (highest position on the screen), because of the code at 37288-37293 (#91A8-91AD), which ensure that if a vertical guardian 'overshoots' at the top of its range on the screen, its y-coordinate is reset to the lowest permitted value. EDIT: Presumably it would be relatively simple to insert a similar couple of commands (with a relative jump to bypass them, as appropriate) which could ensure that vertical guardians don't overshoot their permitted range at the lowest point of their descent down the screen (highest value of y-coordinate). Simple that is, except for the fact that the 'Move the guardians' routine is located at a tight spot in the code, and so consolidating to achieve the necessary space to allow for this would be rather time-consuming. FURTHER EDIT: This 'bug' is actually 'fixed' in Manic Miner, as the code for moving vertical guardians doesn't actually update the guardian's y-coordinate to a value outside of its permitted range, if it detects that it has been moved beyond its range. Conversely, the JSW code for drawing vertical guardians, provides the basis for a fix to the bug in MM whereby the colour of the vertical Skylabs 'bleeds' into the platforms upon which they crash.

Okay Richard, I've looked again and I'll take back my suggestion that your numbers are out of sync. Having paused the game mid-jump and PEEKED at the value of the Jumping Animation Counter, the values do tally with what is seen on the screen, as shown by your illustrations. Specifically, at the very start of the jump when Willy's sprite moves forward one frame of animation before he starts to move vertically upwards, the Jumping Animation Counter is still set to zero. So there is a 'Step 0' in every jump (I was previously considering that to be Step 1). To keep things simple, perhaps you could just include your earlier 'Step 16' illustration, with a note to the effect that this isn't actually seen on the screen during the jump, but it demonstrates Willy's 'internally-stored' location at the precise point when the check for Fire cells is made:- His vertical position has moved down so that he is exactly one cell above his starting position, and only occupying two cell-rows, while his horizontal position hasn't yet been adjusted to take him across the cell-column boundary and his frame of animation hasn't yet been incremented from left-facing 0 to left-facing 3. As for whether x is incremented before or after y, this really is a classic case of 'chicken and egg'. Going from one on-screen 'snapshot' to the next, y is incremented first. But considering the point when the Jump key is pressed as the 'origin', x is incremented before y!

Glad you liked it! I came up with the finer detail, and it was expertly implemented by Daniel Gromann! Throughout the project we tried to stay true to Matt Smith's vision, but of course in the original game when time runs out it just proceeds straight to the Title Screen!

I meant to ask you Mickey, what did you make of the 'Time Up!!' sequence?

Thanks for the responses everybody. It's a lot clearer now. Excuse my previous ignorance in such matters!

Maybe the best way to illustrate what's going on would be to have two sets of diagrams: (1) your previous set, with an explanation that the Step 16 diagram shows where Willy is truly located at the point in time when the check for fire cells is made; (2) a second set, with an explanation that these illustrate what is displayed on the screen at each of the latter time-frames of the jump. This would be what's currently in the disassembly, except that the Step Numbers are out by one. Step 15 should show Willy in left-facing frame 1, 6 pixels above the fire block, then Step 16 is the one labelled as Step 15 in the disassembly, etc. Step 19 just represents Willy's on-screen sprite vertically adjusted to reflect the reality, at the point that the Step 18 check (which brings his jump to an end) was made.

I think we're in agreement that, during a jump, Willy's true coordinates (as stored internally) are not in sync with his apparent position (as shown on the screen), at the point when the check for fire cells underneath him is made. Where we seem to differ is that I believe the updates to Willy's x-coordinate are ahead of updates to his y-coordinate, whereas you consider his y-coordinate is updated first. It's kind of a 'chicken and egg' scenario, but if you consider that the start of the jump is instigated by the command at 36766, and then if you follow the subsequent code in the order that the program arrives at it, it should hopefully be clear that the x-coordinate is adjusted first, then Willy is drawn, and then his y-coordinate is updated.

Hmmm, I wonder are we at cross purposes? I just think that stating "as is the case here" (i.e. there's a nasty below Willy's sprite in step 16) doesn't tally with what one can see in the diagram for Step 16. The illustration labelled 'Step 16' appears to show that Willy has cleared the Fire cell and is straddling two Earth cells, on top of those Earth cells. Whereas in fact, by that point he has sunk four pixels down into the Earth cells (and subsequently drops to the floor beneath). But his sprite's vertical position hasn't been updated to reflect that. At the precise point when a Fire cell is detected underneath Willy, what you see on the screen is shown by your diagram labelled 'Step 15'. Since the Jumping Animation Counter has reached a value of 16 at the point when the Fire cell is detected, labelling that diagram as 'Step 15' seems to me to add to the confusion! N.B. It IS actually possible for him to land in the position shown in the 'Step 16' diagram, if the starting point of his jump is one frame of animation further forward - in that case, in the penultimate time-frame before he lands, he is drawn in exactly the same animation frame (left-facing frame 3) but three pixels above the two Earth cells - again, the update of his y-coordinate lags BEHIND the update of his x-coordinate. So the effective check* for Earth cells underneath Willy interrupts his descent, and his sprite drops straight down onto the bricks without progressing laterally. His jump has effectively ended when he is still displayed a few pixels up; his 'drawn' y-coordinate just has to catch up with his 'internally-set' y-coordinate. (* The code actually checks for Air cells under the left and right halves of his sprite, in turn, and interrupts his fall if either check receives a negative response - but both those checks are bypassed if there is a Fire cell beneath either half of him.)

It's all a bit beyond me I'm afraid! I play files using an online emulator called QAOP. I just click 'Open' and then browse for a file (sometimes they're .tap files, sometimes .z80). The emulator seems to go straight to the Title Screen with no bother. Therefore, as far as I am aware, no 'loader' is involved in the process? I was just wondering how the emulator knows where to begin? The specific concern behind my question is this: if I were to put 'meaningful code' (i.e. Z80 commands) prior to #8400, would the emulator chance across that first and try to implement it in the first instance? (The specific location I have in mind is the 2x42 byte chunks of spare code in the Rope Animation Table from #8300.) The same concern could in theory also arise with 'data' bytes, but we did that successfully in The Nightmare Edition (three of the in-game tunes are located in the #8141-81ff region), and it doesn't seem to be mis-interpreted as Z80 instructions, so that's fine.