Every game needs the ability to interact with its user. Be it through a keyboard, mouse, dance pad, or other device, your game needs a way of getting direction from the person playing. The input device can be used to drive a car around a track, move your character around its world, or anything else that you can imagine.
Back in the days of DOS, game developers had very little choice but to poll hardware interrupts if they wanted to get keystrokes from the keyboard. Standard C functions of the time, like getchar, were too slow to be useful for games. Developers needed a better way; enter the Basic Input Output System (BIOS). The BIOS is the lowest level of software in a computer.
Stored normally in a flash ROM on the motherboard, the BIOS tells the system how to initialize and prepares the hardware for the operating system. The BIOS itself used to be directly accessible to programmers through assembly language while under DOS. Since the BIOS knew everything that the hardware was doing, developers were able to ask it for certain information. One of the important bits of the system that the BIOS was always watching was the keyboard. Every stroke of a key triggered a hardware interrupt, informing the system that a key had been pressed. Since this happened almost instantaneously, a very quick and efficient method for getting keystrokes from the keyboard was available.
When Windows NT came along, the ability to read the keyboard directly from the hardware was eliminated. Windows became an absolute boundary between applications and the hardware. Any information needed about the system had to be gained from the operating system since applications were no longer allowed direct access to the hardware. Windows had its own way of getting user input and that was through the message queue.
MSG msg = {0};while (WM_QUIT != msg.message){ // check for messages while( PeekMessage( &msg, NULL, 0U, 0U, PM_REMOVE ) == TRUE ) { TranslateMessage( &msg ); DispatchMessage( &msg ); }}
The message queue collects events, such as mouse movement and keyboard input, from the system. While this method is normally sufficient for Windows applications, it isn’t fast enough for games. Most developers at this point turned to another Windows function, GetAsyncKeyState, to get the information they needed.
This function allowed for very quick checking of the keys on the keyboard and even allowed for checking of multiple keys and the state of the mouse buttons. This method of collecting user input became common among game developers, but it had one major issue; it didn’t allow for input to be collected from other devices like game pads and joysticks. Game makers were stuck specifically supporting only certain devices because each device had a different way of collecting and transmitting the input data to the system.
A standard way of getting fast input from the user was needed regardless of the method or the device used. DirectInput provided the common layer needed to solve this problem.
Which Devices Does DirectInput Support?
DirectInput allows your game to support myriad of input devices without forcing you to know the exact details of each device. A small sample of the devices supported by DirectInput is shown here.
Keyboard
Mouse
Game pads
Joysticks
Steering wheels
