Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualMick is Stumped

Posted 18 October 2012 - 06:32 PM

Last night just as I was readying to demo a controller subsystem Direct Input 8 begins having a tendency to never come back from Acquire...

Anyway dinput8d.dll is no longer in any of the DX SDKs and seems to have even been backwards removed from the download links of SDKs from years past.

I am not convertible downloading it from a .dll repository website as they all look like the seediest things on earth.

But I am wondering if some of my usage patterns might be error prone and would feel better if I had a debug build either way.

Background: I have at this point a single thread that manages multiple devices all self contained. The outer framework is very asynchronous but the DirectInputDevice stuff is all self contained within the single thread itself. So I just don't see any excuse for the method to deadlock. The coop mode is background nonexclusive.

The controls seem to work in the control panel even when the thread is waiting for Acquire to return. Not sure if that would work if it was a driver bug. Thanks.

#2Mick is Stumped

Posted 18 October 2012 - 06:32 PM

Last night just as I was readying to demo a controller subsystem Direct Input 8 begins having a tendency to never come back from Acquire...

Anyway dinput8d.dll is no longer in any of the DX SDKs and seems to have even been backwards removed from the download links of SDKs from years past.

I am not convertible downloading it from a .dll repository website as they all look like the seediest things on earth.

But I am wondering if some of my usage patterns might be error prone and would feel better if I had a debug build either way.

Background: I have at this point a single thread that manages multiple devices all self contained. The outer framework is very asynchronous but the DirectInputDevice stuff is all self contained within the single thread itself. So I just don't see any excuse for the method to deadlock. The coop mode is background nonexclusive.

The controls seem to work in the control panel even when the thread is waiting for Acquire to return. Not sure if that would work if it was a driver bug. Thanks.

#1Mick is Stumped

Posted 18 October 2012 - 06:31 PM

Last night just as I was readying to demo a controller subsystem Direct Input 8 begins having a tendency to never come back from Acquire...

Anyway dinput8d.dll is no longer in any of the DX SDKs and seems to have even been backwards removed from the download links of SDKs from years past.

I am not convertible downloading it from a .dll repository website as they all look like the seediest things on earth.

But I am wondering if some of my usage patterns might be error prone and would feel better if I had a debug build either way.

Background: I have at this point a single thread that manages multiple devices all self contained. The outer framework is very asynchronous but the DirectInputDevice stuff is all self contained within the single thread itself. So I just don't see any excuse for the method to deadlock. The coop mode is background nonexclusive.

The controls seem to work in the control panel even when the thread is waiting for Acquire to return. Not sure if that would work if it was a driver bug. Thanks.

PARTNERS