koobas.hobune.stream
Exact meaning of Input.GetButtonDown()
Here's a paranoid question. What exactly do GetButtonDown(), GetButtonUp() and GetButton() return, and what is the relationship between them?
My own intuition tells me that GetButton() should return the state of the button at the instant when the frame began, GetButtonDown() should be equivalent to "``GetButton() && !GetButton_FromPreviousFrame``" and GetButtonUp() should be the same as "``!GetButton() && GetButton_FromPreviousFrame``". If so, then the following will always be true:
GetButtonDown()always impliesGetButton(), soGetButtonDown() && ~GetButton()will always equal false.GetButtonUp()always implies!GetButton(), soGetButtonUp() && GetButton()will always equal false.From 1 and 2 it follows that
GetButtonDown() && GetButtonUp()will always equal false.
Are these assumptions correct? Is this properly documented anywhere? My worst fear is that if in the duration of one frame the user magically manages to press a button and then release it, then both GetButtonDown() and GetButtonUp() will return true, and the same will happen if, on the contrary, the button is first released and then quickly pressed. Then I won't be able to distinguish between these situations! And the fear is not purely hypothetical too: occasionally a long frame happens, that lasts for like 0.3 seconds, and it is physically possible to push a button and release it in that time.
UPDATE: ok, an update (apparently I cannot answer my own question). Assumptions 1 and 3 above are wrong, assumption 2 is in the gray area. The most important lesson is like this: GetButtonDown() and GetButtonUp() are not mutually exclusive and can both return true in the same frame.
I've seen those pages, and they are not specific enough. They are not explicitly clear on what happens in the scenario that I'm talking about. They seem like introductory explanations, not addressing possible paranoid cases.
For instance, description of GetButton() says "Returns true while the virtual button identified by buttonName is held down.". That cannot be true to the letter, because GetButton() will always return the same value during one frame, and the actual state of the button can change, and even more than once.
Of course like this only one log message will appear. You use if-else-if.
O$$anonymous$$, I've made an actual experiment, and managed to get GetButtonDown() and GetButtonUp() to return true in the same frame, although I had to make frames long by loading Update() with useless work.
Hello,
Think of it this way: The only "real" input that the Unity application gets, is gathered into a queue from the operating system. This only includes key based up and down events. This queue is then stored and evaluated using "Input" before Update is called
KeyUp - There was an up event for this key between this frame and the last
KeyDown - There was a down event for this key in between this frame and the last
Key - There has previously been a KeyDown event for this key, but no KeyUp yet
The same goes for button (obviously through the input manager). This both explains why key up/down don't work in the fixed update loop, but just key does. It also explains how you can have both a KeyUp and KeyDown event for the same key on a frame.
If you want a coding example for how this is implemented in the backend, I can post that too :)
Hope this helps,
Benproductions1
Thanks a lot. This explains my experimental data perfectly. Of course, a code example would be great!
so how is that acceptable? This is just an awful design. Up should be true for the frame that it was released and Down should be true for the frame that it was pressed down. No question about it. This is an engine for writing games for fuck sake, you would expect everything to be logical and definite, not this crap.
