Opening Walls in JSW64

[IRF]

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 November 10, 2018 by IRF

[Spider]

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

[jetsetdanny]

An interesting technical, improvement, Ian, and very well designed examples illustrating it - congratulations! :)

 

Andy, well done on the alternative escape route!  B)

 

However, the proper solution is very simple:

 

Fixed Opening Wall solved.rzx

Edited November 10, 2018 by jetsetdanny

[IRF]

Well done Danny on completing it the 'official' way, and well done Andy on spotting the 'loophole'!

 

I've updated the files to prevent the latter, 'unofficial' solution (with a judiciously placed additional file cell), and reuploaded to the first post in this topic.

[Spider]

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 November 11, 2018 by Spider

[IRF]

Of course the escape route doesn't work in the 'unfixed' version, because Willy can't safely drop down one cell row at a time.

Edited November 12, 2018 by IRF

[JohnElliott]

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.

[IRF]

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 November 16, 2018 by IRF

[JohnElliott]

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.

[IRF]

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 November 19, 2018 by IRF