SkoolKid

Is it something like 12/cos(?), where 12 is the value that prevents Willy jumping off the top when the rope is hanging vertically down [and is the value of the bytes in question in the original game code], and ? is the angle by which the top of the rope deviates from the vertical, at its point of maximum swing?

No, there's no trigonometry involved. :) Here's the explanation I've included in the bug description:

"The number 15 here determines the highest segment of rope that Willy can reach (originally 12). At segment 15, Willy's y-coordinate never goes below 25 while he's on the rope, and is adjusted down to 24 (see 36782) when he jumps off, which is too far from the top the room (the maximum height Willy can jump is 20 pixels). At segment 14, Willy's y-coordinate never goes below 23 while he's on the rope, but is adjusted down to 16 when he jumps off, which is close enough to the top of the room to be able to jump through it."

You can see the full text in the git commit:

https://github.com/skoolkid/jetsetwilly/commit/99733c6c4708b86b9c58f2369934d02a43ee7c1b

Richard,

 

Please see the attached, starting position is The Forgotten Abbey.  I performed the manoeuvre twice - the first time, I kept 'left' depressed (walking against the flow of the conveyor) so Willy was able to escape the situation.  The second time, I let go of 'left' after entering The Wine Cellar, and so Willy got stuck!

 

In Dr Jones..., if you manoeuvre Willy to be standing three cells above the 'tusk' item, and walk left, then he gets stuck inside the elephant's head!  (N.B. This is the case in the original JSW, but in the Bug Fix 2015 Edition it has been prevented by removing some of the Water cells inside the 'head', allowing Willy to drop out of that row of cells.)

Thanks for the RZX. I didn't think of trying to get onto the floor tile in The Forgotten Abbey before entering The Wine Cellar!

I'll have to give the Dr Jones manoeuvre a try some time...

Okay, so I was right that you mocked up the images rather than using snapshots, although in doing so your intention was to recreate what is seen on screen!

Ah, I see what you mean. Yes, the images are 'mocked up' in that sense, but then so is every other image in the disassembly. (And every image in the MM/SD/BTS/CSC disassemblies too.)

Have you played our JSW The Nightmare Edition? There's a static guardian (with filled-in pixels only one cell-column deep) on the far right-hand side of The Off Licence - if you can get that far!!

I started playing it, and I have to admit I soon gave up! Does the WRITETYPER cheat work, by any chance? :)

Not derailing at all!  15 (or #0F in hex) was the value that I concluded was just enough to prevent it.

And my own investigations have confirmed that value of 15 as the minimum. I've already written up the bug description, and it includes an explanation of why 15 is the minimum value.

I take it you're aware that Willy can walk THROUGH a Fire cell on the edge of a room, while entering the room, BUT ONLY if he keeps the relevant 'walk' button depressed?

 

Apparently it's because the check for nasties doesn't occur during the 'zeroth time-frame' in a room.

No, I can't say I was aware of that, although it does make sense given how the game engine works. (My lack of JSW modding experience is clearly showing here. :) )

Re: the former, I presumed you must have 'mocked up' the images in your disassembly to illustrate the point!? They don't resemble what is displayed on the screen during the jump! (Although they do demonstrate the sequence in which the checks/coordinate updates take place.)

No, I'm pretty sure I intended the images to reflect exactly where Willy is drawn - instead I must have mistakenly assumed that he's drawn at the coordinates where the nasty tile check takes place.

I think it would be fairly simple to rearrange the code so that both coordinates are updated before the check takes place - no idea about unintended consequences, though!

By the way, something else that I've though of - if an arrow is placed before a guardian in the list for a room, and if the guardian's flight takes it into the path of the guardian, then it will kill Willy even if the guardian is NOT White. So to be on the safe side, the arrow should be placed AFTER the guardians in the list.

And another one for the trivia entry TODO list. Thanks!

EDIT: Perhaps this explains why Willy can land on certain guardians and jump safely away IF the player keeps the jump key depressed; whereas landing in the exact same spot kills Willy if the player has let go of the jump key!

I've never seen that happen before. Do you have an RZX that demonstrates this bug?

There does seem to be a mismatch between Willy's 'physical presence' (the room cells that take on his attributes), and where his sprite is drawn on the screen.

 

Certainly during jumping - if you take the 'Through the Wall' illustrations in the Bugs section of your Manic Miner disassembly, they certainly do give a better representation of how he interacts with the various room elements.

 

However, if you study Willy's jumping by pausing the game at each time-frame during a jump, his sprite appears on screen at a higher y-coordinate (during the descent from the highest point of the jump), than is shown in your illustrations.

You're right - I hadn't noticed that before. I'll update the images and description in 'Through the wall' accordingly. Thanks!

By the way, the reason for the mismatch you've noticed is that the check for nasty/fire cells below Willy takes place after his y-coordinate has been updated but before his x-coordinate has been updated. In other words, the code is looking for danger at (x-1,y) instead of (x,y) (where (x,y) are Willy's new coordinates).

And another suggestion for your TODO list - you could mention the fact that the 'Don't Mind Your Head' Bug can cause Willy to get stuck inside Earth cells (in at least two places that I can think of, namely Dr Jones... and The Wine Cellar, via The Forgotten Abbey) - forcing the player to abandon the game!

Can you explain how Willy can get stuck inside Earth cells (wall tiles?) in The Wine Cellar, for example? I'm not seeing it.

Question: on the toilet dash, the code at around #8A06 "sets Willy's animation frame at 85D2 to 1 or 3 if Willy is running to the toilet or already has his head down it; this has the effect of moving Willy at twice his normal speed as he makes his way to the toilet".

 

But doesn't he display animation frames 0 and 2 when he's on the toilet dash?  (i.e. The two 'intermediate' frames, so it looks like he's gliding without moving his legs at all.)

Yes, Willy's animation frame is either 0 or 2 during the toilet dash, because it's incremented from 3 or 1 by the 'Move Willy' routine on the next pass through the main loop before he's drawn.

I'll add a note to the comment to make that clearer.

[Pedantry alert!]  I've just noticed an error (I think) in the disassembly.

 

The entry at #8820-8827 is described as "Copy the attribute bytes for the top two-thirds of the title screen from 9800 to the attribute file".

 

In fact, the LD BC command at #8823 copies the attribute bytes for the entire title screen from #9800 AND #9A00, as determined by the operand #0300.

 

(So it sets the attributes for the bottom third of the title screen, as well as for the playing area.)

Well spotted! Another item for my TODO list...

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 don't think it would be a problem. The rope's buffer would extend beyond the entity buffer at 8100 into the first and third bytes of the unused area that follows at 8141. It wouldn't corrupt the layout of any other room.

See also The encroaching rope.

I'd definitely count this as a bug too - and I didn't have a description of it anywhere in my notes, so thanks for bringing it to my attention!

I'll have to examine the code closely to see what the smallest value is that can be POKEd into 37782/6 to prevent Willy from jumping through the top of the screen...

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

And here's how to do it using SkoolKit and Windows PowerShell:

> echo "b 49280" "T 49280,32" "L 49280,256,60" | sna2skool.py -c - jsw.z80 | select-string DEFM | %{$_ -replace '.*DEFM ', ''}

This might not be the best way (PowerShell is not my first language), but I think it works.

Here's how you could do it in one line with SkoolKit (on Linux, and possibly OS X):

$ echo -e 'b 49280\nT 49280,32\nL49280,256,60' | sna2skool.py -c - jsw.z80 | grep -o '".*"'

This produces the following listing:

"         The Off Licence        "
"         The Bridge             "
"       Under the MegaTree       "
...
"           The Yacht            "

All suggestions duly noted...

One thing I didn't mention in my first post is that, just like the decimal versions of the disassemblies, copies of the hexadecimal versions are available for download (for offline viewing). To download the hex version of the JSW disassembly, first go to the gh-pages branch of the jetsetwilly repo on GitHub:

https://github.com/skoolkid/jetsetwilly/tree/gh-pages

and then click the 'Download ZIP' button. The same applies to the hex version of the Manic Miner disassembly:

https://github.com/skoolkid/manicminer/tree/gh-pages

Just pointing this out because it's not obvious unless you're already familiar with GitHub's interface.

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.

 

[snip]

Very interesting. I find your argument compelling! I'll add a note to the 'Corrupted conveyors' item about this - or add a new item - for the next release.

Thanks!

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!

There are other places too in these disassemblies where hexadecimal numbers would be more appropriate than decimal (e.g. the Codes table in JSW), and solving this problem is also on my TODO list for future releases. The tricky part is that the solution must enable me to build either a fully decimal or a fully hexadecimal disassembly from the same source files, with no manual base-conversion work required. I have some ideas about how to do it, but they involve some changes to SkoolKit.

In the meantime, feel free to point out other places where the use of base 10 is jarring or inconvenient, and I'll make a note of them. :)

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!

Actually, the fact that arrows can collect items deserves its own trivia entry - I'll add that to my TODO list for the next release. Thanks!

In the 'White-seeking missile' entry I hope I've made it clear that arrows don't mix well with anything white, whether it's guardians, wall blocks, floor blocks, nasties etc. The white rope is just a good example of something to be avoided when arrows are around.

Hello all

Since I completed and published my MM/JSW disassemblies just over a year ago, one or two people have asked for hexadecimal versions. Now that I have a lazy, scripted solution for publishing such disassemblies on my GitHub pages, I present:

• The complete Manic Miner RAM disassembly (hexadecimal version)
• The complete Jet Set Willy RAM disassembly (hexadecimal version)

I hope the fans of base 16 among you will enjoy these versions!

Of course, the original decimal versions are still available at skoolkit.ca.

Leaving single POKE mode for a moment, here's my first attempt at fixing the bug that misdraws the conveyors in West of Kitchen, The Nightmare Room, The Wine Cellar, and Tool Shed:

Thanks for the shout-out on the Yahoo! group!

Just so it's clear to anyone interested in a hexadecimal version of the JSW (or MM) disassembly, the "maintenance burden" I mentioned has nothing to with building it, and everything to do with publishing it and keeping it up to date. Building it is simple, and in fact instructions on how to do so are included in the readme.txt file in the downloadable version at http://skoolkit.ca/?page_id=113. To build the hexadecimal version instead of the default decimal version, you just need to use the '-H' option of skool2html.py:

skool2html.py -H jet_set_willy.ref

jetsetdanny: no offence taken - I really do wish I had called it "Yet another disassembly of JSW", as a nod to all the partial disassemblies already available on the internet!

I have considered publishing hexadecimal versions of all the disassemblies on skoolkit.ca, but then laziness kicked in as I realised what an extra maintenance burden that would be. However, anyone else is free to build and publish my disassemblies on their own site, so I encourage that option instead. (Let me know if you need any details on how you or a friend could build a hexadecimal version.)

As for the sticky bed bug - you know, I could have sworn I tried all the "right" keys to get off the bed when I was verifying the bug, but obviously not! Thanks for the info. I will add a correction to the next release of the disassembly.