Do you have a plan to support Directinput controllers, because many HOTAS joysticks or 6DOF joysticks are directinput.
Viewing post in Project "Constraint" comments
I guess I should, although I need to get one first :) A little busy atm however, and first I badly want to do some tweaks to the particle system controller (almost finished in fact, will allow to fit things tighter by generating systems of a lower quality whenever the one requested does not fit into the buffer instead of skipping them altogether in this case - this is a neat touch for the lower-end GPUs where you would just limit the buffer without the need to set the effect quality that carefully).
Well, slowly getting it to run (hope to finish till this weekend) and got a few questions. At the moment I got the enumerator and the binder running, able to attach basically whatever is in the DI-standard joystick structure. The actual control, response curves etc are ready as well, and I'm mostly cleaning the stuff up. Unlike the XInput support from the current build, the DInput will not be multiplexed, but will be additive instead (as, opposed to how a gamepad can be used to control a real-life drone, and can be used as a complete control device here therefore, a flightstick may lack the ability to do several things unless in conjunction with a keyboard). And, FIY, yes - the selected device can be registered for future use, where it will start automatically (not really portable tho I guess, as stores the device's GUID) - the layouts are portable however, as are stored in separate tiny files named after each device.
Now, for the questions. So far I made it select a single device (for which it loads the control map as well, which you can edit in-game) and run like that, e.g. the keyboard is always available, mouse available whenever the axis pair meant for the yaw and pitch is not bound completely (for an obvious reason), and discrete, axial and POV controls, should they overlap, will be properly combined (yes, you will be able to bind a button as, say, strafe left, an axis for horizontal strafe and a POV switch to both strafe and ascend/descend all at the same time, and any combination of those will be correctly parsed). Should I leave it like that, or do I have to (won't really take that long I guess) make a control stack as well, allowing to assign and use a few DI devices at once (in this case you'd have to assign devices like #0...#something, where the layout of device #1 overrides the one of #0 in case of a direct overlap - say, if both are bound as "axis X", the one from #1 will be used, but binding one to strafe_x, and the other to strafe_left button is still combined - and so on)?
Also, about the deadzones. Should I rely on the DI ones, or have an own dead-zoning in software instead (atm I only tried the latter, just like with XI)?
i think second examplel would be better so users can make a profile of multiple controllers easily. I use an arcade stick for strafing,l rudder pedals for moving forward/backward and anything else for flight stick.
many controllers offer third party software to configure deadzone, but it would be better to configure the deadzone in the game.
Guess should be fine by now - the current build runs a stack of 4 devices (guess the biggest sane setup would be two sticks, pedals and... don't know, some switch pad, maybe? - can't think up anything else so 4 feels just right) added by "DI INIT #". The binding mechanism is mostly the same as before, all four are saved for the later starts using CONF.STORE. Yeah, yeah, overlap priority, dynamic disconnects and manual pause included :)