Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[identitycrisisuk]

This may be a little difficult to explain but I am working with a setup that registers as a joystick but uses the y axis as an identifier for the device mode. If changes to the y axis are made after our program has been running then we receive axisMoved callbacks/the joystick state is updated fine. However, until it is moved the joystick is reported to be dead centre - 0, 128 or 32767 depending on which value mode you're looking at. I assumed at first that we just weren't receiving an axisMoved callback, which is understandable since it hadn't moved from its starting position yet. However when I tried getJoyStickState() after a capture() I found that the state was constantly in a centralised position.

I know there must be some way around this as we have used poswdm.exe to examine the values being reported and that correctly shows the y axis position if it hasn't been moved since the program was first run. We have the OIS source code so we can make changes if necessary, I have tried to follow through the capture function in the debugger but then all of the joystick request functions seem to fail. I guess this is because we are not focused on the window related to that joystick now. We want to be able to get the actual joystick value as the program is started so that it can work from the start rather than having to be 'toggled' before it is usable.

Any ideas?

[identitycrisisuk]

Made some progress in this, looking in Win32JoyStick::capture I see that it uses IDirectInputDevice8::GetDeviceData but not IDirectInputDevice8::GetDeviceState. If I add in a call to GetDeviceState then the y axis value given there is correct but since GetDeviceData doesn't generate an event for the y axis it doesn't update mState.mAxes[axis].abs, which I'm reading values from. I'm not sure how I might go about updating mState from the DIJOYSTATE2 that GetDeviceState returns, other than hacking it horribly based on what I know should go where. Anyone got a quick clean way of doing this? I don't mind if it doesn't generate axisMoved callbacks at the end, I'll just be calling getJoyStickState() once after startup to get the initial y axis state.

[AshMcConnell]

Sorry I can't help, but just to say I'm getting the same problem.  When I start the game the axes have odd values until I move the controller (Logitech G25).  If there is any way to fix this or even a workaround I'd love to hear it.

Did you get any further identitycrisisuk?

Thanks
Ash

[AshMcConnell]

Correction it's not my G25 that it has problems with, it's the Logitech Driving Force Pro.  It also happens in the DirectInput Joystick sample in the DirectX SDK so I believe it must be a problem with either the logitech hardware or their driver, although strangely in the control panel it appears to be "normal", so there must be a workaround

[pjcast]

I have on the road map scanning initial state's of axes, hopefully this will fix your problem... I'm thinking as soon as the device is acquired, a call to getdevicestate could fill in proper initial values.

[AshMcConnell]

Thanks pjcast,  I'll have a look at getDeviceState to see if I can get it working, i'll post back any results.  If not i'll leave it to the expert

[AshMcConnell]

Hi PjCast,

As a quick test I hacked together a new version of Win32JoyStick::capture() that used GetDeviceState rather than GetDeviceData, but it still shows the same behaviour - i.e. odd values until the wheel or pedals are moved.

Code: [Select]

void Win32JoyStick::capture()
{
#ifdef OIS_WIN32_XINPUT_SUPPORT
//handle xbox controller differently
    if (mJoyInfo.isXInput)
{
captureXInput();
return;
}
#endif

//handle directinput based devices
DIDEVICEOBJECTDATA diBuff[JOYSTICK_DX_BUFFERSIZE];
DWORD entries = JOYSTICK_DX_BUFFERSIZE;
DIJOYSTATE2 state;

// Poll the device to read the current state
HRESULT hr = mJoyStick->Poll();
if( hr == DI_OK )
hr = mJoyStick->GetDeviceData( sizeof(DIDEVICEOBJECTDATA), diBuff, &entries, 0 );


if( hr != DI_OK )
{
hr = mJoyStick->Acquire();
while( hr == DIERR_INPUTLOST )
hr = mJoyStick->Acquire();

// Poll the device to read the current state
mJoyStick->Poll();
hr = mJoyStick->GetDeviceData( sizeof(DIDEVICEOBJECTDATA), diBuff, &entries, 0 );
//Perhaps the user just tabbed away
if( FAILED(hr) )
return;
}

hr = mJoyStick->GetDeviceState(sizeof(DIJOYSTATE2), &state);
mState.mAxes[0].abs = state.lX;
mState.mAxes[1].abs = state.lY;
mState.mAxes[2].abs = state.lZ;
mState.mAxes[3].abs = state.lRx;
mState.mAxes[4].abs = state.lRy;
mState.mAxes[5].abs = state.lRz;
I know there is redundant code and sliders / POVs etc aren't handled, but I just wanted to check if GetDeviceState would help.

I have tried to contact logitech on their consumer forum, but no response as yet.  I've signed up to their developer portal too, but no response yet.  If I hear anything I'll report back

All the best,
Ash

[pjcast]

I wasn't intending to change the method used by capture, but during the initial enumeration of the joystick, it could query the status with getdevicestate then.

Does this controller have its own driver? Or does it use internal Microsoft HID drivers?

[AshMcConnell]

Yeah, I didn't think you would do, it was just an experiment really.  Seems that GetDeviceState has the same problem as GetDeviceData though, so I don't think it will work (unless I am missing something).  This is a Logitech Driving Force Pro with the latest Logitech drivers.

All the best,
Ash