How does the simucube communicate with games?

Simucube 1
1

I am new to using the Simucube and direct drives in general. I have a project that requires that I send periodic effects using my own C# or C/C++ code. Is there any information on how games like Assetto Corsa communicates with the Simucube? Im not looking to change the firmware itself, just to be able to send commands to it.

1 Like
2

Hi,

Simucube can be commanded via Microsoft DirectInput, and thats how games usually do it. We do not have any code samples that we can share, as we suspect that there are sufficient samples in Microsoft DirectX SDK.

3

Thats what I had thought, I initially tried using a C# wrapper of DirectInput called SharpDX. Is there a reason that the simucube might not report a Guid but still show up as a gamepad/joystick to Windows?

My program reports all other joysticks that are connected. The firmware is installed and it works with other games so I dont think theres anything wrong with the unit. Ill try getting the same result with the native DirectInput API to see if there is any differences there. The function that I am using is below.

 if (joystickGuid == Guid.Empty)
    {
        foreach (var deviceInstance in directInput.GetDevices(DeviceType.Joystick, DeviceEnumerationFlags.AllDevices))
        {
            Debug.Log("Joystick: " + deviceInstance.InstanceName);
            joystickGuid = deviceInstance.InstanceGuid;
            joystickList.Add(joystickGuid);
        }
    }
1 Like
4

Simucube does seem to be getting a GUID in Windows. I belive this project has some working code samples on how to get the device handle, as at least their software here can list Simucube with GUID succesfully.

https://sourceforge.net/projects/x360ce/files/ditool.zip/download

5

Thank you. The x360ce program does report the simucube with its guid. Ill check out their repo and see if there are any clues as to why SharpDX wouldnt be working.

6

I think I’ve come across this issue with SharpDX some other time too (in a support request). In short, it did list it as another type of device for some reason that we didn’t manage to find out. My quick idea of reason: We do use a vendor specified report ID to transfer our custom data packets, and that might fool the Device Descriptor Parser to think strangely - maybe that report ID number is reserved somehow for some other purpose.