'Guardian Aura' Bug Fix and miscellaneous other patches

[IRF]

Further Update: I have also fixed the problem described here:

http://jswmm.co.uk/topic/184-guardian-aura-bug-fix/?p=7914

 

Update: for an optimised solution, see this post on page 3 of this thread:
http://jswmm.co.uk/topic/184-guardian-aura-bug-fix/?do=findComment&comment=5587

 

******

Here is a patch for the bug that is seen in Jet Set Willy in non-Black rooms, if a Guardian is present that has a different Brightness setting to the Air cells in that room. e.g. The Flying Pig in Emergency Generator.

The following 'new' code should be added - I suggest you locate it between #96f4 and #970b:

7e e6 38 c2 f1 91 dd 7e 01 e6 0f c6 38 e6 47 4f 7e e6 38 a9 4f c3 fd 91

Then the existing code at #91ee to #91fc should be edited as follows (this is based on the suggested starting address for the new code listed above):

c3 f4 96 dd 7e 01 e6 07 4f 7e e6 78 a9 4f 00

(The last byte is a NOPped out spare byte in the guardian-drawing routine.)

The above patch is an amalgamation of two routines in the original Jet Set Willy code (one of which was previously unused, except in Manic Miner). It eliminates the 'Guardian Halo/Shadow' bug in non-Black rooms, whilst allowing a wider range of guardian colours (Bright and non-Bright) in rooms with Black screens).

N.B. There is a simpler fix for the Guardian Halo/Shadow Bug that uses fewer bytes, but it would limit the colour palette of guardians throughout the game. i.e. with the simpler fix in place, all guardians on a given screen must be either Bright or non-Bright - even on Black screens where the Guardian Halo/Shadow Bug doesn't manifest itself. So for example, you would no longer see a Bright Red AND a non-Bright Red Monk in The Forgotten Abbey.

Note also that the way the alternative guardian-drawing routine (a remnant from the Manic Miner code) is implemented, avoids the following bug from occurring:

http://skoolkit.ca/disassemblies/manic_miner/reference/bugs.html#attributeCrash

So the above fix really provides the 'best of both worlds'!

Edited March 6, 2018 by IRF

[jetsetdanny]

Thanks a lot for this, Ian!  :)

[IRF]

I should clarify that the 'Guardian Halo/Shadow Bug Fix' doesn't eliminate the 'shadow' that occurs when a guardian's 2x2 square passes over Willy or other room elements (without a pixel collision, which is of course fatal), temporarily changing the Ink colour of part of Willy or the room elements that the guardian passes 'in front of'.

 

It only prevents a 'square halo/shadow' against the screen's background (of the opposite 'Brightness Polarity' to the room's Air cells). i.e. an anomalous Paper colour within the 2x2 square (or 2x3 rectangle when the guardian isn't cell-row aligned).

Edited July 17, 2016 by IRF

[jetsetdanny]

Ian, the bug fix is working fine AFAICT  :) .

 

Just one question. The modification you suggest to the original code at 91EE-91F0 makes the program jump to the new code located elsewhere. The instruction at the end of the new code makes the program jump to one byte *after* the modified original code. So it looks like all of the modified original code (after the jump instruction) is simply *bypassed*. How come it plays some role in the whole affair?

[IRF]

Ian, the bug fix is working fine AFAICT  :) .

 

Just one question. The modification you suggest to the original code at 91EE-91F0 makes the program jump to the new code located elsewhere. The instruction at the end of the new code makes the program jump to one byte *after* the modified original code. So it looks like all of the modified original code (after the jump instruction) is simply *bypassed*. How come it plays some role in the whole affair?

 

