IRF

And of course, the precise manifestation of the Invalid Arrow's 'side effect' (colour-attribute blocks, a temporary pixel trail, or a permanent pixel trail) depends on the exact pixel-row position of the Invalid Arrow (within each cell-row, and in the top or bottom half of the screen).

One point that I didn't mention - it may be obvious but anyway - in the case of a 'Constant Invalid Arrow', the effects would occur throughout all eight cell-rows of either the upper or lower half of the playing area (being the opposite half to where the arrow is located).

I think the sound is supposed to represent the Arrow being 'fired', perhaps it should occur just as the Arrow enters the side of the screen - of course, that would mean it should be sounded eight times in each 256-tick cycle, rather than once in each cycle! i.e. Trigger the effect every time the Arrow occupies cell-column #00 if it's a left-to-right Arrow, or cell-column #1F if it's a right-to-left type. Actually, there's only one tick difference between those two, which isn't worth splitting hairs about. So you could just do a AND #1F on the Arrow's x-coordinate (stored at IX+$04 in the Guardian Buffer), in place of the command at #924C (you could also remove the commands at #9240 and #9247), then the JR NZ at #924D would ensure that the sound effect occurred each time the Arrow wrapped round the edge of the screen (just after it appears flying rightwards; just before it appears travelling leftwards). Those code changes would all have to be put back to normal in rooms with normal Arrows, though! One other point, I referred earlier to the Arrow moving one cell-row down the screen each time it reappears. However, that only applies to a left-to-right Arrow; for a right-to-left it would move up by one cell-row each time it wrapped around.

One other point - it wouldn't really make sense to have the 'Arrow Warning' sound at a random point when the Arrow is constantly firing?!

Indeed, I had your earlier comment in mind when I named the test file! If a 'Constant Arrow' starts off as Valid (because it's been inserted in a pixel-row other than the top or bottom one within a cell-row), then it will remain Valid throughout the 256-tick game cycle (and vice versa - which could be fun!) Yes, it's a game engine change that would affect all Arrows in the game. But you could make the intervention in the code via a Patch Vector, with the correct code restored by default in rooms where you don't want the effect.

I wasn't quite right with the above - the Arrow descends through each cell-row in turn down either the top half or the bottom half of the screen (depending on whether its allocated y-coordinate in the room's guardian specification data is in the top or bottom half), but stays within the same pixel-row within each cell-row. Therefore the Arrow in such circumstances will either be Invalid, or not, each time it appears. See the attached 'Constant Arrow' test file, with the aforementioned bytes NOPped out. Constant Arrow Test.z80

It's sometimes said that the unused Room 47 in original JSW was meant to be located above 'Conservatory Roof'. This seems to be based on the fact that the value at #EFEC, in the code remnants that occupies the place where the room data usually sits, is set to #2D (Conservatory Roof's room number in hex). Offset #EC in a room's data usually defines the Down Exit, but in this case the '2D' actually forms part of the operand of an unused CALL command. So it's a rather spurious claim. Indeed, the Up Exit from Conservatory Roof is set to The Off Licence. However, the Right Exit from Tree Root is set to Room 47 (#2F) in the code, so the likeliest place where Room 47 would have been located, if it had ever been present in the original game, is to the right of Tree Root. (Several modified games have in fact placed it there, I believe.) Perhaps this merits a small mention in the Unused Room Trivia entry? http://skoolkid.github.io/jetsetwilly/reference/facts.html#unusedRoom

I'm just wondering what would happen if you were to NOP out the bytes at #925F-#9266 in the code that draws Arrows. I believe (without having tried it yet) that, instead of only being drawn on the screen for 32 'ticks' out of every 256, an Arrow would continually 'wrap round' and pass through the screen again, in the same direction and remaining within its designated cell-row, but moving down one pixel-row each time it went beyond the edge of the screen (looping back to the top of its cell-row once each time it reached the bottom of the cell-row)!? Of course, it would cause some interesting Invalid Arrow side-effects when the Arrow passed along the top and bottom pixel-rows!

