EvilInput(TM)

DirectInput has been one of the commonly used components of game engines, especially the ones developed by hobbyists which easily cloaks the fact that it’s actually quite deprecated.

I believe that the reason DirectInput is so commonly used is not its ease of use. It is rather the amount of tutorials available on the Internet and also the amount of ready-to-use code written on top of DirectInput.

It has quite a bit of evil running under the hood, though. First of all, DirectInput creates a second thread to read data from input devices and process it. Having a separate thread for input processing running in the background may not be significant, which is relative to the application. It nevertheless has an unnecessary overhead. Another important point is that DirectInput is low level. But we want low level stuff when developing 3D applications, right? That’s not always true. DirectInput, for example, lacks the following features because it is such a low level API:

  • It does not apply pointer ballistics (i.e. pointer acceleration)
  • It does not process shifted input, such that you need to process input like “<shift> + a” so that it is interpreted as “A”.
  • It does not detect the state of caps lock but only detects whether caps lock key was pressed.
  • It cannot give you the absolute coordinates of the cursor. Instead you get a bunch of delta coordinates and have to process these along with the initial coordinates to compute the absolute coordinates at a given time.
  • It does not support key maps other than US English.

Some of the issues mentioned above may not sound as serious to you but they are indeed DirectInput issues. All of the features mentioned above are available when you handle standard Win32 input messages. The reason DirectInput doesn’t have these is because they are processed by the operating system at a higher-level layer than that of DirectInput. If you would like to spend time and implement such stuff in your application be my guest! Yeah, I didn’t think so either. I don’t even mention that using DirectInput usually requires considerably more code to get things working because of the low-level stuff.

Even Microsoft states that DirectInput offers no advantages whatsoever in the general case and its use should be avoided:

Overall, using DirectInput offers no advantages when reading data from mouse or keyboard devices, and the use of DirectInput in these scenarios is discouraged.

I confess that I have been using an input system based on DirectInput for years, mainly because of the aforementioned reasons, that is the availability of tutorials and code around. I actually implemented it like 5 years ago and did not want to spend time on reimplementing it without DirectInput, until now. I think I’ll do it sometime soon.

To sum up, try to stay away from DirectInput unless you need exotic features like force feedback or you absolutely need to support special DirectInput hardware. It probably won’t kill your application but what doesn’t kill your application may not turn out to make it stronger.

Leave a Reply