What you call the "modified original code" is actually the 'new' code [although it's based on an unused routine left over from Manic Miner].  Whilst what you call the "new code" is actually the 'old' [original JSW] code, relocated!

 

(I did it that way because the 'new' code is shorter, and therefore it - and a jump command to the new location - slotted nicely into the original location, without the need to carry out extensive consolidation of the existing 'Draw the guardians' routine.)

 

Are you still following me?  Good!  On we go...

 

The 'old' code (at the new location) actually starts at #96FA, as it is preceded by a check at #96F4: '7e e6 38 c2 f1 91'.

 

The first three bytes of that selects the Paper colour of the current room's Air cells i.e. the screen's background colour.  '7E' is LD A, (HL), which picks up the attribute byte of the cells in which a guardian is located; 'E6 38' is AND 00111000 (#38 expressed in binary), which selects Bits 3 to 5 (Paper colour) and ignores all the other bits of the attribute byte.

 

Then there is a 'C2' (JP NZ) conditional absolute jump command, which returns the program back to #91F1 if the Air Paper is NOT ZERO (i.e. non-Black).

 

Thus on the Black screens, the program proceeds as it always did (with both Bright and non-Bright Guardians potentially present, determined by the Brightness setting of each individual Guardian Class).  Whereas on the non-Black screens, the Brightness setting of the guardians is determined by the Brightness setting of the screen's Air cells (as specified by the 'new' code, via an 'E6 78' command - AND 0111000).

 

So the section of code that you thought was being bypassed is in fact the new element that fixes the 'Guardian Shadow' Bug!

 

N.B. My first attempt at a fix only had that 'new' code in place [with the original JSW guardian-drawing code from #91EE-91FC removed entirely], which did indeed fix the 'shadow bug'.  However, that placed limitations on the range of guardian colours that you could have present on the Black background screens - they could either all Bright or all non-Bright on a given screen, determined by the Air's Brightness setting.  (Of course, on non-Black screens, you still cannot have both Bright AND non-Bright guardians without one or the other displaying a 'shadow' against the background - I don't think it is possible within the game engine to define screen cells that have Bright Ink and non-Bright Paper colours, or vice versa.)

 

So to summarise, the final product - the code in the first post in this thread - calls up one of two sub-routines to draw the guardians onto a screen, and which one of the two sections of code is used is dependent on whether the screen's background (Air cells Paper colour) is Black or non-Black.

Edited April 5, 2016 by IRF

[IRF]

Actually, I've just noticed that the fix is even more comprehensive. The Swimming Pool has a Black background, but the Underwater Monk is walking amongst Inkless Water cells, which are of course non-Black (Cyan).

 

If you edit original JSW and turn that Monk Bright Yellow, it has a Bright Cyan Shadow against the surrounding non-Bright Cyan Water cells.

 

However, with the above patch in place, there is no shadow - the Monk is rendered non-Bright Yellow on this screen (unless the Water cells are set to Bright Cyan, in which case both the Monk Guardian and the pool's Water cells are Bright, so again no shadow!) But the same Guardian Class of Monk is seen in The Forgotten Abbey, this time in Bright Yellow!

Edited April 6, 2016 by IRF

[jetsetdanny]

Thanks a lot for your explanations, Ian! You've done a great and clever job designing the fix! It's much appreciated  :) .

[jetsetdanny]

As mentioned above, I have applied the fix in the Special Edition of "Willy's New Mansion".

 

I decided to make use of the spare byte which emerged after the mode modifications. In order to do that, I did the following:

 

 

The 'new' code is from #9BD2 to #9BE9 (for reasons related to the code distribution in "WNM SE") and it goes like this:

7e e6 38 c2 f2 91 dd 7e 01 e6 0f c6 38 e6 47 4f 7e e6 38 a9 4f c3 fd 91

The existing code at #91EE to #91FC has been edited as follows:

c3 d2 9b 00 dd 7e 01 e6 07 4f 7e e6 78 a9 4f

 

Therefore, I believe that thanks to the change in the C2 instruction in the 'new' code the spare byte, currently placed at #91F1, is omitted by the whole routine and can be safely used for other purposes (I have moved the music flags there from 85E2).

 

If I have missed something and there is a flaw in the above solution / reasoning, please let me know!  :)

[IRF]

I think I might have implemented it in that way in the first place, but when I came to typing it up for this article, I put the spare byte at the end, thinking that was 'neater'. (And I thought that if it had to be consolidated to sit alongside other spare bytes, to make good use of it anyway, then it wouldn't matter where exactly the spare byte was left.)

 

However, as you've presumably realised Danny, if it's been left at the end of the section of modified original addresses, then it wouldn't be safe to keep it in situ and use it for a single-byte variable (such as the Music Flags). This is because the program would stumble across it after drawing every guardian in a non-Black room, and may take whatever the value of the Music Flags happens to be at that instant, and try to interpret it as a command code - with unpredictable and potentially disastrous consequences!!

 

So your approach is better, Danny, as both of the alternative Guardian-drawing sub-routines bypasses the spare byte entirely!

 

Thank you for pointing out this 'trick', which may be a useful general principle to apply elsewhere in the code!

Edited April 6, 2016 by IRF

[IRF]

By the way Danny, hopefully the bug fix will have 'liberated' you to consider changing guardians on Black screens in WNM to Bright ON, without fear of causing any instances of the Shadow Bug around guardians in the non-Black rooms.

Edited April 6, 2016 by IRF