Jump to content
Jet Set Willy & Manic Miner Community

Opening Walls in JSW64


IRF

Recommended Posts

I was looking at the code which implements opening walls in the JSW64 game engine.

 

The way the existing code works, the pixel-rows disappear from top to bottom, and then the attributes of the blocks are turned from Earth to Air.  However, if you have a opening wall which is several blocks high, none of the blocks get turned to Air until the whole wall has had its pixels cleared.  So you can temporarily have an INKless wall, several blocks high, before the whole lot turns to air.

 

Having scrutinised the pertinent code, and thinking out loud, I wonder if the original intention was for each block in turn (from the top one down) to turn to Air as the eight pixel-rows of each are cleared.  A simple single POKE can be used to achieve this - and it involves reversing the conditionality of a relative jump (so a simple mistake by John Elliott when writing the code might explain the way the feature ended up, if my hunch is right that they were intended to disappear one-by-one).

 

Have a look at the two test files attached.  They illustrate the difference between the two variants of opening wall mechanics.  The opening wall in the 'unfixed' file behaves exactly the same as in the unpatched JSW64 game engine.  In the 'fixed' file, I've changed the value of address #FFD9 from #20 (JR NZ) to #28 (JR Z).

 

Willy starts off in the Off Licence.  Collecting the single item in the room causes the wall to start opening.  I've come up with a little challenge based on the different behaviour of the opening wall - only in one of this pair of files is it possible for Willy to leave the room and access The Bridge.

 

EDIT: Both files have been updated, with the addition of an extra Fire cell to prevent an (unintended) loophole.

MM Unfixed Opening Wall Test File JSW64X v.0.01 HL 12.tap

MM Fixed Opening Wall Test File JSW64X v.0.01 HL 12.tap

Edited by IRF
Link to comment
Share on other sites

That's quite good. The change is very easy to see.

 

 

Regarding the small challenge: I was not able to survive the jump down after the wall had gone, despite trying!

 

I suspect the correct method may involve a quirky manoeuvre, possibly by allowing his head to pass into a solid cell :unsure:

 

However I managed to *ahem* cheat my way out ;) I don't (think) this was intended escape route as its possible in both versions ? , one extra fire cell could prevent this though. Attaching two very small .rzx's of the escape, the 'fixed version' one is slightly quicker...

 

Unfixed_Escape.rzx Fixed_Escape.rzx

Link to comment
Share on other sites

The solution is so obvious when I saw it. :blush: I stayed on the righthand side of the wall and then tried various tricks to jump/land safely, with a vague idea of passing his head through a cell. Come to think of it I'm not quite sure how well those kind of 'quirks' are in JSW64 / JSW128 if at all...

 

The extra fire cell is about where I would of placed it too, to prevent an 'unintended escape' :)

Edited by Spider
Link to comment
Share on other sites

I was looking at the code which implements opening walls in the JSW64 game engine.

 

The way the existing code works, the pixel-rows disappear from top to bottom, and then the attributes of the blocks are turned from Earth to Air.  However, if you have a opening wall which is several blocks high, none of the blocks get turned to Air until the whole wall has had its pixels cleared.  So you can temporarily have an INKless wall, several blocks high, before the whole lot turns to air.

 

Having scrutinised the pertinent code, and thinking out loud, I wonder if the original intention was for each block in turn (from the top one down) to turn to Air as the eight pixel-rows of each are cleared.  A simple single POKE can be used to achieve this - and it involves reversing the conditionality of a relative jump (so a simple mistake by John Elliott when writing the code might explain the way the feature ended up, if my hunch is right that they were intended to disappear one-by-one).

 

IIRC, the opening-wall code is pretty much lifted from the Kong Beast rooms in Manic Miner, so that's the best place to start looking to see what the intended behaviour is.

Link to comment
Share on other sites

IIRC, the opening-wall code is pretty much lifted from the Kong Beast rooms in Manic Miner, so that's the best place to start looking to see what the intended behaviour is.

It works differently in MM's Kong rooms - there are two blocks which open up in parallel, the upper block opens 'upwards' (the bottom pixel-row clears first, then the next one up, etc) whilst the lower block opens 'downwards' (from the top pixel-row downwards). Because both blocks become cleared of all pixels at the same time, they turn to Air at the same time.

 

In JSW64 you can have a wall of arbitrary height (in terms of the number of Earth blocks), which opens from the top pixel-row downwards. Your code clears each pixel-row in turn, and then once the entire height of the wall is cleared of pixels, the attributes of each component block of the wall turn from Earth to Air. But the latter part of the code appears to allow for the possibility of turning each wall block to Air in turn, as each block's pixels become cleared. Indeed, reversing the conditionality of a single relative jump achieves this outcome, as I discovered.

 

The Manic Miner code doesn't really give a precedent from which we can draw a conclusion - at no point is there a 'completely cleared' wall block that is left retaining its 'INKless Earth' status, pending the clearance of the pixels of a separate block of the wall.

 

****

 

Incidentally, I have recently discovered a previously-undocumented bug in Matthew Smith's MM code: if you insert a blank pixel-row (00 graphic byte) midway down the Earth cell bitmap, then the opening wall turns to Air prematurely, leaving a 'ghost' of some remaining uncleared pixels - which the nearby horizontal guardian (whose range is edited once the wall has fully opened so that it passes through the gap created) promptly crashes into!

Edited by IRF
Link to comment
Share on other sites

Ah yes, I remember - because an opening wall is of arbitrary height it was easier to do it from the top or bottom than from the middle.

 

Looking at my original source, there's a comment:

;
;When all segments have slid, change cell attributes.
;

which suggests that I intended it to behave as I wrote it.

Link to comment
Share on other sites

Ah yes, I remember - because an opening wall is of arbitrary height it was easier to do it from the top or bottom than from the middle.

 

Looking at my original source, there's a comment:

;
;When all segments have slid, change cell attributes.
;

which suggests that I intended it to behave as I wrote it.

 

Fair enough. :)   Although, after having come up with the code tweak that causes the alternative opening mechanism, I think I actually prefer it that way - it seems more 'natural' that the wall blocks turn to Air one at a time, and it facilitates interesting challenges such as the one which Willy encounters in the 'fixed'* test file attached to the first post in this thread.

 

I wonder if there is a spare bit in the Opening Wall Guardian definition bytes, which could be used as a flag to determine which mechanism is used when a wall opens up?  Either on an individual 'wall instance' basis, or else on a 'per room' basis (with the code change to switch between the two mechanisms implemented via a 'Room Setup' Patch).

 

 

(*In hindsight, 'Fixed' and 'Unfixed' are inaccurate descriptions, in light of John's confirmation that the existing behaviour is as he intended.  'Changed ' and 'Unchanged' would be better; or 'Series' and 'Parallel' - the blocks turn to Air either in series or in parallel.)

Edited by IRF
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.