This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

A restructuring of the controller inputs...

A restructuring of the controller inputs...
by on (#39920)
This is something I've been thinking about, but I wanted to ask first.

Basically, my game's got the controller to work and move you around and all that good stuff. Though I've been wondering about doing things such as conveyor belts or fans that can move you without you requesting to move and I'm concerned the way I'm doing things now is not going to be compatible if I decided to implement these things.

So my question would be: Is there a proper way to be checking all the inputs? Right now I'm doing something like this:

-Set a flag for what direction you moved to 0 (1 is left, 2 is right), set flags for if you moved horizontally/vertically to false
-Checks if you pressed left/right to move (can be applied to ground movement or falling/jumping)
-If you requested to move and it's possible, move. Sets the horiz. move flag to true and the direction flag to the requested direction.
-Checks if you requested to jump and if possible, move up. Sets the vert. move flag to true
-While jumping, it checks each pixel if you hit something on your way up and changes the jumping flag to false if you did and immediately exits the jumping routine. Also, the check for directional input gets called again for each pixel you move up so the player can "squeeze" into narrow spaces. If I didn't do this check, you'd have to be pixel perfect to get in between such spaces. This particular check ALSO checks if the horiz. move flag is true because if it didn't, you'd be able to move twice in certain frames and get a much faster speed.
-Checks if you are falling. If the flag for jumping is true, this is skipped entirely. If not and falling is possible, do it. Sets that vert. flag.
-The same directional input check and checks per pixel for jumping also occur for falling.

-Basically after this, it's just checks for shooting, animation, and death.

My methodology does work currently, but I think there are possibly better ways I could be doing it that I may not be seeing. If anyone's got any ideas, I'd love to hear 'em.

by on (#39987)
Balloon Fight has 64 bits for each fighter:
  • Position, X component, 1/256 pixels
  • Position, X component, whole pixels
  • Position, Y component, 1/256 pixels
  • Position, Y component, whole pixels
  • Velocity, X component, 1/256 pixels
  • Velocity, X component, whole pixels
  • Velocity, Y component, 1/256 pixels
  • Velocity, Y component, whole pixels

I haven't traced the Super Mario Bros. games, but I'd be surprised if they didn't do something similar for at least the player character.

To move the character each frame, you calculate the net accelerations on the player, add that to the velocity, and add the velocity into the displacement.

Think of how running works in real life: person exerts force on the floor, and the floor exerts force back on the person. So when it is determined that an actor is on a floor-type object, and the player is pressing sideways, calculate the difference between the velocity of the floor and the velocity of the actor, and use that for figuring out how much force the actor can exert.
Re: A restructuring of the controller inputs...
by on (#39998)
Your problem is that you have the input tied directly to the movement, while it would be better to have the input modify velocity variables, and the velocity variables are used to update the player's position every frame. That way you could have other things besides input modifying those variables, so that the final result is a combination of all forces.

by on (#40002)
Quote:
Your problem is that you have the input tied directly to the movement

I do that for my game right now and it works quite well, because the player contols the first derivate of player's position (velocity) and not the second derivate (acceleration) as he does in SMB for example.

But yeah I'd get in trouble if I want the player to move by its own in demoplay for example. I guess I'd have a programm that create a false joypad input and call the normal player moving routine (I do that when the player finishes the level).

by on (#40004)
Bregalad wrote:
I guess I'd have a programm that create a false joypad input and call the normal player moving routine (I do that when the player finishes the level).

But then what happens when the engine pushes the player in a direction and the joypad in the other? This is not really problem for conveyor belts and fans, because you actually want to merge both forces, but with scripted motion I guess you'd want to disable input from the controller.

Of course there are ways to achieve this, you could for example skip the joypad reading altogether and supply the engine with fake button presses, like in a demo video.

I, at least, feel that directly manipulating the positions of characters is a poor alternative to even the simplest of the physics engines.