zub Posted May 10, 2020 Report Share Posted May 10, 2020 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 jetsetdanny and IRF 2 Quote Link to comment Share on other sites More sharing options...
zub Posted May 10, 2020 Report Share Posted May 10, 2020 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 IRF 1 Quote Link to comment Share on other sites More sharing options...
zub Posted May 10, 2020 Report Share Posted May 10, 2020 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 IRF and jetsetdanny 2 Quote Link to comment Share on other sites More sharing options...
zub Posted May 10, 2020 Report Share Posted May 10, 2020 (edited) 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 IRF and Spider 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.