IRF

I just had an idea this evening, and so I knocked up a test file to try it out. Load up the attached, kill Willy (he only gets one life) and see what happens... Game Over Test.z80

If the following two commands (five bytes) are added at the start of the subroutine at #9584: LD HL, #85D2 SET 0, (HL) then the eleven bytes at #8A00-#8A0A can be removed from the Main Loop entirely. **** To achieve the above: - The four bytes at #9580-83 can be replaced by a relative jump to the code that is currently at #9596 (but that will need to be adjusted to take account of the next step); that saves two bytes; - The three-byte command at #959A is redundant, and can be removed (remember to adjust the length of the relative jump which takes you to that entry point, from #9539).

Interestingly, when Willy is standing (stationary) at certain positions on the ramp in The Bathroom, as the BLOB passes (harmlessly) through his legs, he is drawn at a higher position than usual.. But only for a single time-frame, before he drops back down to the regular height. This is presumably because when the BLOB is coincident with the ramp cell upon which Willy is standing, it changes the attribute-based behaviour when Willy is drawn, and so in that moment his y-coordinate is not adjusted for the fact that he is standing on a ramp. The BLOB is probably acting as a Water cell by default. You could maybe get some other interesting effects by making the BLOB's attribute coincide with that of: - the Conveyor cells - it could cause Willy to turn around, or increment his frame of animation, as it passed under his feet?; - the Ramp cells - i.e. the reverse of the behaviour seen in Norman's file, causing Willy to bob down as it passes under his feet (perhaps into the path of a guardian?); - the Air cells - if Willy was standing on a single Water/Earth block and the BLOB passed through that block, then it would briefly turn to Air, causing him to fall through the block upon which he is standing (the BLOB would be invisible against the background though, unless it was given a pixel pattern and the INK and PAPER for the room's Air cells had different settings?); - the Fire cells - the blocks would be lethal if they hit Willy (that's already been done in a Geoff Mode patch actually); - the Earth cells - you could create a moving 'Innocent Looking Block' which Willy has to try to perform a quirky jump through, in order to access a lower level?!?; - Crumbly cells - causing a platform to crumble only when Willy is standing on it and the BLOB passes through it? - In JSW64, moving Trampoline or Trap cells? The former would force Willy to jump as it passed under his feet; the latter would cause him to start falling if it passed under his feet (even if the other half of his sprite is also standing on a solid block).

I've just realised that it would be possible to make the yellow Maria in The Nightmare Room animate through two, or indeed all four of her sprite-frames, if you wanted her to, without causing the yellow foot guardian (which shares the same guardian class number) to deviate from the foot sprite - but only if you swapped around the position of the foot and the barrel on their sprite page (i.e. Page #9C - put the barrel at #9C40 and the foot at #9C60). Of course, you would then have to adjust other instances of a foot or a barrel guardian elsewhere in the game, and also amend the pertinent addresses in the 'Game Over' routine accordingly.

Not that the defined ramp pattern in 'Under the Megatree' actually makes any sense for a ramp - it's a horizontal line, due to the value #FF stored at #C2C8. Willy would 'sink through' the line as he walked along it, if ever it were present and visible on the screen. Possibly Matthew inserted that non-zero graphical byte by mistake, whilst inserting values of #FF as default attributes for the ramp and conveyor (at #C2C4 and #C2CD)?

Gentlemen, we have just reached post #8000!

Which could suggest that Matthew knew about the problem, but worked around it rather than fixing it? I guess we'll never know. Thanks for the file and the analysis. P.S. One thing that your graphics on the line below the room name doesn't show, is any defined pixel patterns that are 'hidden' because the associated cells have a defined attribute with matching INK and PAPER settings. e.g. the ramp cells in 'Under the MegaTree'.

For reference, this was the post that Norman Sword is referring to (thanks Norman): http://jswmm.co.uk/topic/185-free-space-and-code-optimisation-in-jsw/page-8?do=findComment&comment=6101

The point I was making is that SPECSAISIE prints the initials 'BGB' for at least half of the rooms in JSW! But you only appear to have spotted the ones that happen to sit in the right-hand columns of the tables ('jutting out' from the main tables, so to speak). If you look again you will see there are 'BGB' entries scattered throughout the tables that you failed to spot the first time! ;)

