Hey guys. Yeah, I'd like to join the x360ce project. In fact I've already done a bunch of bug fixes and added some significant features to the codebase. I obviously can't commit them, but you can download the changes for review from my DropBox here:
https://www.dropbox.com/s/qn9xgog8bpmjvw9/x360eXntrc.zip?dl=0
I've been waiting to play GTA V on PC forever and I was especially excited to be able to play with my racing wheel and flight stick. As you probably know those hopes were dashed a few days ago when GTA came out supporting only Xinput and only one controller at that. So I decided to fix that.
Here's a summary of the fixes / changes I've made in the above linked codebase:
Fixed a bug in in Controller.cpp and Config.cpp where a badly formatted Trigger or Axis mappings could lead to a crash. In short it was caused by the line of code
u32 index = std::abs(m_mapping.Axis.id) - 1
which could lead to an unexpected value for index if id was set to zero. I added a test case for id 0 to skip the mapping and added a log warning in Config.cpp when an invalid mapping is seen.
Fixed a few bugs in Controller.cpp where the left trigger [0] deadzone was being used for the right trigger [1].
Fixed a bug in Controller.cpp and x360ce.App where trigger deadzones went by different names ("Left Trigger DZ" / "Right Trigger DZ" in dll and "LeftTriggerDeadzone" / "RightTriggerDeadzone" in app). I changed them both to use "Left Trigger DeadZone" and "Right Trigger DeadZone".
Fixed a bug in ControllerManager.cpp that caused PassThrough to get set to true by default. This was because the value variable was never explicitly initialized which left it to be a random number (considered true).
Added a new config option 'ForcesPassThrough' (0 Off, 1 On). This feature allows a controller to participate in mappings, deadzones, etc. but have its vibration data sent unaltered to the device. When this feature is enabled, the underlying device is also used when querying for Xinput capabilities so that the game knows the right vibration data to send.
Added new config option 'PassThroughIndex' (0 - 3). This is necessary since we load controllers by their InstanceGUID or ProductGUID but we also allow users to specify which player they want the controller to represent by supplying a UserIndex. What if more than one controller is an XInput device? We could get into a situation where physical controller 2 has been mapped to player 1 and vice versa. This setting allows us to make sure vibration data gets routed to the right physical device.
Added support for virtual controllers that don't represent a physical device! This was accomplished by changing most of the application to use an abstract ControllerBase class instead of the concrete Controller implementation. Also added one virtual implementation (see below).
Added support for virtual force feedback devices in a similar way by targeting most of the code at an abstract ForceFeedbackBase class. Also added one virtual implementation (see below).
Added support for combining multiple physical (or virtual) controllers into a single virtual controller! This was accomplished by creating ControllerCombiner which inherits from ControllerBase and has its own collection of child controllers. When input is read from ControllerCombiner it in turn reads data from all child controllers and intelligently combines them (e.g. if one controllers x axis is -200 and another controllers x axis is +100 the virtual x axis is -100).
Added support for combining multiple physical (or virtual) force feedback devices into one virtual force feedback device! This was accomplished with the ForceFeedbackCombiner class which functions similarly to the ControllerCombiner class. It simply forwards force data to all child devices that support force feedback and uses the first child in the collection used when the game queries for force feedback capabilities.
Added new config option 'Combined' (0 Off, 1 On). Specifies that a physical device will participate in combining.
Added new config option 'CombinedIndex' - (0-3). Specifies which player index a controller should get combined into. Multiple controllers can (and should) have the same CombinedIndex. If three controllers are set to 'CombinedIndex = 1', those three controllers will appear as a single controller for player 2.
Added new config option to the global section called 'CombineDisabled'. This can be used to temporarily disable combining for all controllers, which is handy since once controllers are combined they appear combined even in the x360ce front-end!
Note that other than the bug fix mentioned above I have NOT yet done any updates to the front-end. I will be working on that next. There is also a bug I haven't quite figured out yet in ForceFeedback.Shutdown. The call to SendForceFeedbackCommand(DISFFC_RESET) just hangs on application exit (but not when Restart is called). I could use some help figuring out what's going on here.
Well, that's it. Please let me know if you would like these changes added to the codebase and please add me to the project. You can use jbienz <at> gmail <dt> com.
Thanks!
https://www.dropbox.com/s/qn9xgog8bpmjvw9/x360eXntrc.zip?dl=0
I've been waiting to play GTA V on PC forever and I was especially excited to be able to play with my racing wheel and flight stick. As you probably know those hopes were dashed a few days ago when GTA came out supporting only Xinput and only one controller at that. So I decided to fix that.
Here's a summary of the fixes / changes I've made in the above linked codebase:
Fixed a bug in in Controller.cpp and Config.cpp where a badly formatted Trigger or Axis mappings could lead to a crash. In short it was caused by the line of code
u32 index = std::abs(m_mapping.Axis.id) - 1
which could lead to an unexpected value for index if id was set to zero. I added a test case for id 0 to skip the mapping and added a log warning in Config.cpp when an invalid mapping is seen.
Fixed a few bugs in Controller.cpp where the left trigger [0] deadzone was being used for the right trigger [1].
Fixed a bug in Controller.cpp and x360ce.App where trigger deadzones went by different names ("Left Trigger DZ" / "Right Trigger DZ" in dll and "LeftTriggerDeadzone" / "RightTriggerDeadzone" in app). I changed them both to use "Left Trigger DeadZone" and "Right Trigger DeadZone".
Fixed a bug in ControllerManager.cpp that caused PassThrough to get set to true by default. This was because the value variable was never explicitly initialized which left it to be a random number (considered true).
Added a new config option 'ForcesPassThrough' (0 Off, 1 On). This feature allows a controller to participate in mappings, deadzones, etc. but have its vibration data sent unaltered to the device. When this feature is enabled, the underlying device is also used when querying for Xinput capabilities so that the game knows the right vibration data to send.
Added new config option 'PassThroughIndex' (0 - 3). This is necessary since we load controllers by their InstanceGUID or ProductGUID but we also allow users to specify which player they want the controller to represent by supplying a UserIndex. What if more than one controller is an XInput device? We could get into a situation where physical controller 2 has been mapped to player 1 and vice versa. This setting allows us to make sure vibration data gets routed to the right physical device.
Added support for virtual controllers that don't represent a physical device! This was accomplished by changing most of the application to use an abstract ControllerBase class instead of the concrete Controller implementation. Also added one virtual implementation (see below).
Added support for virtual force feedback devices in a similar way by targeting most of the code at an abstract ForceFeedbackBase class. Also added one virtual implementation (see below).
Added support for combining multiple physical (or virtual) controllers into a single virtual controller! This was accomplished by creating ControllerCombiner which inherits from ControllerBase and has its own collection of child controllers. When input is read from ControllerCombiner it in turn reads data from all child controllers and intelligently combines them (e.g. if one controllers x axis is -200 and another controllers x axis is +100 the virtual x axis is -100).
Added support for combining multiple physical (or virtual) force feedback devices into one virtual force feedback device! This was accomplished with the ForceFeedbackCombiner class which functions similarly to the ControllerCombiner class. It simply forwards force data to all child devices that support force feedback and uses the first child in the collection used when the game queries for force feedback capabilities.
Added new config option 'Combined' (0 Off, 1 On). Specifies that a physical device will participate in combining.
Added new config option 'CombinedIndex' - (0-3). Specifies which player index a controller should get combined into. Multiple controllers can (and should) have the same CombinedIndex. If three controllers are set to 'CombinedIndex = 1', those three controllers will appear as a single controller for player 2.
Added new config option to the global section called 'CombineDisabled'. This can be used to temporarily disable combining for all controllers, which is handy since once controllers are combined they appear combined even in the x360ce front-end!
Note that other than the bug fix mentioned above I have NOT yet done any updates to the front-end. I will be working on that next. There is also a bug I haven't quite figured out yet in ForceFeedback.Shutdown. The call to SendForceFeedbackCommand(DISFFC_RESET) just hangs on application exit (but not when Restart is called). I could use some help figuring out what's going on here.
Well, that's it. Please let me know if you would like these changes added to the codebase and please add me to the project. You can use jbienz <at> gmail <dt> com.
Thanks!
