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