Sign in to follow this  
Hurp

Unity Input and updating objects

Recommended Posts

While thinking about the input manager i am creating I began to wonder what the correct way of updating objects based up input was. Currently for any objects that need to be updated I simply add them all to a list of "process objects" and update them. However, with key detection happening at all times, how should I handle updating objects that move depended on input? For example, if I had a camera that moved when I pressed the "W" key, I would want that to process before the next time my list of "process objects" get updated, or is that a bad idea?

Share this post


Link to post
Share on other sites
It shouldn't really matter as long as you do it during the update of the camera. I mean, humans aren't able to distinguish the time between two 60Hz frames, and we aren't able to hold a button down for 1/60th of a second. So it's not going to matter if the user presses the button and you do it immediately, or if you simply wait until the update of the camera and then just check if the player has the button pressed. The user won't be able to tell the difference between the two options.

Share this post


Link to post
Share on other sites
Most of the time, I like to take a "snapshot" of the input state at the start of the frame, and anything checking input goes by that. That way, you can check if a key was just pressed that frame, just released that frame, etc. and it's all consistent for everything. Also more portable, as you can use it on console systems by just checking the state of the keys at the start of the frame, and on event-based input systems like most computers, you have the events update the stored input state, and make a copy of it at the start of the frame.

Just-pressed/just-released events seen by the game are computed logically by examining the current frame's input snapshot versus the previous frame's snapshot, not by setting flags when processing keyup/keydown events or anything. Those are only used to update the current pressed/not pressed states that will be seen next frame. Much easier when the game code can check the up/down states rather than trigger states sometimes, and they all match up.

It doesn't play that well with jumpy frame rates though, like computers do sometimes. You can miss a press and release entirely during a long frame. If it's a problem, you could probably come up with some kind of buffering system, like if a keydown event happens, then make sure the key is seen as being pressed on the next frame regardless of whether it has actually been released before then. But make sure you keep the buffered state separate from the true state, so you don't end up with keys stuck down and such by ignoring the keyup events.

Share this post


Link to post
Share on other sites
Yeah, my previous workplace did something similar, with a global input manager that stored all the button states at the beginning of the frame, but I can't recall ever having a problem with an input or button press being ignored or missed because of a long frame.

Granted, most of the games I worked on were for non-PC platforms (DS, PSP, PS2, Wii), but I would have expected it to be more of a problem on those less powerful platforms. Anyway, DekuTree64 is right that a multiple buffering system would help, but just make sure that you have consistent problems on a retail (not debug) build of the code.

Share this post


Link to post
Share on other sites
Well one of my main concerns if if the camera also have a physics object on it, for example, when it may be a third person camera.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this