I've just come across the first of the previously-documented instances of the CGB: the conveyor in Room 24 ('West of Kitchen'). Interestingly enough, the conveyor attribute matches one of the Water cell graphic bytes - but even if it didn't, the buggy CPIR loop would have encountered a match with two of the Earth cell graphic bytes anyway, before it reached the proper conveyor attribute byte! EDIT: A similar thing is true of the instance affecting the conveyor in 'Tool Shed'. ****** Room 29 'The Nightmare Room' - the previously-documented instance of CGB affecting the conveyor is present in the table - but that only occurs because the attribute byte for conveyor is located at the wrong Offset Byte within the room data! Once the misaligned bytes are shunted into where we think are their correct locations, the Cell Graphics Bug stops occurring even without the CGB Bug-Fix in place! Also in the Nightmare Room, as I spotted earlier, the Fire cells (which are unused but which have a defined pixel-pattern and non-#FF attribute) would be affected by the CGB if any were placed in the layout. ****** I've been through all the tables, and I'm now confident that there are no more* matches that would give rise to the Cell Graphics Bug, other than with a default #FF attribute byte for unused room elements. * i.e. no more matches other than the conveyors documented in the SkoolKit disassembly, the recently discovered instance affecting the Fire cells in 'A Bit of Tree', and the 'theoretical instance' affecting the unused Fire cells in 'The Nightmare Room' (which has a defined attribute and graphic, even though it is unused). Phew! P.S. I'd be happy to analyse similar tables for 'Manic Miner', if you have the time and inclination to put MM through the same SPECSAISIE analysis?

I've been going through the data. As I highlighted above, there are lots of instances of an unused room element with attribute set to #FF (or -1 as it is referred to in the SPECSAISIE tables), which matches with a full-infilled pixel-row that is listed earlier in the room data. Which is not a problem for unused room elements, of course. Aside: This has prompted me to think of something - if any of the non-conveyor tiles in 'Conservatory Roof' had happened to have a fully filled-in pixel-row, then the Cell Graphics Bug would have caused the conveyor present in that room to have a pixel-pattern, even though Matthew never defined one! Although since the conveyor attribute is set to #FF, this pixel pattern would only display itself when Willy is killed in that room, causing all the infilled pixels in the primary pixel-buffer instantaneously to flash in white-INK-on-black-PAPER! Anyway, one non-#FF value that I have come across is in Room 18 ('On the Roof'). The ramp attribute byte is set to #07, and there is a graphic byte with that value in the Earth cell data (third pixel-row down). However, the Cell Graphics Bug does not occur, because Water and Ramp cells share a common attribute in that room, and so the Water cell pixel pattern (which comes before Earth's definition in the data) takes precedence for the Water-Ramp combined cell-types.

Danny, have you only spotted the instances where the initials 'BGB' appear in the rightmost column of the tables (the 'overspill' column, that is empty in most cases)? There is an instance in Room 2 ('Under the MegaTree'), which is embedded in the middle of a table (and a regular 'Offset byte' number is shunted along into the right-hand column). The fourth pixel-row of the (unused) ramp tiles was apparently assigned a value of #FF (a solid line), which is rather peculiar given that there is no ramp in that room, and all the other ramp pixel-rows are blank (#00). That is then causing a match with the attribute byte for the (also unused) conveyor in that room. So (i) the 'BGB' flag must appear immediately after the byte which causes the erroneous match; (ii) there are probably more instances than you indicated at the top of your post #30 in this thread (many of which may be the default #FF 'unused attribute' value matching with a fully-infilled pixel-row); (iii) further investigation should (hopefully) confirm that all the previously-known instances of the CGB have been detected by SPECSAISIE after all!

