Jump to content


Photo

Pokes for Fixing the Cell Graphics Bug in JSW


  • Please log in to reply
63 replies to this topic

#61 zub

zub

    Space Marine

  • Contributor
  • 98 posts

Posted 10 May 2020 - 04:37 PM

The update on Github wasn't transferred to a disassembly update until the following January:
https://skoolkid.git...g.html#20160117

 

Ah, I guess I had no way of knowing, then! Looking back, I included an acknowledgement of SkoolKid’s page on the block graphics bug at the time of my posting, and I would have hoped I would have noticed any POKEs that had been added.

 

In any case, it’s remarkable that for a game 31 years old at the time, two of us independently implemented a fix for a well-known bug only a month apart, followed by a third only a year and a half later!



#62 zub

zub

    Space Marine

  • Contributor
  • 98 posts

Posted 10 May 2020 - 04:52 PM

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 “surprises”, I felt that it was safest to make the loop be bounded anyway.

 

I hope the hint of irony was clear enough in my initial announcement when I stated that it was “only” (!) 16-bytes long! As my version of the fix was intended for the Nightmare Edition I didnt really expect many people to be typing it in as POKEs, so it didt seem worth optimising it for size. I was fairly sure that no matter how hard I tried, others would do a better job of that, anyway: the main thing was to get the ball rolling. :-)

 

As a general fix for the problem, its worth considering that modifications to the JSW engine could easily break any assumption that screen cells can only hold attribute values defined in the block graphics table. Personally, I’d prefer use of an easily recognised game-wide block graphic as the default: perhaps the "?" character in the font, although I’m not so strongly oriented towards to the “quick and dirty” style of programming that wasn’t uncommon in 8-bit games programming, that’s also helpful in fitting everything in to such a small space!


  • IRF likes this

#63 zub

zub

    Space Marine

  • Contributor
  • 98 posts

Posted 10 May 2020 - 05:01 PM

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/t...or-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’s fix is definitely a more proper fix for the bug, but of course one would want to be more careful about applying it to existing game data. I’d started designing a unified MM and JSW engine at one point and I had definitely intended to apply a fix along these lines. Matt Smith’s use of attribute values as tile IDs struck me as very strange when I first saw that part of a Manic Miner disassembly, and there’s a startling directness to that approach. I’m not sure if it would have really saved work, or simply cost time during development in workaround around quirks/bugs. I suppose we can never know whether the engine might have evolved differently if he hadn’t taken that approach. It’s possible platforms and crumbling platforms in Manic Miner would have had the same brightness, but beyond that, who can say?



#64 zub

zub

    Space Marine

  • Contributor
  • 98 posts

Posted 10 May 2020 - 05:07 PM

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 by zub, 10 May 2020 - 05:07 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users