Creating slippery "Ice" platforms

[Norman Sword]

 My last post ---- In exasperation - Troll away - 

[IRF]

11 hours ago, Norman Sword said:

 My last post ---- In exasperation - Troll away - 

Norman, I didn't mean to 'troll' or exasperate you.  My intention in posting that "I've just noticed that Norman added a code listing to his last post here" was to draw the attention of others to the fact that you had latterly edited your earlier post to add some detail of your conveyor code.  If a member goes back and edit an earlier post then there is no notification on this forum that they have done so.  Indeed, it was only several days after you had edited the post that I noticed you had done so - I thought it might have escaped the notice of other members as well, so I tried to flag it up.

The code you provided in that post (which you have now apparently deleted) was very useful and informative, and I hope that you reinstate it. 🙂

[IRF]

P.S. I subsequently edited my post last night because I thought that I might have identified a typo?  I couldn't see how a conveyor direction byte value of db %01111110 could create a right conveyor?  The lowest two bits of a right conveyor are usually 01 (so that after subtracting 3, you get 10 in the lowest two bits - Bit 1 set, Bit 0 reset).  A conveyor with lowest two bits of 10 is usually an Off Conveyor (because the routine subtracts 3 leaving 11 in the lowest two bits, and no reset bits = no movement)?  However, I've just tried POKEing your file in the way that I suggested last night, and it didn't work in the way that I thought it would, so I bow to your knowledge of the way that your code operates. 🙂

P.P.S. I probably came across as pedantic when I suggested certain changes for "neatness and consistency", but that was more about me trying to get my head fully around the subject matter.  The point I was trying to make was that the status of bits 2-5 is less critical. EDIT: I was wrong on that point - see my subsequent post.

Edited February 8, 2023 by IRF

[IRF]

3 hours ago, IRF said:

P.S. I subsequently edited my post last night because I thought that I might have identified a typo?  I couldn't see how a conveyor direction byte value of db %01111110 could create a right conveyor?  The lowest two bits of a right conveyor are usually 01 (so that after subtracting 3, you get 10 in the lowest two bits - Bit 1 set, Bit 0 reset).  A conveyor with lowest two bits of 10 is usually an Off Conveyor (because the routine subtracts 3 leaving 11 in the lowest two bits, and no reset bits = no movement)?  However, I've just tried POKEing your file in the way that I suggested last night, and it didn't work in the way that I thought it would, so I bow to your knowledge of the way that your code operates.

Aha!  Cracked it!

