Better Joystick Support

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
A while ago, I made a joystick library based on a codepoject article I found to enable me to easily implement joystick support on any project I'm working on (Windows only). Here's the github for this library (includes 64-bit static library for Windows applications).

[UPDATE]
The repository for the plugin that I'm working on is here:
Here's the repository for the joystick viewer application I wrote to test-out my library (64-bit): [/UPDATE]

It's probably not required to improve joystick support since DirectInput8 can be used to achieve the same thing. But here's what I'm thinking could be done regardless of the API used:

  • Enable controls to be assigned to joystick buttons and/or axis depending on the type of control.
  • Enable input processors to modify axis input values before sending them to the control that is using said input.
  • Preserve assignments even when the controller is unplugged.
  • Enable an API that can be used by a vessel plugin to create vessel-specific controls.
  • Include a set of generic control axis that can be applied to most vessels, including:
    • Pitch
    • Pitch Trim
    • Roll
    • Yaw
    • X, Y, and Z Translation (independent of Pitch, Roll, and Yaw controls)
    • Throttle (for all and independent engines).
    • Retro Throttle (for all and independent engines).
    • Hover Throttle
    • Left and Right Wheel Brakes
    • Spoilers
    • Nosewheel Steering

Here's the road map to updating those two repositories:

"Joystick" Repository First Update Plans
  • (75%) The input system (Windows only at first) correctly identifies whether to use XInput or DirectInput and creates the appropriate interface for the device.
  • (75%) Correctly account for when more than 4 XInput devices are connected to the system and improvise a solution (I don't have enough XInput devices to test this).
  • (75%) Device interface selected correctly reports axis and hat positions, and button states.
  • (75%) Create platform-independent instances of Joystick class which uses the correct interface (this class can be extended to implement device-specific functions).
  • (75%) Create platform-independent initialization/destruction functions which use platform-specific preprocessor directives to create/destroy the correct platform-specific input system.
"Orbiter Joystick API" Repository First Update
  • (75%) Have a fully functioning Joystick library that I can integrate into this plugin.
  • (0%) Have a control assignment system (like that of Solar Lander) that will (at first) hardcode the equivalent of the core's joystick controls.
 
Last edited:

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
Sorry about the bump, but I feel this is relevant. I'm currently refactoring the library linked in the above post to accommodate different APIs. The intent is to eventually use it in Orbiter without having to hack the message loop somehow. For now, I just intend to make this a plugin which will require the default Joystick handling to be disabled. Eventually, I'll want to find some way to integrate this into the Orbiter core. I fully intend for this to be cross-platform.

Current plans for this library:
  1. Have a single, platform-neutral interface.
  2. Have each API in the library derive from the platform-neutral interface. These APIs are not platform-neutral.
  3. Have a single base joystick class that has basic functionality (including force feedback?)
  4. Allow joystick-specific extensions to the base class (eg: for the X52, G29 functions).
  5. Handle device disconnection and reconnection (including change in handle pointer).
  6. For Windows, automatically determine the correct API to use for the device.
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
Hmm. So, XInput creates a fake HID for any XInput device that is plugged into it. And DirectInput picks up HIDs. This job just got a whole lot easier. Too bad Windows' XInput drivers combine the left and right triggers into a single axis. Well, now I know that all I need to do to find an XInput device is to look at the HID report descriptor that the RAWINPUT API gives and then enable XInput. This kind of makes my job a whole lot easier. That is unless somebody decides to build a gamepad designed specifically to trick my library into thinking that it's an XInput gamepad.
 

JDat

Active member
Joined
Sep 6, 2010
Messages
107
Reaction score
62
Points
28
Calm down, cowboy!
Why you want to add it into Orbiter core instead of building input addon for Orbiter?
Less thing into core less problems problems with core.
As I hear from Martin, default joystick plugin in future will be moved from core to separate addon.
The same is true for MFDs, and maybe keyboard input.
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
Well, the main reason is to ensure that my library can process input from the devices before forwarding the results to the rest of the simulation (eg: apply user-defined sensitivity and null zone settings). But also to guarantee that if I have to do processing in the message proc, then I can (though that's more or less a Windows-specific issue). Orbiter's API isn't set up for that.
 

DarkWanderer

Active member
Orbiter Contributor
Donator
Joined
Apr 27, 2008
Messages
212
Reaction score
51
Points
43
Location
Moscow
Do you have specific suggestions on what can be changed in Orbiter core API to achieve better functionality?
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
I have two suggestions:
  1. (Probably Windows-specific) Add an API callback that is called by the message proc function (as well as one for configuring which messages are handled by the plugin).
  2. Add an API callback function that is called after DispatchMessage (or platform-equivalent) but before the PreStep function specifically for processing input device states.
 

JDat

Active member
Joined
Sep 6, 2010
Messages
107
Reaction score
62
Points
28
How critical is to miss one keypress/joystick input for one main loop circle/frame?

These API calls are interesting and looks like can be used for alternative keyboard/joystick input addon:
vessel.IncThrusterGroupLevel_SingleStep
vessel.SetControlSurfceLevel
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
Ideally, PeekMessage() would be in a nested loop so that we process all messages that have accumulated since the last frame. I think that the worst that will happen if a message is missed is a little bit of input lag, because that message is still in the message queue, but not processed that frame. But if I must use Windows messages for devices that use the Raw Input API, then I must have an API function within the message handling function. Otherwise, you might as well not have that device connected.

By the way, the implementation can be as simple as 2 API functions which are only called when a Raw Input message is posted (1 API function per message type).
 
Last edited:

JDat

Active member
Joined
Sep 6, 2010
Messages
107
Reaction score
62
Points
28
Less words, more code!
Write great joystick addon for Orbiter. If it will be really good, than you get chance to merge it into Orbiter code.
It is really stupid to ask promises to include code into Orbiter before code is ready.
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
You're talking as if I'm not writing any code at all. I have both the XInput and DirectInput APIs working in standalone test applications and am working on integrating both into my library. Also, I have not asked for it to be included into the Orbiter core. I simply stated that integration into the core is a goal.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,395
Reaction score
866
Points
203
Location
Langendernbach
You're talking as if I'm not writing any code at all. I have both the XInput and DirectInput APIs working in standalone test applications and am working on integrating both into my library. Also, I have not asked for it to be included into the Orbiter core. I simply stated that integration into the core is a goal.

Standalone isn't even a prototype for this "product". Make a Orbiter plugin of it, test how it fares, which problems will appear. You will NEVER find out more about this by playing with standalone applications.
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
Standalone isn't even a prototype for this "product". Make a Orbiter plugin of it, test how it fares, which problems will appear. You will NEVER find out more about this by playing with standalone applications.
The purpose of the standalone is to test the library as I develop it to make sure what I have works as intended. The Orbiter plugin will come in after I've verified that the library works as intended.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,395
Reaction score
866
Points
203
Location
Langendernbach
The purpose of the standalone is to test the library as I develop it to make sure what I have works as intended. The Orbiter plugin will come in after I've verified that the library works as intended.

And what if it doesn't work in the intended runtime environment?
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
And what if it doesn't work in the intended runtime environment?
There is no intended runtime environment for this library. It's going to replace the library linked in the first post. Once I verify that the library is working (at least on Windows), I'll integrate it into an Orbiter plugin. If my plugin doesn't work as intended, I'll debug and fix it until it does.
 

DarkWanderer

Active member
Orbiter Contributor
Donator
Joined
Apr 27, 2008
Messages
212
Reaction score
51
Points
43
Location
Moscow
It's good to have wrappers for DirectInput/XInput, but they don't add much value by themselves. There's a ton of wrapper libraries already - most known one is SDL.

Real value and work lie in integrating it with Orbiter properly - rewriting APIs, creating UI/config files, ensuring addon support etc. Solving that - and raising a PR with ready-to-use feature - is the way to go
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
Real value and work lie in integrating it with Orbiter properly - rewriting APIs, creating UI/config files, ensuring addon support etc. Solving that - and raising a PR with ready-to-use feature - is the way to go
I intend to do exactly that (minus rewriting APIs).
 

DarkWanderer

Active member
Orbiter Contributor
Donator
Joined
Apr 27, 2008
Messages
212
Reaction score
51
Points
43
Location
Moscow
I'm sure a lot of people will look forward to it (especially if it comes with ability for centralized configuration for addons)
 
Last edited:

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
My only concern is that, as an Orbiter plugin, I'm going to have to provide a .LIB file to allow other plugins to interface with my plugin in order to implement vessel-specific controls. Can't find anything in the Orbiter API to get a previously-loaded plugin.
 

JDat

Active member
Joined
Sep 6, 2010
Messages
107
Reaction score
62
Points
28
Why you think about .LIB? Look on TrackIR and Rcontrol sources. If you need additional API from core, then... write plugin without that API, show proof of concept and ask to get missing APis. I hate if anything it tied to windoze, becaue I am pinguin guy and be really hppy if your addon be multiplatform (support linux directly or via wine library).

By the way: I'm watching you on github... So far you have only readme.MD and have two emty repositories when tried to implement your own joystick library into orbiter core...

1de80f0cdc4a454937e9a4251b6f1aa1.png

Anyway! Keep going! We all need good joystick library for Orbiter!
 
Top