Taking Room 16 (Quirkafleeg), the instance flagged up relates to the fact that the bottom pixel-row of the Fire cells is entirely filled in (value #FF), which causes a match with the (default) value of #FF for the conveyor attribute in that room. But there is no conveyor in Quirkafleeg, and if Matthew had put one in, he would almost certainly have ascribed a different attribute to it (notwithstanding the solid white block in Conservatory Roof, which must have been an omission on Matthew's part). So it is clearly necessary to do some manual, post-SPECSAISIE analysis of the generated tables, in order to extract any 'genuine' instances of the CGB.

Thanks Danny! Rooms 47, 62 and 63 aren't used in the game, of course!

Regarding the point in bold, this is actually the case in Jet Set Willy! If you place some Fire cells into 'The Nightmare Room', they aren't drawn as defined in the code, because their attribute byte matches the penultimate Earth cell graphic byte and so the Cell-Graphics Bug kicks into effect again! Richard's investigations evidently only took into account the defined room tiles that actually made it into the published game, not the ones that Matthew Smith defined but left unused and buried in the code!

Should have gone to SPECSAISIE! :D EDIT: Danny, in case that goes over your head - that's a play on the words of a series of TV adverts for a budget opticians we have here in Britain, called Specsavers. (Someone does something ridiculous due to their poor eyesight, followed by the punchline: "Should have gone to Specsavers!". Check out YouTube if you want a brief diversion.) BTW, did you try out that function of SPECSAISIE on an unmodified copy of JSW and/or MM, Danny? (To confirm what we already know in relation to the former, or to spot previously unidentified instances in the latter - there may be some lurking in the defined-but-unused cell types?)

Thanks Richard, that's useful to know. :) Have you checked whether the Cell-Graphics Bug affects any cavern elements in Manic Miner? I can't think of any examples off the top of my head, but it can occur in theory because the same erroneous use of a CPIR command is present in the routine which draws the layout to the pixel-buffer. I know that there are instances in Andrew Broad's mirror-imaged versions of both Manic Miner and Jet Set Willy - in the latter, there are new instances that arise because the graphic bytes are all laterally-inverted (Fire cells in The Attic, for example, whose attribute byte matches the penultimate graphic byte of the Earth cells if it's inverted), whilst I believe the same mirroring process either changes the nature of some of the existing examples of conveyor corruption, or in some cases 'cures' them altogether (i.e. prevents them from arising). ****** Here's another thing for your JSW TODO list (although I may have already mentioned this - can't remember - or perhaps you have already mentioned it in the JSW disassembly): Several vertical guardians in Jet Set Willy can extend below the bottom of their specified range (one or two of the bats that lurk between the columns of Fire cells in 'At the Foot of the MegaTree' do so, for example). It happens if the difference between the guardian's upper and lower bounds isn't exactly divisible its vertical speed. The 'out of bounds' situation only prevails for a single time-frame, whilst the guardian's direction of travel is being reversed. N.B. It doesn't happen at the top of a vertical guardian's specified range, because there is a specific command at #91A8 which sets the guardian's definition byte 06 as a 'hard' upper bound. ****** One other little point that you might be interested in, Richard - please see the post at the following link, which gives a possible explanation for the existence of a redundant instruction that is present in the 'Lose a Life' routine of both JSW (#8C19) and Manic Miner (#8925). You describe the instruction thus: "Set bit 4 of A (for no apparent reason)". http://jswmm.co.uk/topic/185-free-space-and-code-optimisation-in-jsw/?p=7817

Thanks Norman. You could use a similar PUSH IX / POP HL trick for all the 'Move the guardians' elements (ropes and horizontal guardians as well), couldn't you? Since H and L aren't used at all within that routine (and nor is there a CALL to a subroutine that does use H or L). EDIT: In fact, if that is the case, then couldn't the PUSH IX / POP HL be placed near the very start of the 'Move the Guardians' routine - after #90C0 but before #90C4 (with #91BB jumping back to include this 'variable swap') - so that it only has to be done once, rather than at the start of each branch of the routine (for ropes, horizontal and vertical guardians)?

Here's another bug fix, although this applies to the 'Move the guardians' routine, rather than 'Draw the guardians'. This fixes the bug (feature?) whereby certain vertical guardians can extend beyond their lowest permitted bound (if the distance between their upper and lower bounds isn't exactly divisible by their vertical speed). For comparison, this is the original code, courtesy of SkoolKid http://skoolkid.github.io/jetsetwilly/asm/90C0.html DD 7E 03 9193 LD A,(IX+$03) Update the guardian's y-coordinate DD 86 04 9196 ADD A,(IX+$04) DD 77 03 9199 LD (IX+$03),A DD BE 07 919C CP (IX+$07) Has the guardian reached the lowest point of its path (maximum y-coordinate)? 30 0D 919F JR NC,$91AE If so, jump to change its direction of movement DD BE 06 91A1 CP (IX+$06) Compare the new y-coordinate with the minimum value (the highest point of its path) 28 02 91A4 JR Z,$91A8 If they match, jump to change the guardian's direction of movement 30 0E 91A6 JR NC,$91B6 If the new y-coordinate is above the minimum value, jump to consider the next entity DD 7E 06 91A8 LD A,(IX+$06) Make sure that the guardian's y-coordinate is set to its minimum value DD 77 03 91AB LD (IX+$03),A DD 7E 04 91AE LD A,(IX+$04) Negate the y-coordinate increment; this changes the guardian's direction of movement ED 44 91B1 NEG DD 77 04 91B3 LD (IX+$04),A The above would need to be replaced with the following (which requires code consolidation to fit eight extra bytes into the available space, or else a JUMP to somewhere with the necessary free space): DD 7E 03 LD A, (IX+$03) Pick up the guardian's y-coordinate DD 86 04 ADD A, (IX+$04) Add the guardian's vertical speed; A now holds the updated y DD BE 07 CP (IX+$07) Has the guardian reached or gone past its lower bound? 30 07 JR NC, change_direction If so, jump to change its direction of movement DD BE 06 CP (IX+$06) Compare the new coordinate with the guardian's upper bound 28 02 JR Z, change_direction If they match, jump to change the guardian's direction of movement 30 16 JR NC, update_y If the guardian hasn't gone past its upper bound, jump to update y DD 7E 04 change_direction: LD A, (IX+$04) Negate the y-coordinate increment; ED 44 NEG this changes the guardian's DD 77 04 LD (IX+$04), A direction of movement DD CB 04 7E BIT 7, (IX+$04) Is the guardian's vertical speed now negative? 20 05 JR NZ, reached_bottom If so, the guardian must have reached its lower bound, so jump DD 7E 06 reached_top LD A, (IX+$06) Otherwise, the guardian has reached its upper bound, so 18 03 JP update_y make sure that the guardian's y-coordinate is set to its minimum value DD 7E 07 reached_bottom LD A, (IX+$07) Make sure that the guardians' y-coordinate is set to its maximum value DD 77 03 update_y LD (IX+$03), A Update the guardian's y-coordinate