I was puzzled about this - how a conveyor with direction byte 01111110 would cause Willy to move rightwards if he falls down vertically onto it whilst facing leftwards, without any movement keys being pressed.  Surely the fact he was facing left (bit 0 of #85D0 was set before he landed) would mean that leftwards movement would take precedence once the movement flag (bit 1 of #85D0) was set by Norman's code?  Why, then does the conveyor turn Willy around to face to the right before moving him rightwards?  (Conveyor type 6 in Norman's test file.)

But then I realised that, after the conveyor subroutine has subtracted 3 from the direction value, giving 01111011 - BIT 2 IS NOW RESET.  And it turns out that the higher bits of the conveyor direction byte (2-5) do actually help to determine Willy's sideways movement, not just bits 0-1.

N.B. For a normal right conveyor, value 00000001, subtracting 3 gives 11111110.  Only bit 0 reset so Willy moves right.
For an Off conveyor, direction value 00000010, subtracting 3 gives 11111111.  No bits reset so no movement (unless you press a left-right key).
A direction byte of 01111101 would also act as a right conveyor (subtract 3 and you get 01111010 - both bits 0 and 2 reset).

Edited February 8, 2023 by IRF

[IRF]

17 hours ago, IRF said:

There is one more conveyor logic permutation I can think of. (ie. Two more conveyor types, one L and one R.) Namely fast sliders but for which it IS possible to lock Willy in a stationary position (after falling vertically down onto it with the 'upstream movement' key depressed, or by walking upstream & releasing the 'upstream' key for a single time frame before pressing it again).

I think this additional conveyor type could be facilitated (though I haven't tried this yet) by replacing the first RET NZ in Norman's code with a JR NZ that just skips forward past the SET 1, (HL) command.

And then the conveyor direction bytes to implement that type of conveyor would be:

db    %11000000  ;L SLIDE CONVEYOR - LOCKOUT ON FALLING
Subtract 3 and you get 10111101 (bit 1 reset so it's a left conveyor; bit 6 reset causes fast sliding; bit 7 set means horizontal movement isn't automatically switched on if he falls onto it vertically)
db    %11000001  ;R SLIDE CONVEYOR - LOCKOUT ON FALLING
Subtract 3 and you get 10111110 (bit 0 reset so it's a right conveyor; bit 6 reset causes fast sliding; bit 7 set means horizontal movement isn't automatically switched on if he falls onto it vertically)

Armed with my new understanding of how the conveyor direction bits affect Willy's movement, I've managed to come up with a new pair of conveyor types.  Using a conveyor direction byte value of 11000001, and with a minor tweak to Norman's conveyor subroutine, I created a fast-sliding conveyor which otherwise retains the logic of the original JSW conveyors. e.g. you cannot drop down onto a conveyor from above and proceed upstream, but you can 'drop and stop' using the upstream button, and you can turn and stop by walking upstream and releasing the upstream movement key for a single time-frame then pressing it again.

Implemented in the attached test file. (NB If you lose a life, or leave the Bathroom and re-enter, or restart the game, then the conveyor will stop working in the above way and you'll have to reload the snapshot file).

Conveyor Logic test of new logic.sna

Edited February 8, 2023 by IRF

[IRF]

I think I've just come up with another new conveyor type (which also needs the minor tweak that I implemented yesterday to Norman's code to make it work - I replaced the first RET NZ with a JR NZ).

A conveyor direction byte value of 11000010. (After the conveyor routine subtracts 3, this becomes 10111111.)

I'm not in a position to try this out right now, but if someone wants to load up the 'Conveyor Logic test of new logic' snapshot file that I attached to my previous post, and apply the following POKE whilst Willy is in the Bathroom, they should be able to see it in action:

POKE 32982, 194

(If you could then save another snapshot and re-upload, I'd be much obliged.) 

Edited February 9, 2023 by IRF

[Sendy The Endless]

2 hours ago, IRF said:

I think I've just come up with another new conveyor type (which also needs the minor tweak that I implemented yesterday to Norman's code to make it work - I replaced the first RET NZ with a JR NZ).

A conveyor direction byte value of 11000010. (After the conveyor routine subtracts 3, this becomes 10111111.)

I'm not in a position to try this out right now, but if someone wants to load up the 'Conveyor Logic test of new logic' snapshot file that I attached to my previous post, and apply the following POKE whilst Willy is in the Bathroom, they should be able to see it in action:

POKE 32982, 194

(If you could then save another snapshot and re-upload, I'd be much obliged.) 

Like this? I call it the "turbo platform" : ))

Conveyor Logic test of newer logic.sna

[IRF]

22 minutes ago, Sendy The Endless said:

Like this? I call it the "turbo platform" : ))

Conveyor Logic test of newer logic.sna 48.03 kB · 3 downloads

Thanks!  Yes, that works exactly how I anticipated that it would. 🙂

It's an Off Conveyor, but Willy walks along it at double-speed if you press a left-right movement key (thanks to Norman Sword's code which responds to a reset bit 6 of the conveyor direction byte).  And he stops moving if you stop pressing the key, even if you're still on the (non-)conveyor.

One further quirk is that if you drop onto it from above without a sideways movement key pressed, Willy lands in animation frame 1, not animation frame 0 as usually happens when you drop off a platform onto the next platform below.

N.B. As with my previous snapshot file, the effect only lasts until you lose a life/leave & re-enter the room/abandon & restart the game.  (If you do one of those whilst playing around with the effect, you have to reload the game file.)

[IRF]

There might be one more permutation possible - try POKE 32982, 191.

It should behave like a sticky conveyor if you drop onto it vertically, but with fast sliding both leftwards and rightwards if you land on it via a sideways jump (or walk onto it).

[Sendy The Endless]

I hope these ideas open up allsorts of new gimmicks for designers to use in future JSW games. Yes, this one works as you suggested!

Conveyor Logic test of newerer logic.sna