Okay, so the disassembly at that link is of Geoff Mode 1? But if nothing else, my message above provides clarification about exactly how the CALLs in the first link relate to the routines in the second link. (Given that there isn't a link available for a Geoff Mode 2 disassembly, or is there?) EDIT: The specific bit of code that is called up by the Patch Vectors in Rooms 10 and 53 of Willy Takes a Trip, starts at #8D96 in the Geoff Mode disassembly.

Anyway, I think in Base 16 now, so Millenial Milestones mean nothing to me. :P

Here are a couple more useful links: J.G. Harston's page: http://mdfs.net/Software/JSW/ Geoff Eddy's Patch Vectors: https://web.archive.org/web/20030701143440/http://www.cix.co.uk/~morven/jsw/patches.html UPDATE: Later version, featuring additional PVs for ZX Willy the Bug Slayer: https://web.archive.org/web/20080511161939/http://www.cix.co.uk/~morven/jsw/patches.html http://www.worldofspectrum.org/pub/sinclair/games-info/z/ZXWillyTheBugSlayer.txt [some additional disassembly for ZX Willy the Bug Slayer is in the above txt file] However, in the PV disassemblies, I have noticed a couple of errors. Firstly, the PVs that change Willy's colour in 'Willy Takes a Trip' (Rooms 69 59, 61 and 62) all contain (directly or indirectly) several Calls or Jumps to #9673. However, the pertinent sub-routine in the Geoff Mode disassembly (link below) seems to start at #9679 (ending at #967F). Secondly, the PVs in Rooms 10 and 53 of 'Willy Takes a Trip' both call up #97C8 to print a room element, but the 'Print the room' routine in the Geoff Mode disassembly is at #8D33-#8DB0 (the pertinent part starts at #8D96). Geoff Mode disassembly: https://web.archive.org/web/20030701143111/http://www.cix.co.uk/~morven/jsw/geoff_dis.html Geoff's JSW pages: https://web.archive.org/web/20030805002513/http://www.cix.co.uk:80/~morven/jsw/index.html https://web.archive.org/web/20030818082654/http://www.cix.co.uk:80/~morven/jsw/geoffmode.html Yahoo Group: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/info Broadsoft Lifts disassembly: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/topics/6608 Discussion of Superjump: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/5030 Discussion of Kong Beast: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/4417 https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/6454 Laterally-Inverting arrows: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/1867 Message re: Willy's Hoard: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/5868 Message re: 'It's Oh So Quiet!": https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/2233 Message re: Spectrum file formats: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/topics/4766 Some Top Tips collated by Sendy (including the Droplets Patch, and variable-deadliness Solar Beam): https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/topics/5624

The JSW Disassembly Trivia section mentions an unused Entity Definition (#2B - a vertical guardian, which draws upon the page of sprite data that contains the Skull and the Evil Priest sprites), and the unused guardian sprite (the 'Periscope', whose graphic bytes are on page #B1 - it subsequently appeared in JSW2). However, I have just noticed an unused Entity Specification (sometimes referred to as a Guardian Instance), in the room data for 'The Hall'. It seems to be another instance of the static 'Chandelier', one of which is already present in that room. The second instance of it is there in the room's guardian list data, but because it follows after the 'FF' Terminator byte in the Guardian List, a second Chandelier doesn't actually appear in the game. That's just as well, as its specified x-coordinate of 00 would cause it to block the route up the Ramp in that room, and cause an Infinite Death Scenario if Willy walked in from 'Ballroom East' along the middle platform! (Presumably its second specification byte would have been adjusted to place it further to the right, if it had ever been used. EDIT: In fact, now that I think about it, a value of '00' would also have caused it to select one of the 'Centipede Segments' from The Attic as its base sprite, which would look distinctly odd without a head! Rather than the Chandelier base sprite, which would fit thematically with the room. So it's clear that the second specification byte is simply set to '00' by default.) Anyway, it's nice that the original game's data can still throw up the odd surprise, all these years later! Perhaps this merits a Trivia entry in Richard's disassembly? Incidentally, in recent projects (such as JSW The Nightmare Edition), we have been inserting more than one of the 'Chandeliers' into The Hall. Following this discovery, it would appear that we may have been coming close to Matt Smith's early vision for this room?! P.S. I've checked the data for the other rooms, and there aren't any other such instances of 'unused guardian specifications' in the original game code.

I was going by the hyperlink, which has '#entry4027' at the end. My post above has it thus: http://jswmm.co.uk/topic/198-post-4000/?do=findComment&comment=5000 However, looking at the homepage, it currently says: 4,959 Total Posts (That's at the time of typing; I guess it will say 4,960 Total Posts when I go to check after submitting this.) So it seems that my 'virtual party poppers' were premature. :blush: The disparity between the two figures must arise from posts having been deleted by the Moderators. :huh:

I'm not sure if that was post #4000, Danny? (If you hover over the '#1' hyperlink at the top-right of the first message in this thread, it says: http://jswmm.co.uk/topic/198-post-4000/?do=findComment&comment=4027 However, this post of mine is Post #5000!!! Let's get the party poppers out!!!

The following quote is taken from Geoff Eddy's description of his 'Geoff Mode' remix of the JSW game engine. Am I right in my interpretation that it isn't possible to have Invalid Arrows in Geoff Mode (because of the aspect highlighted in bold)? https://web.archive.org/web/20030818082654/http://www.cix.co.uk/~morven/jsw/geoffmode.html

It might be helpful for game designers incorporating Rooms 61-63 into a JSW48 game, if the disassembly were to provide the WRITETYPER Teleport codes for those Rooms. (As you're aware, in the original game the addresses where those rooms would be are just filled with unused code. Note that the JSW disassembly does provide the WRITETYPER code for Room 47, even though that room is also unused in the original game!) As an educated guess, I would suggest that the pertinent Teleport codes should be as follows: Room 61: 134569 Room 62: 234569 Room 63: 1234569 (Actually, it might be fun to try those out in original JSW and see where Willy ends up!!!)

I thought I'd copy the following two suggestions here (from a PM) for the 'wider readership'. (And rather cunning they are too, if I do say so myself!): And:

If the instruction at #8985 (setting the Rope Status Indicator to 0) was relocated to immediately before #894A, then it would benefit from A having been decremented to zero in the preceding loop, and therefore the single-byte XOR A command at #8984 would become unnecessary and could be recycled.

The Encroaching Rope: I believe that a Rope's data spilling beyond its alloted eight bytes in the Entity Buffer, falls firmly into the 'Bug' rather than 'Trivia' category. Furthermore, placing a Guardian directly after a Rope in a room's Entity List can potentially cause corruption through the game code, in a similar way to the Attic Bug! May I humbly suggest that your JSW disassembly could provide the POKEs that implement the Adjacent Ropes Patch (assuming the prior, kind permission of John Elliott for such, of course!)? Ropes before Arrows: This Trivia entry could perhaps point out that this scenario is sometimes, but not always, fatal to Willy. (Depending on whether the Arrow and Rope have sufficiently diverged in the next time-frame, when Willy's sprite is first drawn on the Rope.) Also, if the Arrow's pixel y-coordinate is such that it passes between the Rope's segments, then a pixel-collision might not take place, in which case 'teleportation' would be avoided!

To clarify, a Rope teleports Willy onto it, if one of the Rope's pixels collides with something that was drawn prior to it in the current game 'tick'. If that's an Earth cell, for instance, then he's fine. If it's a Fire cell, or a Guardian that sits earlier in the room's guardian list, then Willy in turn collides with that fatal element, and is killed. But it's not actually the collision of the Rope with the Guardian or Fire cell that kills him directly, just the fact that the 'teleportation' brings him into close proximity with the nasty! In fact, Willy can sometimes survive such encounters. e.g. if an Arrow is drawn before a Rope and the Rope hits it, sometimes the Arrow has moved on in its flight path in the next time-frame, sufficiently that Willy avoids being hit by it, and he is safely deposited on the Rope by the Rope-Arrow collision! Sometimes that's not the case though, and instead he is struck by the Arrow during the first (and indeed only!) 'tick' that he's on the Rope.

Indeed! I take it they are restored each time you leave and then re-enter a room? If so, the frustrating scenario I envisaged above would be repeated if the player had to pass through such a room more than once! :excl: :lol:

It would if they were Fire cells, or a guardian. But touching a Crumbly cell doesn't kill Willy!

But then the Crumblies in the middle (in the path of the Rope) may as well be Air cells... EDIT: Actually, Willy would be teleported onto the Rope every time it hit a Crumbly's 'on' pixel. So you could have quite a frustrating room with a few Crumblies in the path of the Rope, so that Willy keeps getting teleported onto the Rope before he gets chance to walk to the far side of the room! He would have to continually dismount from the Rope at the right place, clearing the Crumblies in turn (perhaps having to jump back onto the Rope at the last moment, after clearing the final pixel row of each, to avoid a fatal fall onto some Fire cells at the bottom of the screen?) Then only once all the Crumblies has been cleared from the path of the Rope, could Willy jump clear of the Rope and exit off the far side of the screen without being teleported back onto the Rope!

I suppose that's one option. However, I've considered it a nice challenge to find 'efficiencies' in the existing code and therefore try and pack as much into the available space as possible, without compression. And if nothing else, taking on the task has helped me get my head around how the Z80 machine code works. (I was clueless just a few months ago!!) :wacko:

(I wasn't sure whether to put this in the Manic Miner or the JSW thread!) Theoretically, if Willy were to descend onto a Crumbly cell whilst he's swinging on a Rope, presumably the Crumbly wouldn't actually crumble? (In the same way that Earth cells don't block Willy's progress, etc whilst he is on a Rope.) Because the Move Willy routine (from which the 'Animate a crumbling floor tile...' sub-routine is called) is bypassed when Willy is on a Rope (apart from the 'detect the movement keys being pressed' elements). Of course, such a situation wouldn't normally arise in a Manic Miner game (as the MM game engine doesn't feature Ropes), or in a JSW48 game (because Crumbly cells aren't supported). EDIT: Although, having pointed out this 'quirk', I can't actually think of a practical application of it in a game!? Any difficulty that the Crumbly cells crumbling away might present, in terms of proceeding upwards in a room, could simply be bypassed by climbing up the Rope! Having to clear a Crumbly cell away from the path of an oncoming guardian is a 'quirky' challenge, and putting the Rope in the way might make clearing the Crumbly away more difficult (if Willy keeps getting caught up on the Rope) - but then the guardian would be prone to being hit by the Rope, which would itself kill Willy (by teleporting him to the point of collision)! FURTHER THOUGHT: I suppose a nearby Rope might slow down the process of clearing away Crumblies that have Items on top of them (which can only be collected once the Crumblies have been cleared).