Collect input counts over one frame to avoid missing inputs within the same frame #3383
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.