DirectInput Notes
Last modified
Direct Input
This is a new (2000) page on MSDN explaining the essentials of DirectInput 8.0 programming. This page has many tutorials and quite a bit of technical information.
DirectInput and Developing for Microsft Sidewinder Digital Game Controllers
This shows example code on how to support the Microsoft joysticks. This is interesting even if you are supporting other joysticks, becuase there is a lot of sample code.
This link is part of Angelic Coders, "Journals of a Direct X Junkie". It contains a quick tutorial on how to write a direct input program that will work under NT and Windows 95. (Written by Brian P. Shea)
Check it out! Not Working
Programming Mouse and Keyboard with DirectInput 3.0. by Peter Donnelly
An old article on MSDN. It has good explanations, as well as code samples.
Moving Your Game to Windows, Part II: Mouse and Joystick Input. by Peter Donnelly
Another old MSDN article, archived at loirak.com. Contains generic information on Direct Input 3. There are explanations on Joystick and Mouse programming, and small code samples.
Click here to go to Gamasutra's force feedback article
May the force Feedback be with you: Grappling with DirectX and DirectInput--MSJ, February 1998.
Immersion's Developers corner
This is the web page for TouchSense, the force feedback standard by Immersion Corporation. It has the SDK and primer, both available for download.
Cyberimpact SDK
Another force feedback SDK. This API claims to be compatible with DirectInput and I-FORCE.
Get World-Class Noise and Total Joy from Your Games with DirectSound and DirectInput.
written by Dave Edson
This page is on the DirectX eXperience site. It is mostly on Direct Sound, but the end holds a good overview of Direct Input 1.
Extending DirectInput's Joystick Subsystem Services. Not working This page is a MSDN article, showing how to get more information about a joystick. It uses joyGetPosEx, so most of the code is outdated. But, the registry information seems to still be valid and up to date. There are methods to get the joystick name, the number of joysticks, and other useful information.
Originally written by Brian Gosselin, Spacetec IMC
Modifications of Direct X 5 may cause some confusion. Devices like SpaceOrb 360 have data in different locations. With the changes in DirectInput in DirectX v5.0 the collection mechanism has changed, but not the data. As with any new version of DirectInput the data structure to receive the data has been changed from the DirectInput 3.0 structure.
DirectInput 3.0
typedef struct joyinfoex_tag { |
DirectInput 5.0
typedef struct DIJOYSTATE { |
There is an extended DIJOYSTATE2 structure that includes velocity, acceleration and force fields. HID devices are the only device types that can reach those data fields.
When Microsoft mapped the present DirectInput 3.0 data into the DirectInput 5.0 structure the fields ended up as:
DirectInput 3.0 | DirectInput 5.0 |
---|---|
dwXpos | lX |
dwYpos | lY |
dwZpos | lZ |
lRx | |
lRy | |
dwRpos | lRz |
dwUpos | rglSlider[0] |
dwVpos | rglSlider[1] |
Ramifications:
Unless devices are HumanInterfaceDevices, it is impossible to fill the Rx and Ry data fields. All the data was moved to the slider fields. Since the SpaceOrb and other multi-axis DirectInput devices make use the U and V fields, programmers must be aware that the data will appear in the slider fields. This impacts the configuration of the device for the end user. There are mechanisms to determine if a device is a HID device.
One way to determine this is to check the DIDEVICEINSTANCE structure, under dwDevType. If the DIDEVTYPE_HID flag is set, it means the device is HID.
There aren't many(any) HID/USB devices out right now that will cause these messages. Once the HID /USB devices come out, this will happen a lot.
Most of the time, when a program is checking the resulting values of IDirectInputDevice2::Poll it is looking for a result DI_OK, and expecting any other value to be an error. In DirectInput 5, this isn't correct.
COM specifies that unless the high bit is set to 1, the returned value is not an error but a status code. It is always a good idea to use the SUCCEEDED() macro to determine if a COM function has succeeded. For instance, Poll() can return a 1 for a result. This is not an error, this is an acceptable result.
If you do a compare between the data retrieved with the multimedia calls (joyGetPos) and the new Direct X 5.0 calls, you will notice a difference. That is because the calibration routines are different for each. This normally doesn't cause a problem. But, if you are using a joystick that has more than 2 axis, you may see some drifting on the third axis. That is because X and Y are set with a default 1% dead zone. All other axis have no dead zone. But, the new calculations have the at rest position one higher than the center position. The fix for this is to set the other axis dead zone to at least 1%.
typedef struct { DWORD dwSize; GUID guidInstance; GUID guidProduct; DWORD dwDevType; TCHAR tszInstanceName[MAX_PATH]; TCHAR tszProductName[MAX_PATH]; GUID guidFFDriver; WORD wUsagePage; WORD wUsage; } DIDEVICEINSTANCE, *LPDIDEVICEINSTANCE; typedef const DIDEVICEINSTANCE *LPCDIDEVICEINSTANCE;
The device friendly name should be in tszProductName.
Inside Direct X by Bradley Bargen Microsoft Press, 1998, ISBN:1572316969 The transcript of the authors chat at FreeWire cafe |