[kazade]

I'm currently writing a C library implementation of the Sonic Physics Guide but I've noticed something that isn't documented and might not be as simple as I thought; how to determine which direction the character should face...

In my implementation I naively switched direction based on gsp - if gsp is less than zero and we aren't facing left, then face left, and vice versa. However I've noticed the following:

• When balancing on an edge, sonic seems to change direction to face the edge and this change seems permanent - you can see by jumping
  
• When hitting the bumpers in SYZ the direction doesn't change although gsp does
  
• When hitting a normal horizontal spring, direction changes but it doesn't seem to do so immediately

Does anyone have the full behaviour documented? Are there other edge cases? Is there a delay when hitting a spring or is it just my eyes?

Thanks!

[Mercury]

Facing is not strictly based on gsp. Off the top of my head:

• On the ground, facing is set when checking for input. If pressing left and gsp<0, then face left. Likewise if pressing right and gsp>0, then face right. So it's a combination of gsp and input direction - they have to both line up.
  
• In the air, it's different. Facing matches input regardless of speed. So if you press left, he'll face left even while still moving right. Thus you can run right, jump, tap left, turn around, and land facing left but moving right, I.e. some kind of moonwalk.
  
• As for the balancing animation, it forces facing when the animation is set, because Sonic 1 does not have a backwards balancing animation.
  
• Springs set facing in the direction they bounce you when you hit them. The also set an input delay (about 16 steps) so you don't brake immediately after hitting them if you are still holding the D-pad toward them when you hit them.

[MarkeyJester]

Mercury, on 19 February 2014 - 08:01 AM, said:

• Springs set facing in the direction they bounce you when you hit them. The also set an input delay (about 16 steps) so you don't brake immediately after hitting them if you are still holding the D-pad toward them when you hit them.

Actually, the springs simply reverse the direction, they don't actually set. If you hit a spring facing backwards, it'll reverse you so you are still facing backwards. Also, an additional part of the delay is in fact caused by the SST priority. Where the spring changes Sonic's "Memory $22" direction. But it doesn't come into effect until the next frame where the Sonic object gets to read $22 and apply it to $01 correctly. Which is one frame extra than it needs to be.

[kazade]

Mercury, on 19 February 2014 - 08:01 AM, said:

Facing is not strictly based on gsp. Off the top of my head:

• On the ground, facing is set when checking for input. If pressing left and gsp<0, then face left. Likewise if pressing right and gsp>0, then face right. So it's a combination of gsp and input direction - they have to both line up.

Yeah, that's what I figured, so I think my logic is correct:

    if(facing_ == DIRECTION_LEFT) {
        if((gsp_ > 0.0 && x_axis_state_ == AXIS_STATE_POSITIVE) || ground_state_ == GROUND_STATE_BALANCING_RIGHT) {
            facing_ = DIRECTION_RIGHT;
        }
    } else {
        if((gsp_ < 0.0 && x_axis_state_ == AXIS_STATE_NEGATIVE) || ground_state_ == GROUND_STATE_BALANCING_LEFT) {
            facing_ = DIRECTION_LEFT;
        }
    }

Quote

• In the air, it's different. Facing matches input regardless of speed. So if you press left, he'll face left even while still moving right. Thus you can run right, jump, tap left, turn around, and land facing left but moving right, I.e. some kind of moonwalk.

Ah yes! Thanks I'll implement that.

Quote

• As for the balancing animation, it forces facing when the animation is set, because Sonic 1 does not have a backwards balancing animation.

Cool, dealt with above.

Quote

Actually, the springs simply reverse the direction, they don't actually set. If you hit a spring facing backwards, it'll reverse you so you are still facing backwards. Also, an additional part of the delay is in fact caused by the SST priority. Where the spring changes Sonic's "Memory $22" direction. But it doesn't come into effect until the next frame where the Sonic object gets to read $22 and apply it to $01 correctly. Which is one frame extra than it needs to be.]

Thanks, I'll make my springs do the same.

Thanks both of you!

[KingofHarts]

ALSO, for implementing other objects... correct me if I'm mistaken, but the "Facing" status bit works the opposite for many other objects (I.e. Badniks) as it does for Sonic. Meaning that a Facing value of 1 for Sonic, will have Sonic facing the opposite direction that a facing value of 1 for a Motobug.