[Question] Enabling Extra axes, buttons and (possibly) POVs?

[joao678]

Since Xidi was designed around the xbox controller (or xinput in this case), and I was working around removing this limitation by allowing external programs to feed data to it (here)
And I've ran into some problems...

In ControllerTypes.h in the EButton enum there are 16 possible buttons but only 12 buttons can be possibly used in mappers one for each xbox button.
By modifying the number of buttons in both ControllerTypes.h

Xidi/Include/Xidi/Internal/ControllerTypes.h

Lines 91 to 112 in dd84968

	enum class EButton : uint8_t
	{
	B1,
	B2,
	B3,
	B4,
	B5,
	B6,
	B7,
	B8,
	B9,
	B10,
	B11,
	B12,
	B13,
	B14,
	B15,
	B16,
	/// Sentinel value, total number of enumerators
	Count
	};

And by adding extra dummy buttons in MapperParser.cpp

Xidi/Source/MapperParser.cpp

Lines 701 to 721 in dd84968

	static const std::map<std::wstring_view, unsigned int> kControllerElementStrings = {
	{L"StickLeftX", ELEMENT_MAP_INDEX_OF(stickLeftX)},
	{L"StickLeftY", ELEMENT_MAP_INDEX_OF(stickLeftY)},
	{L"StickRightX", ELEMENT_MAP_INDEX_OF(stickRightX)},
	{L"StickRightY", ELEMENT_MAP_INDEX_OF(stickRightY)},
	{L"DpadUp", ELEMENT_MAP_INDEX_OF(dpadUp)},
	{L"DpadDown", ELEMENT_MAP_INDEX_OF(dpadDown)},
	{L"DpadLeft", ELEMENT_MAP_INDEX_OF(dpadLeft)},
	{L"DpadRight", ELEMENT_MAP_INDEX_OF(dpadRight)},
	{L"TriggerLT", ELEMENT_MAP_INDEX_OF(triggerLT)},
	{L"TriggerRT", ELEMENT_MAP_INDEX_OF(triggerRT)},
	{L"ButtonA", ELEMENT_MAP_INDEX_OF(buttonA)},
	{L"ButtonB", ELEMENT_MAP_INDEX_OF(buttonB)},
	{L"ButtonX", ELEMENT_MAP_INDEX_OF(buttonX)},
	{L"ButtonY", ELEMENT_MAP_INDEX_OF(buttonY)},
	{L"ButtonLB", ELEMENT_MAP_INDEX_OF(buttonLB)},
	{L"ButtonRB", ELEMENT_MAP_INDEX_OF(buttonRB)},
	{L"ButtonBack", ELEMENT_MAP_INDEX_OF(buttonBack)},
	{L"ButtonStart", ELEMENT_MAP_INDEX_OF(buttonStart)},
	{L"ButtonLS", ELEMENT_MAP_INDEX_OF(buttonLS)},
	{L"ButtonRS", ELEMENT_MAP_INDEX_OF(buttonRS)}};

I was able to get up to 31 buttons to work using custom mappers defined in xidi.ini, trying to add more buttons results in this assertion error

Xidi/Include/Xidi/Internal/ControllerTypes.h

Lines 344 to 346 in dd84968

	static_assert(
	static_cast<uint8_t>(EButton::Count) <= 0b11111,
	"Number of buttons does not fit into 5 bits.");

If those assertions are commented out, none of the buttons work. Is there any possible way to change this?
Same happens for axes too. Other than the usual X,Y,Z,RotX,RotY,RotZ, trying to add Slider 0 and Slider 1 also results in a assertion error.

One more thing, is the possibility to add more than one POV per virtual controller too difficult to implement? I didn't even poke around to find something related to this, is just something I was thinking because DirecInput supports it.

Does something in DataFormat.cpp need to change to acoomodate these changes?

[samuelgr]

Those assertions are related to a data structure size optimization I implemented so that all of the related structures could be passed around by value very efficiently. It's a low-level optimization that most likely makes no difference whatsoever for your use case.

In files like ControllerTypes.h you will see some structures defined using bit-fields, like this:

Xidi/Include/Xidi/Internal/ControllerTypes.h

Lines 204 to 212 in dd84968

	struct
	{
	/// Number of axes in the virtual controller, also the number of elements of the axis type
	/// array that are valid.
	uint8_t numAxes : 3;
	/// Number of buttons present in the virtual controller.
	uint8_t numButtons : 5;
	};

At the very end of each declaration, you will see a colon and then a number. It should be safe to remove the colon and the number, so the above struct would look like this instead:

      struct
      {
        /// Number of axes in the virtual controller, also the number of elements of the axis type
        /// array that are valid.
        uint8_t numAxes;

        /// Number of buttons present in the virtual controller.
        uint8_t numButtons;
      };

That makes it safe to ignore the assertions about not fitting into some number of bits. But you'll need to do that everywhere. This can result in some assertions related to data structure size constraint violations, but those are safe to comment out after you've made this change.

As for multiple POVs, yes, that should also be possible. You would need to modify some data structures like SState which currently assume there is only a single POV along with the various functions that read from and write to those data structures.