d3xMachina
commented
4 months ago You can keep the Joycons separated by setting the DoNotRejoinJoycons option. They will behave independently and send their motion to their own slot on the motion server.
The fork you mention is about triggering inputs on different motions, It doesn't change how the gyro is handled otherwise. There is a change that force the mapping of the gyro to always be on the right Joycon when enabled (the "GyroToJoyOrMouse" config option), but it's the same as setting it to "joy_right" here. So if you're talking about the triggering of inputs on motions, that's not something I'm willing to work on because I just have no interest in it. (there is the shake motion that's already implemented at least)
As for your last point I think there is a confusion. SDL allows an application/game/emulator to communicate easily with a controller. (they support a lot of controllers natively and it now include Nintendo controllers). The main purpose of BetterJoy is to interpret the datas sent by Nintendo Switch controllers which are non standard and make them appear as a standard virtual controller (XBOX360 or PS4 controller) so that most games can use them.
So when you see in your application "SDL/0/Nintendo switch joycon L/R", it means that's the application is getting all the inputs from SDL and not BetterJoy and when you see "SDL/0/xbox 360 Controller" it uses the virtual controller made by BetterJoy.
The XInput API (used for the XBOX360 controller) doesn't support motions so I can't make a XBOX360 virtual controller with motions, that's why we use the motion server (DSU). As for the PS4 virtual controller, it could support motion but is not implemented here. However there is a fork of my project that implemented it here (I haven't tested it, you need to put "passthru" in the config option "GyroToJoyOrMouseOrPassthru" and enable "ShowAsDS4" to have the PS4 virtual controller). If you use the last commit of their fork, I would advise you to remove the following lines in Joycon.cs (it's probably a quick fix they made for a bug with the sticks that is now fixed) :
output.ThumbLeftY = CastStickValueByte((isLeft ? 1 : -1) * (float)(stick[0] / 2.075));
output.ThumbLeftX = CastStickValueByte((isLeft ? 1 : -1) * (float)(stick[1] / 2.075));
a few weeks ago I came across this fork (since the original gave me a lot of problems) and I find it really well done, however I have never loved the concept of having a single value of the gyroscope (in all its movements) and accelerometer . This makes sense if I have a single controller like the pro controller, but it starts to be really limiting if you use the joycon pair.
And so I said to myself, why has no one separated them to be able to use them better as input (see for example dolphin, where it would have a notable advantage in terms of emulation of the Wii remote and nunchuck). searching around I came across another miracle, also a fork of the original project: https://github.com/StandieNL/BetterJoyMotion . It solves this problem/improvement of the joycons: the sensors are separated and they also work as a single value, however it is not very different from the original project (as well as its bugs and the way in which it is not really recognized in some emulators) and the changes made seem few from the commits (other than deciding which image to use in the readme [I don't want to belittle or appear offensive, but I find it quite funny]).
The question is, would it be possible to take this functionality and implement it in this project?
Also if it is implemented, would it be possible to make it work using SDL rather than DSU? for many reasons right now the only one that has always worked perfectly for me has been to always use SDL when choosing controllers + motion sensors (right now using your version 8.4.2 it is recognized as "SDL/0/xbox 360 Controller" where the sensors do not work, instead in its fork it is recognized as "SDL/0/Nintendo switch joycon L/R" with motion sensors