Open GameOverture opened 7 years ago
Thanks for the heads-up. You're right this is a problem if you check the state of an input device (or via InputMap
). This should, however, not be a problem if you use an input listener (be it InputListener
or MappendInputListener
).
Does that help? Can you confirm that this works?
When looking through your library I did notice InputDeltaState being coupled with listeners, and they might be able to solve this problem. My code that utilizes and wraps around gainput is meant to be a generic, reusable library so I don't want to have to enforce using listeners (yet).
I managed to fix the issue on my end, and I sent a pull request with those changes. Feel free to use or ignore the pull request. It's not a lot of code, but I may have not accounted for all the different features and platforms you support.
If these two messages occur and are processed in the same frame (via
InputManager::HandleMessage()
), by the timeInputManager::Update()
is invoked it will essentially think nothing happened as the boolean has been flipped back already.Under normal circumstances a "down" and "up" message for either mouse or keyboard usually doesn't get processed in the same frame. At least can't make it happen without the use of breakpoints in code.
However I have an ELO touchscreen hooked into a Windows 7 embedded image, which is responsible for sending these mouse events, to emulate mouse stuff for programs that don't understand touch. When I tap the screen the
WM_LBUTTONDOWN
andWM_LBUTTONUP
get sent essentially at the same time (in order), and cause the input to be ignored as explained above.I should be able to hack my way around this problem, but I figured I'd mention it here.