Pokes for Fixing the Cell Graphics Bug in JSW

[zub]

The update on Github wasn't transferred to a disassembly update until the following January:

https://skoolkid.github.io/jetsetwilly/reference/changelog.html#20160117

 

Ah, I guess I had no way of knowing, then! Looking back, I included an acknowledgement of SkoolKid

[zub]

Stuart, if this were the Manic Miner game engine under consideration, then an unbounded search could indeed lead to a search well beyond the intended range of data. Because the data in stored in MM in such a way that each cell of the screen layout could potentially be populated with any attribute value between #00 and #FF.

 

However, in Jet Set Willy, because of the way that the room layouts are compressed/expanded, each screen cell can only hold one of the six attribute values defined in the table of room cell definitions. So by the time the program comes to execute the CPIR code (or any of the fixes put forward here to replace it), I don't believe that an unbounded search will take place in practice in the JSW engine.

 

That seems reasonable. However, it may worth noting that mine was a fix for both MM and JSW, and I wanted to avoid unnecessary differences between the MM version of the fix and the JSW version.

 

It did occur to me that JSW might be immune for the very reason that you state, but given that the JSW engine tends to be full of interesting

[zub]

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

[zub]

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.

 

Thank you for sharing that: I had not actually bothered to check what was there in memory! Given that the graphic drawn will vary, that makes the case for saying it's less of an issue if an unbounded search is used. From a computer science PoV, I still really dislike that sort of code, but I suppose I must admit that on the Spectrum, it wouldn't be much of a practical concern.

Edited May 10, 2020 by zub