Resource centre for ZX Spectrum games
using Manic Miner and Jet Set Willy game engines
Archive of the
Manic Miner & Jet Set Willy Yahoo! Group
messages
|
|
|
|
|
Message: 7177
Author: ian.rushforth
Date: 06/03/2018
Subject: Re: Wraparound MM Bug
I've just discovered that the bug, whereby Willy corrupts Cavern 7 if he falls off the bottom of the screen in Manic Miner, can actually be fixed using a single* POKE!
POKE #92B5, #2C (or POKE 37557, 44 in decimal).
It replaces the INC IX at #92B4 with an INC IXL. So it prevents the 'Draw Willy' routine from looking up addresses, via the IX index, that are beyond the end of the table in page #83 of the code.
Instead, when Willy is falling off the bottom of a Manic Miner cavern, the lower part of his sprite is drawn at the top of the cavern (although in the first time-frame, his lower half may not be visible if the Air INK and PAPER settings match). Similarly, if he jumps up past the top of a cavern, his upper half appears at the bottom of the screen but his lower half remains at the top of the screen (whereas in the original MM game engine, his lower half disappears from the top at the instant when his upper half is drawn at the bottom).
With this POKE in place, whilst the low byte of IX may still be incremented from #FF to #00 in the circumstances described above, it is only IXL that is incremented, whilst IXH (the high byte of IX) always retains the value #83. In contrast, in the original code the incrementation of the full IX register-pair means that IX can proceed from #83FF to #8400.
N.B. This does not address the issue where Willy falling past the bottom of a cavern causes Air cells in the top two cell-rows to be replaced by errant (de facto Water) cells. To resolve that, a separate fix would need to be applied to the code which writes Willy's attributes to the screen. But that is a less serious problem, as the Air cells are restored the next time that the cavern is refreshed (whereas the overwriting of the Cavern 7 data by Willy's graphical bytes is a permanent effect).
(* For elegance, you could also replace the preceding INC IX at #92B2 with an INC IXL [using POKE #92B3, #2C or POKE 37555, 44 in decimal], but that isn't necessary to fix the bug, because the IX index always holds an even value going into those two consecutive INC IX commands, and therefore the first of the two will never have the effect of incrementing IX from #83FF to #8400.)
|
|
|