I'm adding support for the SpaceNavigator to a real-time strategy game. As that I despise COM, especially for something as simple as USB device communication, I've opted instead to simply use interrupt IN methods.
That said, I've found your report structures a bit odd. I understand that report ID 0x03 are button reports, but why is it that you use both a report ID 0x01 and report ID 0x02? It would seem that one might combine the two into a single report (unless perhaps you are accounting for low-speed USB bus connections)?
It would be tremendously helpful to me, and perhaps others here, if you could explain the byte pattern used for each of the report packets. What I'm seeing is interleaved report 0x01 and report 0x02, and my assumption is that report 0x01 is broken down as follows:
Byte 0 - Report ID
Byte 1 - X axis movement
Byte 2 - Y axis movement
Byte 3 - Z axis movement
Byte 4 - Rotation about the X axis movement
Byte 5 - Rotation about the Y axis movement
Byte 6 - Rotation about the Z axis movement
Which would seem to align with the HID Multi-Axis controller specification. However, I'm stumped as to what Report ID 0x02 provides; it does seem to be related to the others.
Any insight you can provide here would be most excellent.
Regards,
Enoch Root
Adding game support: Report ID's and byte ordering
Moderator: Moderators
-
- Posts: 2
- Joined: Wed May 02, 2007 8:41 am
Hi EnochRoot42,
The following piece of code should help you pick apart the USB packets:
switch( pRpt[0] )
{
// Axis Translation Data (1)
case 1:
nAxisX = (((short)pRpt[2]) << 8 ) | (unsigned char)pRpt[1];
nAxisY = (((short)pRpt[4]) << 8 ) | (unsigned char)pRpt[3];
nAxisZ = (((short)pRpt[6]) << 8 ) | (unsigned char)pRpt[5];
break;
// Axis Rotation Data (2)
case 2:
nAxisRx = (((short)pRpt[2]) << 8 ) | (unsigned char)pRpt[1];
nAxisRy = (((short)pRpt[4]) << 8 ) | (unsigned char)pRpt[3];
nAxisRz = (((short)pRpt[6]) << 8 ) | (unsigned char)pRpt[5];
break;
// Button State Data (3)
case 3:
switch( nPID )
{
case SPACENAVIGATOR_USB_PID: // (0xc626)
/* 2 buttons.*/
wButtons = ((DWORD)pRpt[1] & 0x0000003);
break;
}
}
Jim
3Dx Software Development
The following piece of code should help you pick apart the USB packets:
switch( pRpt[0] )
{
// Axis Translation Data (1)
case 1:
nAxisX = (((short)pRpt[2]) << 8 ) | (unsigned char)pRpt[1];
nAxisY = (((short)pRpt[4]) << 8 ) | (unsigned char)pRpt[3];
nAxisZ = (((short)pRpt[6]) << 8 ) | (unsigned char)pRpt[5];
break;
// Axis Rotation Data (2)
case 2:
nAxisRx = (((short)pRpt[2]) << 8 ) | (unsigned char)pRpt[1];
nAxisRy = (((short)pRpt[4]) << 8 ) | (unsigned char)pRpt[3];
nAxisRz = (((short)pRpt[6]) << 8 ) | (unsigned char)pRpt[5];
break;
// Button State Data (3)
case 3:
switch( nPID )
{
case SPACENAVIGATOR_USB_PID: // (0xc626)
/* 2 buttons.*/
wButtons = ((DWORD)pRpt[1] & 0x0000003);
break;
}
}
Jim
3Dx Software Development
-
- Posts: 2
- Joined: Wed May 02, 2007 8:41 am
Most excellent! Although I had performed similar experiments on byte ordering, I had not made the assumption that the reports were delineated as translation and rotation.
Likely this was due to misinterpretation of the multi-axis controller portion of the HID usage specification. Many thanks for the clarification.
Likely this was due to misinterpretation of the multi-axis controller portion of the HID usage specification. Many thanks for the clarification.