Further to the above, I've also noticed that if you apply the Infinite Lives POKE, the RIP sprite briefly appears when Willy is killed - overprinting the right-hand dancing Willy in the 'Remaining Lives' bar - but then the rightmost dancing Willy is restored (replacing the RIP sprite) when the game resumes!

Has anyone noticed the instance of the Cell Graphics Bug affecting the Fire cells in 'A Bit of Tree' in the original JSW? It isn't documented anywhere in SkoolKid's JSW disassembly, I don't recall Stuart Brady mentioning it when he introduced his Cell Graphics Bug Fix, and a search in the Yahoo Group has drawn a blank. However, I find it hard to believe (in fact incredible!) that this hasn't been spotted before!?

I've tweaked the layout of the two 'Multimedia Guardian' test files, and re-uploaded them to my post from last night, in order to illustrate the point that Air cells can also have their PAPER miscoloured, if they are entered from the left (or from above) by a guardian that is passing from a different medium with a different PAPER setting.

You can see the bug in action in Andrew Broad's game 'JSW64:MM: James Bond'. That project would certainly benefit from the bug fix I've come up with, if Andrew ever gets round to developing the game further. Andrew had to pack a lot into every room (a whole James Bond movie's plot is represented by each room!), so the layouts are quite dense. As a result, there are a number of guardians which move through non-Air room elements, causing the PAPER colour of certain cells to be temporarily discoloured. Sometimes non-Air cells assume the PAPER colour of the Air cells; at other points in the guardian's trajectory, it is the Air cells which temporarily take on an anomalous PAPER colour. (Actually, the latter is something that my test file doesn't demonstrate [EDIT: It does now!], because the top-left cell of a guardian determines the PAPER setting of the rest of the guardian's surroundings, and in the test file the Air cells are all either above or to the left of the Water cells. So the Air PAPER colour always happens to takes precedence. I might rearrange the layout slightly, putting the 'parting of the Waters' more centrally, in order to display the full range of buggy behaviour - i.e. as the horizontal guardian passes through a column of Air cells sandwiched between two columns of Water cells, the PAPER behind the guardian will change TWICE.)

Et voila! In the attached 'Multimedia Guardian Test' file, the start room is set to the Swimming Pool. There are several vertical guardians (two BRIGHT and two non-BRIGHT) which dip in and out of the Water. The horizontal Monk guardian has turned into King Canute and is "holding back the tide" in the middle of the pool! The bottom row of the pool is comprised of INKless Fire cells, with the same cyan PAPER setting as the Water cells, but with BRIGHT On for the Fire and BRIGHT Off for the Water. The black Air cells have BRIGHTness switched to On. The 'Draw the guardians' routine now CALLS a subroutine, located at #9718, up to six times for each guardian that it draws. You can see that the guardians retain their original BRIGHTness setting when they are in the black background (Air) cells, but they assume the BRIGHTness setting of their host cells if the PAPER setting of the cells isn't black. You can also observe that the guardians are no longer drawn with a fixed PAPER colour for all of the cells that they occupy (based on the PAPER setting of their top-left cell). EDIT: I've also attached a file called 'Multimedia Guardian Without Fix', which illustrates the original problem when guardians (vertical or horizontal) move between different media of differing PAPER settings. Multimedia Guardian Test.z80 Multimedia Guardian Without Fix.z80

Thinking some more about the above, it could be resolved by taking the same approach to distributing the attributes for guardians, as the code which sets Willy's attributes in the secondary attribute buffer. i.e. put the code at #91EE-#91FD (modified to fix the Guardian Aura Bug) into a subroutine, which is then CALLed four or six times (each CALL would replace one of the existing LD (HL),C commands in the code that follows, up to #920E). Of course, the fix is only necessary if you have guardians moving between different mediums, which would both probably need to be INKless in order to prevent a pixel collision between the guardian and the non-Air blocks. In the original game, the Swimming Pool is the only place that I can think of where this would be possible (since the Water cells in that room contain no infilled pixels).