Stuff

DirectInput is the name of the library in Microsoft DirectX at provides direct access on Windows to input devices such as the mouse, keyboard, and game controllers. Well, except that for some time, there's been nothing "direct" about DirectInput at all. Ever since Windows NT, pretty much all of the functionality in DirectInput can be replicated by going straight to the Win32 APIs and using functionality such as low-level keyboard hooks and raw input messages. Once you learn this, some of the restrictions of DirectInput become clear, such as why you can't reliably intercept input from a full-screen application using your own low-level keyboard hook.

I found this passage in the DirectInput docs for EnumDevices() today, which I found especially amusing:

On Microsoft Windows XP, DirectInput enumerates only one mouse and one keyboard device, referred to as the system mouse and the system keyboard. These devices represent the combined output of all mice and keyboards respectively on a system. For information about how to read from multiple mice or keyboards individually on Windows XP, see the WM_INPUT documentation.

Not only is DirectInput not direct, but it's even less direct than the regular Win32 API....

(See also: "DirectSound" and "Windows Vista.")

I guess it's a much more common scenario for people to want multiple keyboards or mice to act identically than for a program to read them separately, but it seems like DirectInput would be the natural place to expose such functionality. There's so much API churn in Windows lately that I think Microsoft bought a blender.

It's fairly common for images to be represented as a structure that includes width, height, and a field called pitch or stride. The pitch of an image is the distance in bytes between the start of one scanline to the next. It allows an image to be specified such that the scanlines aren't adjacent in memory, which is useful for achieving a given alignment. Software tends to run slightly faster if 8 or 16 byte alignment can be achieved; hardware sometimes has more draconian alignment requirements, like 128 bytes.

A fairly common mistake I see when handling an image with pitch is code like this: