Pokes for Fixing the Cell Graphics Bug in JSW

[zub]

Okay, so it turns out that SkoolKid committed his fix in the SkoolKit disassembly about a month before I posted my fix! I

[IRF]

Okay, so it turns out that SkoolKid committed his fix in the SkoolKit disassembly about a month before I posted my fix! I

[IRF]

Also J.G.Harston's 'JSW Extensions' page was updated in 2017, which seems to be when he added the CGB fix.

 

So Stuart (Zub)'s fix on this forum seems to have been the first to be 'published' (unless you count Skoolkid's Github entry, prior to it being transposed to a disassembly update).

[IRF]

Note that both SkoolKid

[IRF]

For reference, Norman Sword's fix for the CGB (as part of a more fundamental rewrite/optimisation of the Room Expansion routine) is listed here:

 

http://jswmm.co.uk/topic/496-source-code-for-jsw/?p=11166

 

It involves a bounded search.

 

(P.S. My tablet attempted to autocorrect that to "a bouncer search", which sounds like a plotline from Neighbours during the 1980's.)

[Norman Sword]

I will correct the notion that it does a search. It uses an algorithm that does not do any searches. it places known data from a fixed position into a fixed position. 


It also removes the major bug that stops duplication of colours that should allow differing graphics, if specified. 

E.g. in JSW (out on a limb) we specify a stair and a platform to have the same colour.  Using the method I use will allow a stair to be drawn as well as the platforms. NONE of the methods listed elsewhere will permit this to happen

Edited May 10, 2020 by Norman Sword

[IRF]

Sorry yes, not a search in the sense of looking for a matching value.

 

I was picking up the terminology introduced by Zub about unbounded vs bounded searches, and trying to make the point that your method (like his) will only use data from within a fixed, intended range.

[IRF]

Incidentally, you can see the effect of a bounded search in action in Manic Miner (albeit that the data picked up falls beyond the intended range of the bounded search, if you insert* an attribute value into a cavern layout which doesn't match with any of the attribute or graphical bytes in the cavern's cell definitions.

 

(*e.g. Manually via the Hex Editor, not in JSWED's GUI.)

 

What happens is that when the CPIR loop comes to an end having failed to find a match after searching through the range of addresses #8020-#8067, HL is left pointing at the next address in the cavern buffer: #8068. The next eight bytes - #8068-#806E (various parameters which define Willy's state upon entry to the cavern) and #806F (which defines the conveyor direction for the cavern) are then interpreted as graphical bytes to draw the pixel pattern of the errant cell.

[Norman Sword]

Talking about the Final Barrier in Manic Miner. and graphic matching using the CPIR code. (re write to clarify)

 

1)

When the final barrier is drawn. The top part of the room contains graphic data. Which is also interpreted as the colours for the room. The room is then expanded out after matching these graphics colours. They are colours from the picture, but the room draw routine will interpret tham as room graphics
 

The colours are not intended to match the room graphics, they are the colours of the picture but the CPIR routine will still try to match the colours.
 

From memory I think the top graphic data has more than 9 differing colours.

Checking one of my source code lists . The top part has around 18 differing graphics- so in every case the graphics will not match the room graphic colour data. So in every case this would. if unchecked. possibly scan all memory.


2)

If the CPIR steps past the last known graphic, and onto stair data etc. Then it indicates that the loop should be shortened to stop on the last known graphic,

Edited May 10, 2020 by Norman Sword

[IRF]

I'd forgotten about The Final Barrier, it's actually a good example of what I was talking about. Some of the cells in the upper half of the cavern are drawn using data that is supposed to represent Willy's start position, movement flags, fall counter, etc for the top seven pixel-rows, and the conveyor direction byte for the bottom pixel-row of the cell.

In other cases, the Cell Graphics Bug causes 'classic' corruption of cells in the upper half of The Final Barrier - like you see in several rooms in JSW - where the defined attribute value inadvertently matches with a graphical byte value (one of the defined cell bitmaps).

But of course, none of this is ever seen in The Final Barrier - it happens 'behind the scenes' in the pixel-buffer, but is then overwritten by the graphic from the title screen before gameplay commences.

 

 

If the CPIR steps past the last known graphic, and onto stair data etc. Then it indicates that the loop should be shortened to stop on the last known graphic,

 

I don't think the search will ever go beyond the address #8068 that immediately follows on after the end of the cell graphics table, where HL is left pointing if the CPIR loop comes to an end without a match.  So there's no danger of a scan through the whole of memory (unless a patch has been applied that is based on an unbounded search, as per Skoolkid's or J.G.Harston's methods).

 

But I agree that it would be good to reduce the length of the CPIR loop by 9 (i.e. reduce the value assigned to BC by 09, prior to the CPIR being executed), so that the 'default' graphic for a 'none of the above' cell type can be defined and controlled, rather than the program picking up unassociated data for the purpose.

 

That would also have the benefit that you would be able to have different coloured switches within a single Kong cavern.  (The switch graphic definition uses the last slot in the table of cell graphics, and collision-detection between Willy and a switch isn't attribute-based.)

Edited May 10, 2020 by IRF