Playing around.

[IRF]

To be clear, I wasn't suggesting that Willy should automatically look downwards when he falls down a shaft.  I just wondered whether the player retains the ability to rotate the torch beam whilst he is falling.

 

I would have expected that this would not be possible in your earlier test file (described in post #164 of this thread), where you had forced the beam to face forwards based on Willy's facing direction AND based on his jump/fall counter*.

 

But I would have expected that it would be possible to look down whilst falling in the later test file (described in post #166), where you only tested Willy's facing direction and not the jump/fall counter to decide whether to force a sideways beam.  It sounds like you have proved me wrong on that point?

 

 

(*Actually, there are two separate variables involved in jumping.  There is a joint variable for Airborne Status, which is reset to 00 by default, holds 01 when jumping, values from 02 upwards when falling - acting as a Fall Counter - and is set to -01 [#FF] as a 'Willy is dead' indicator.  And a separate Jump Counter variable which keeps track of Willy's progress through a jump.  I presume the former is the one that we're talking about in terms of what you were testing at one stage, to determine whether to make the torch beam face forwards?) 

[Norman Sword]

Removing most of the checks and leaving just two checks. On the same condition.

 

1) if a change in movement status. Then direct beam. this detects change of face direction. when static.

 

2) If moving left or right then direct beam.

 

-------------------------------------------------------

 

In the spiral room. Beam can be rotated downwards as willy falls. Beam can be rotated upwards as willy climbs

 

In the Eyeball room beam can be rotated as the floors collapse, or as you climb vertically

 

In Eugenes . A quick walk of the first platform, and on the long fall. the beam can be rotated as you fall.

 

A simple animation change from facing left to facing right. The beam will swap sides.

 

No checking for jumping/falling. Just the movement status now (if moving) or a change in status

 

------------------------------------------------------

 

(*Actually, there are two separate variables involved in jumping.  There is a joint variable for Airborne Status, which is reset to 00 by default, holds 01 when jumping, values from 02 upwards when falling - acting as a Fall Counter - and is set to -01 [#FF] as a 'Willy is dead' indicator.  And a separate Jump Counter variable which keeps track of Willy's progress through a jump.  I presume the former is the one that we're talking about in terms of what you were testing at one stage, to determine whether to make the torch beam face forwards?) 

 

Airborne status is set to 6 when starting a fall. This is the point at which which forward movement is stopped and willy falls vertically.

No longer testing for this condition. The code I used, lasted only 10 minutes, before removal. 

 

 

 

 

[IRF]

My replies in red:

 

Removing most of the checks and leaving just two checks. On the same condition.

 

1) if a change in movement status. Then direct beam. this detects change of face direction. when static.

 

2) If moving left or right then direct beam.

 

Don't both of those relate to the same variable? i.e. different bits of the same byte?  If so, could it be done via a single check, rather that two?

 

-------------------------------------------------------

 

In the spiral room. Beam can be rotated downwards as willy falls. Beam can be rotated upwards as willy climbs

 

In the Eyeball room beam can be rotated as the floors collapse, or as you climb vertically

 

Those are better examples of where the ability to direct the beam up or down would be useful!  The example I gave of dropping into the flashing portal in Return of Kong is a bit of a 'fall of faith', because I believe the torch beam doesn't extend far enough to be useful for avoiding hitting the 'rolling rock' guardian which traverses past the portal - you can't tell where the rock is until you have already fallen down a few rows, by which time it's too late to do anything if you are on course to hit it!

 

------------------------------------------------------

 

 

Airborne status is set to 6 when starting a fall. This is the point at which which forward movement is stopped and willy falls vertically.
 

Incidentally, the reason for the value 6, I think, is so that the pitch of the falling noise transitions smoothly from the jumping arc to the falling sequence.

EDIT: Also, so that the fatal fall distance is the same regardless of whether you descend from the apex of a jump, or whether you just walk off a ledge.

Edited July 15, 2020 by IRF

[IRF]

Question: in Eugene's Lair, why when I first enter the cavern is the vertical Amoebatron colour-cycling (as if it is an 'Angry Eugene', although it doesn't settle down directly above the portal in the way Angry Eugene does), but then if I lose a life and the cavern is refreshed, the Amoebatron stops colour-cycling and remains cyan (until such time that all the items have been collected, at which point the colour cycling kicks in again and it descends to guard the portal as you would expect)?

Edited July 15, 2020 by IRF

[IRF]

Question: in Eugene's Lair, why when I first enter the cavern is the vertical Amoebatron colour-cycling (as if it is an 'Angry Eugene', although it doesn't settle down directly above the portal in the way Angry Eugene does), but then if I lose a life and the cavern is refreshed, the Amoebatron stops colour-cycling and remains cyan (until such time that all the items have been collected, at which point the colour cycling kicks in again and it descends to guard the portal as you would expect)?

 

Regarding the above oddity, I've been back and checked and that was the case in the earlier Manic Panic files as well, I just didn't notice it at the time.

 

****

 

Back on the subject of rotating the torch beam, if Willy finds himself on a conveyor belt standing still (e.g. if you fall onto a conveyor whilst keeping the 'upstream' sideways movement key depressed, so the keypress and the conveyor cancel each other out), are the rotate keys active whilst Willy remains stationary on the conveyor?

 

I presume the answer is yes, because the sideways movement flag isn't set in that situation, even though a Left-Right movement key is being pressed by the player.

Edited July 16, 2020 by IRF

[Norman Sword]

Updated the title screen animation.

Removed all other versions.

1 version which has all the updates in.

That's my lot on this format-version.

 

This Link 





 

[IRF]

Thanks for the latest (final?) file, Norman!

 

Having seen it in action, I can now answer my own questions in red:

 

Regarding the above oddity, I've been back and checked and that was the case in the earlier Manic Panic files as well, I just didn't notice it at the time.

 

The 'Premature eFLASHulation' of Eugene is now fixed!

 

****

 

Back on the subject of rotating the torch beam, if Willy finds himself on a conveyor belt standing still (e.g. if you fall onto a conveyor whilst keeping the 'upstream' sideways movement key depressed, so the keypress and the conveyor cancel each other out), are the rotate keys active whilst Willy remains stationary on the conveyor?

 

I presume the answer is yes, because the sideways movement flag isn't set in that situation, even though a Left-Right movement key is being pressed by the player.

 

Yes, that is indeed possible.  Useful in some situations for 'surveying the scene' around Willy.

 

Here's an idea in case you ever developed this further - I think it would be good to make the K and L rotate keys provide a 'hard rotate' function, so that they override the sideways movement. e.g. if you're travelling along a long conveyor, you can inspect what is above/below Willy as you're moving along.  (There is no concern about your 'other hand' fingers getting in the way of the O-P Left-Right movement keys, because in this situation the conveyor would be doing the moving.)  With H and J being overridden by the sideways movement as per the current situation.  If such a distinction is technically feasible?

Edited July 19, 2020 by IRF

[Spider]

I concur.  Thank you for the latest version! :)

 

I'm sorry I've not been able to participate (much) the past couple of week or so due to lack of online time, real life intrudes much lately.

[Norman Sword]

The worm that plays -


The ball playing worm on the Title screen. After I wrote the routine, I was very tempted to add a screen with just the worm on the bottom of the screen and the balls being fired up across the screen. It would have been similar to the Sky-labs, only with the objects moving up and down from below.

If I do any other games - I might add the worm.

Edited July 20, 2020 by Norman Sword

[Spider]

I think it might be a worthwhile addition when/if the game in question suits. :)