DirectInput Programming Examples
Moderator: Moderators
DirectInput Programming Examples
Moderator Edit: the sample code is no longer available from the FTP service. Please contact 3Dconnexion API Support if you need further assistance.
DirectInput (DI) can be used to get data from 3Dx devices. It is a good API for getting raw data from the device, but has its limitations. Also see our HID and RawInput (WM_INPUT) examples.
The advantages are:
1) You don't need COM or Windows, nor a static library nor any software at all from 3Dconnexion. That can be good and bad. You also don't get any help from 3Dx software (we are only trying to make your development easier!)
2) You may already have DI code in your application or game that you can reuse.
3) You can handle more than one device at a time (as many as you can connect to your machine!).
The disadvantages are:
1) There are some quirks in the DI implementation that have to be coded around.
2) You take the 3DxWare driver out of the loop (some may see that as an advantage ). Therefore you lose everything that the driver is doing for you. You need to implement anything it does if you want it.
The main things the 3DxWare driver does for you are:
2.1) Automatically adds support for new devices as they come along. Careful coding can avoid problems with new devices.
2.2) Adds a dead-band around the rest position of the device to keep it from drifting. Without this, the device may never return to zero and you will constantly get data from it.
2.3) Adds a non-linear response curve to the data. Without it you get linear data.
2.4) Handles disconnection/reconnection of devices. You can do this with other system calls.
2.5) Handles button mapping, axis orientation alternatives, axis scaling and filtering. Normally a game has a control panel that does this.
2.6) Saves user changes per application.
2.7) Implements a scheme to make sure your application uses all the data from the device each frame. Without this your application may keep moving for a while after the user lets go of the device, as your application eventually eats through all the data in the queue. Careful coding must be used to eliminate this.
3) There is not access through DI to some of the more advanced functions, like turning LEDs on/off, the SpacePilot LCD, etc. You can access these features through HID.
4) Older devices, even the SpaceTraveler, don't work the same as the SpaceNavigator, SpacePilot, SpaceExplorer. If you must, you can handle these old devices on a case by case basis.
There are two examples on our examples ftp site.
ftp:/ *** ***
username: ***
password: ***
The two examples are a polling example and an event-driven example. There is documentation for each.
You need to provide your own links to your own DirectInput SDK.
The polling example is the easiest to implement and conceptualize. When you are ready to do something, poll the device and do the math. It is an inefficient model, but matches the AI simulation loop of games perfectly.
The event-driven example allows your application to go to sleep if nothing is happening. This frees the CPU for other apps and is appropriate for most classes of applications. Unfortunately, DI makes this a bit more complicated to code. The details are in the DI8Example doc and code.
These examples use DI8, but I believe these are the latest DirectInput APIs, even though the encompassing DirectX product is at a later version.
Let us know what you do with it.
Jim
3Dx Software Development
DirectInput (DI) can be used to get data from 3Dx devices. It is a good API for getting raw data from the device, but has its limitations. Also see our HID and RawInput (WM_INPUT) examples.
The advantages are:
1) You don't need COM or Windows, nor a static library nor any software at all from 3Dconnexion. That can be good and bad. You also don't get any help from 3Dx software (we are only trying to make your development easier!)
2) You may already have DI code in your application or game that you can reuse.
3) You can handle more than one device at a time (as many as you can connect to your machine!).
The disadvantages are:
1) There are some quirks in the DI implementation that have to be coded around.
2) You take the 3DxWare driver out of the loop (some may see that as an advantage ). Therefore you lose everything that the driver is doing for you. You need to implement anything it does if you want it.
The main things the 3DxWare driver does for you are:
2.1) Automatically adds support for new devices as they come along. Careful coding can avoid problems with new devices.
2.2) Adds a dead-band around the rest position of the device to keep it from drifting. Without this, the device may never return to zero and you will constantly get data from it.
2.3) Adds a non-linear response curve to the data. Without it you get linear data.
2.4) Handles disconnection/reconnection of devices. You can do this with other system calls.
2.5) Handles button mapping, axis orientation alternatives, axis scaling and filtering. Normally a game has a control panel that does this.
2.6) Saves user changes per application.
2.7) Implements a scheme to make sure your application uses all the data from the device each frame. Without this your application may keep moving for a while after the user lets go of the device, as your application eventually eats through all the data in the queue. Careful coding must be used to eliminate this.
3) There is not access through DI to some of the more advanced functions, like turning LEDs on/off, the SpacePilot LCD, etc. You can access these features through HID.
4) Older devices, even the SpaceTraveler, don't work the same as the SpaceNavigator, SpacePilot, SpaceExplorer. If you must, you can handle these old devices on a case by case basis.
There are two examples on our examples ftp site.
ftp:/ *** ***
username: ***
password: ***
The two examples are a polling example and an event-driven example. There is documentation for each.
You need to provide your own links to your own DirectInput SDK.
The polling example is the easiest to implement and conceptualize. When you are ready to do something, poll the device and do the math. It is an inefficient model, but matches the AI simulation loop of games perfectly.
The event-driven example allows your application to go to sleep if nothing is happening. This frees the CPU for other apps and is appropriate for most classes of applications. Unfortunately, DI makes this a bit more complicated to code. The details are in the DI8Example doc and code.
These examples use DI8, but I believe these are the latest DirectInput APIs, even though the encompassing DirectX product is at a later version.
Let us know what you do with it.
Jim
3Dx Software Development
-
- Posts: 1
- Joined: Fri Apr 04, 2008 4:38 am
when you say "the entire MS SDK"
I have
Microsoft Platform SDK for Windows Server 2003 R2 is that what you mean.
I've done that, and it is still not clear how to modify the project file in the example to build correctly.
Microsoft Platform SDK for Windows Server 2003 R2 is that what you mean.
I've done that, and it is still not clear how to modify the project file in the example to build correctly.
As far as I see, the DI8ExamplePoll.cpp doesn't actually need atcoll.h or the rest of the atl, so simply delete themehdi_862000 wrote:I have MS SDK and VC++ 2005 express edition. I have most of atl files but no atlcoll.h
Where can I get it? is it limited to pro MS VC++ version only?
Code: Select all
#include <atlcoll.h>
if TRACE_EVENTS is define you will need to add
Code: Select all
#include <tchar.h>
#include <strsafe.h>
the dxerr8.lib in the linker dependencies to dxerr.lib
Markus
You don't need ATL anyway to use DirectInput.
1.DirectInput8Create() to create an IDirectInput8*.
2. IDirectInput8::CreateDevice(),
3. IDirectInputDevice8::SetDataFormat(), SetCooperativeLevel(), SetEventNotification(), and a thread to be resumed when that event is set.
3. When event is triggered, IDirectInputDevice8::GetDeviceState() and you know when the state of the 3D mouse changes.
1.DirectInput8Create() to create an IDirectInput8*.
2. IDirectInput8::CreateDevice(),
3. IDirectInputDevice8::SetDataFormat(), SetCooperativeLevel(), SetEventNotification(), and a thread to be resumed when that event is set.
3. When event is triggered, IDirectInputDevice8::GetDeviceState() and you know when the state of the 3D mouse changes.
There is an issue with SpacePilot Pro under the DirectInput API, device perform calibrating all the time on any wheel's movement. This cause data reset to zero with a short period of time and we have small motion/stop/reverse.
Tested in our app. and same effect in DI8Example.exe also. It works fine under driver's test app.
Buy the way, Navigator works fine in DirectInput on same config.
How can I fix this?
Thanks.
Tested in our app. and same effect in DI8Example.exe also. It works fine under driver's test app.
Buy the way, Navigator works fine in DirectInput on same config.
How can I fix this?
Thanks.
Windows XP SP3, 32 bit. The latest DirectX.jwick wrote:Hello DeeMAGE,
That's interesting. We haven't had reports of that before. What operating system are you running on? What version of DirectX are you using?
3Dx Engineering
SpacePilot Pro is not detected as HID device, so I think that's a driver's bug.
Thanks.