Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collect input counts over one frame to avoid missing inputs within the same frame #3383

Closed
wants to merge 5 commits into from

Conversation

RoryO
Copy link

@RoryO RoryO commented Aug 4, 2020

In response to #2787 I'm attempting a low impact way of addressing dropped inputs over the course of a frame. This can happen at the standard 60hz refresh with high frequency devices like high quality keyboards. It's also possible this happens when frame rate drops.

This changes the KeysDown array from an array of bits to an array of unsigned integers. That change alone has no affect on any code since a standard C++ bool is 1/0 and not a special object. This means existing implementations can gradually adopt this change along with widgets. From there in the example win32 impl when we process pending window message we total up all the down events for that key. This also introduces KeysUp and KeysUpPrev arrays of unsigned integers. When processing the window messages, tally the up events into the KeysU array.

We have two Up arrays so we can process Up events in the next frame. Upon NewFrame, we subtract the Down events from Up events that occurred the previous frame. This way we capture the down event and can process it when there is a down and up within the same frame.

I thought about also changing MouseUp/Down in this way. The more I thought about it the more I think that may actually make the problem worse with errant clicks in areas the user doesn't expect. Currently it appears the input interface checks if the mouse is down and then gets the current position of the mouse. This could lead to situations where the last recognized mouse position on a lagged frame was different than the position the user actually clicked causing inputs they didn't expect. I can't think of a quick slot in solution for that situation like this keyboard input one. I think we'd need either encoding a mouse click with the coordinates of the mouse at that moment in time or go full on event list and replay the events in order every frame. Both of those are a monumental undertaking and may not be worth the effort.

@RoryO RoryO marked this pull request as ready for review August 5, 2020 20:41
@ocornut ocornut force-pushed the master branch 2 times, most recently from 0c1e5bd to bb6a60b Compare August 27, 2021 19:10
@ocornut ocornut force-pushed the master branch 2 times, most recently from 8b83e0a to d735066 Compare December 13, 2021 11:31
@ocornut ocornut force-pushed the master branch 2 times, most recently from b3b85d8 to 0755767 Compare January 17, 2022 14:21
ocornut pushed a commit that referenced this pull request Jan 17, 2022
…nt() api + updated all Backends. (#4858) (input queue code will be next commit)

Details: note that SDL, OSX and GLFW backends removed recording of MouseJustPressed[] which will be unnecessary with input queue (which is the NEXT commit). (#2787, #1992, #3383, #2525, #1320)
@ocornut
Copy link
Owner

ocornut commented Jan 17, 2022

FYI dear imgui 1.87 WIP now uses a new IO api (e.g. io.AddKeyEvent() io.AddMouseButtonEvent() etc.) which implement an input trickling queue, normally solving this problem correctly and everywhere for all types of inputs. We'll monitor feedback and expect bugs to have creeped as we reoverhauled that system.

See e.g.

Also see #4858 for a general overview.

@ocornut ocornut closed this Jan 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants