Are you developing a game for Windows, and are you working on input handling?
At first, it could reasonably be assumed that mouse and keyboard should be the simplest parts of this to deal with, but in reality, they are not – at least if we are talking about Windows. In fact, several extremely popular AAA games ship with severe mouse input issues when specific high-end mice are used, and some popular engines have issues that are still extant.
In this article we’ll explore a few reasons why that is the case, and end up with a solution that works but is still unsatisfactory. I assume that there is a whole other level of complexity involved in properly dealing with accessories like steering wheels, flight sticks, and so on in simulators, but so far I never had the pleasure of working on a game that required this, and this article will not cover those types of input devices.
↫ Peter ‘Durante’ Thoman
So, what is the problem? Basically, there are two ways to handle mouse input in Windows: if you use batched raw input processing, which is pretty much a requirement, you need to also choose whether or not to keep legacy input enabled. If you keep it enabled, the legacy input will add so much junk to your message queue it can negatively impact the performance of your game quite harshly. If you disable it, however, something really fun happens: you can no longer move the game window… Because the Windows UI uses legacy input.
Thoman has a solution that he and his company uses, and he considers it an ugly hack, but they just don’t know of a better way to solve this issue. Thoman keeps legacy input enabled, but just limits the number of message queue events per frame that are being processed (they limit it to 5). As far as they can tell, this doesn’t seem to have any negative side effects, but it’s clearly a bit of an ugly hack that shouldn’t be necessary.
I found this a rather interesting niche topic, and I wonder how many people have struggled with this before, and what kind of other solutions exist.