Better Joystick Support

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
One repository I just recently created to move the joystick code out of the "CPP Libraries" repository. But since the new code is still being written, I haven't posted anything there yet. And the Orbiter Joystick API is going to have the source code to my plugin once I get that working properly. I'm familiar only with Windows and this is my first attempt at a multi-platform library.
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
Looks like I'm going to have to skip that test application for now. For some reason, Visual Studio is creating a bad EXE file (it runs, but throws an error when creating the dialog box). The Joystick repository has gotten its first upload with the code I have written. Hope it works. Looks like the first test of the code is going to be in Orbiter. And of course Visual Studio is being uncooperative when it comes to building Orbiter.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,395
Reaction score
866
Points
203
Location
Langendernbach
Looks like I'm going to have to skip that test application for now. For some reason, Visual Studio is creating a bad EXE file (it runs, but throws an error when creating the dialog box). The Joystick repository has gotten its first upload with the code I have written. Hope it works. Looks like the first test of the code is going to be in Orbiter. And of course Visual Studio is being uncooperative when it comes to building Orbiter.

So, you understand now what I mean with "intended runtime environment".

Well, smart people learn from their mistakes. (Wise people learn from the mistakes of others)
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
So, you understand now what I mean with "intended runtime environment".

Well, smart people learn from their mistakes. (Wise people learn from the mistakes of others)
This time, it had nothing to do with my library. I tried to create a dialog box with a feature that the windows API didn't like. I removed those features from the dialog box and this is what I have now:
Joystick Viewer.png
Now I need to re-add my library and see if I get some results.
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
Nevermind. My library updated one list, then tried to get data from a completely different list.
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
Quick Update: A couple days ago, I discovered that my assumption that the Raw Input and Direct Input APIs would list the devices in the same order was wrong. So I'm currently working on a way to try to match the two. It's not going so well.

EDIT: Fixed! The library can now match devices between the Raw Input and Direct Input APIs. Now I need to verify that all of the inputs are reported correctly.
 
Last edited:

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
Well, it took longer than I expected, but I finally got this working properly. Granted, it'll crash when you hit the refresh button, but other than that, it works! By the way, this thing
creates 4 fake buttons if it finds a HAT switch, which will come in handy if you want to assign things to the HAT.
Joystick Viewer Working Output.png
 

JDat

Active member
Joined
Sep 6, 2010
Messages
107
Reaction score
62
Points
28
Keep going. Fix all bugs in testbench and then in library. Wrap stable library in addon, and test with orbiter. Only then you will find out what you miss from orbiter API, and only then there will be additional info to make decision is it worth to include your code/libraty into orbiter core.
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
The refresh feature is not an intended feature of my library. It's more of a hack that I'm using in my application. The refresh button causes the application to delete the instance of the input system and immediately create a new instance in its place.
 

JDat

Active member
Joined
Sep 6, 2010
Messages
107
Reaction score
62
Points
28
Can I get somewhere your binaries for tests under linux+wine?
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
Repository updated. I do not need any API functions in the window proc function. I managed to get input fetching working without using Raw Input or DirectInput (still going to use direct input to eventually implement FFB support). For some reason, the program crashed when I built the 32-bit binary. But the 64-bit binary works fine unless you hack-in a device list refresh like I did.

Repository Link:
 

JDat

Active member
Joined
Sep 6, 2010
Messages
107
Reaction score
62
Points
28
Now it's better. At least you managed to build Add-on and compiled .dll
Form now you are not double faced.

But you still on only on step 2 (?) in progress.
Finish step 7 and than you have chanse to get your code into Orbiter branch.

1) Write your joystick libary
1.5) Write test app if necessary.
2) Write addon wrapper for your library and test it with Orbiter 2016
3) Clone orbiter source code
4) Compile it
5) Test your addon with latest orbiter source
6) Integrate your library into orbiter
7) test all again
8) make pull request to main code
9) If bosses will like it, they will merge your pull request.

Ok, doesn't matter.

What is reason to not use MsgProc? Didn't dive deep regarding msgproc, just asking.

By the way, here my 6 line edited contribution for Open Source Orbiter. This must explain some of your code problems.
This fixed really small thing regarding MFD, but added some portability between 32 and 64 bit platforms.
https://github.com/orbitersim/orbiter/commit/8015ccc7c65186b7d019fc3788fdf4a6270c8425

Keep coding and good luck with your add-on.
 

JDat

Active member
Joined
Sep 6, 2010
Messages
107
Reaction score
62
Points
28
It is good practice to use common add-on naming system system for all add-ons.
In your case change:
C++:
char rootName[] = "TChapman500";
to
C++:
char rootName[] = "Input devices";

You will park your addon into "Input Devices" category like it was originally done by Martin.
Check TrackIR add-on as example.

Ok, while developing/debugging, you can use whatever you want, but when you publish/put into production, better to follow these (so far) undocumented rules.
 

TCR_500

Developer of Solar Lander
Joined
Mar 3, 2009
Messages
631
Reaction score
36
Points
28
Website
www.tchapman500.com
What is reason to not use MsgProc? Didn't dive deep regarding msgproc, just asking.
I don't need the MsgProc to retrieve input from the devices. But I will be using it to handle dialog controls. I'm thinking about creating a separate thread to get device input when the dialog is opened because of how Orbiter's message loop works (execution pauses when at launchpad until a message is received).
It is good practice to use common add-on naming system system for all add-ons.
In your case change:
C++:
char rootName[] = "TChapman500";
to
C++:
char rootName[] = "Input devices";

You will park your addon into "Input Devices" category like it was originally done by Martin.
Check TrackIR add-on as example.

Ok, while developing/debugging, you can use whatever you want, but when you publish/put into production, better to follow these (so far) undocumented rules.
I think something like
C++:
char rootName[] = "Joystick Controls";
would be a better name for the root item. Then
C++:
char globalName[] = "Assignments (Global)";
for my module, then
C++:
char vesselName[] = "[Vessel Name]";
for each addon that provides custom controls.
 

JDat

Active member
Joined
Sep 6, 2010
Messages
107
Reaction score
62
Points
28
TrackIR source code is your best friend.
Seems that TrackIR also don't have MsgProc, while MFD (MFDtemplate) code have MsgProc.

Before inventing something of following your own opinion, it is better to not break anything and follow common practice.

There are lot of bad examples then somebody write code on his own feeling and as result addons fail to work in next orbiter version or even worse: CTD.

One of such examples is FreeOrbitMFD (found on orbithangar), where addon code check for Orbiter 2006 version and patch memory directly in executable area just because lack of necessary API call from core on that version. Totally incompatible with anything but 2006.

That's a reason why it is recommended not to be cowboy, calm down, learn, think and do it right way to get code reliability on the same level or even better than code for AGC or AP-101S.

Addon is really good way to go instead of making orbiter core dependent on another library. Who don't need joystick support simply dsiable addon and go, instead of adding extra weight into core. From my perspective modularity is a way to go. Theoretically it is possible to write keyboard input addon for one reason it can remove direct input depencency from orbiter core.

And, remember, world is changed, linux become more popular than 10 or 15 years ago. Think about protability even if you have no idea how to do it. Imagine that next gen orbiter run on Raspberries Pi4 natively, who are controlling many projectors in big simulator.

Peace?

PS: I am already writing code on my x64 linux laptop, test it, fine tune, and then simply copy/paste necessary function into arduino and code works!!!
 

JDat

Active member
Joined
Sep 6, 2010
Messages
107
Reaction score
62
Points
28
Is there any progress with your joystick addon project?
 
Top