Add basic joy-con support #1098
Conversation
|
TLDR: These changes make the app more sluggish so I cannot accept this pull request as is. It is interesting and hopefully you will continue working on JoyCon use for PC. My main stance on different controller support in DS4Windows is that the code is not really structured for devices that are not a DS4 style controller. There are a lot of bits that deal with attributes specific to the DS4 hardware beyond just inside the DS4 input reader. Being able to map other controllers would be a "nice to have" feature but not essential. Other projects can fill in some gaps; for example, I have pretty much adopted the Touchmote project (Wiimote mapper) and I have been adding to it for the past couple of months. I had an initial idea for a future mapper that could be useful for mapping different controllers. The mapper would be much more flexible than DS4Windows currently allows and supporting multiple controller types would be a desired feature. Binding functions (taps, holds, etc.), action set support, various output modes for input group (like Gyro works now but for sticks), and more would be needed to accomplish what I want. The main goal is to be able to play Elder Scrolls 4: Oblivion again. For the way I want to play, DS4Windows is not up to the task. I got sidetracked with learning WPF and updating DS4Windows to use that stack so the test mapper code has not been touched since August. I would be using the same software stack in a future mapper so updating DS4Windows to use that stack was a good learning exercise. https://github.com/Ryochan7/mappingtest As for coding style, any new device input reader should be its own class which would probably have to inherit from DS4Device. That class might have to be changed a bit to define a better interface that a different class could override. |
|
Thanks for the response, and that all makes sense. There was definitely not an obvious way to add a new type of controller, because as you say it's extremely DS4 specific. If you get back to working on the mapping, feel free to use this code for a Joy-Con class. I would like to understand what you mean by "more sluggish" though. Are you specifically referring to the use of variables instead of the |
|
I'll have to look at your more recent changes. As for the responsiveness issue, those types of problems have plagued me since working on DS4Windows. There are several instances when I had to refactor changes many times to get performance in line with what I want; one more recent example was having to implement the Square Stick routine about 3 times before it finally got included in the project. I am not sure which part of the changes would be causing the problem as a profiler cannot pick up which routine is directly causing the problem; I would have to dissect the code to find the problem. It seems to usually be more an issue with interaction with the .NET Runtime rather than anything directly wrong with the code itself. I have had times when even the structure of a simple if statement can affect overall application performance even if that portion of code is never executed. That has been far less the case with the 2.x code base but I have run into the issue a couple of times since DS4Windows 2.0 was released. |
|
I finally took the time to update the mappingtest project. It is mainly just an update that includes the ViGEm client libraries and some changes from DS4Windows 2.0. It is pretty bad that I have forgotten some of the ideas I was considering; not sure what the purpose of the IntermediateState class was supposed to be. One big holdup with the previous API proposal was how to implement an Action Layer style feature. Set merging will probably be done to allow overriding output controls for an Action Set. No profile that I have ever used in Steam Input has taken advantage of Action Layers so I am not sure when it would be better to use an Action Layer over a new Action Set. ExistentialEgg videos about the Steam Controller would be my main reference for how Action Layers are used. |
|
Hello! I'm glad to see some recent activity on this project! Forgive me, I'm brand new to any kind of project like this, but I was wondering how difficult would it be to add support for specific third-party PS4/DS4 controllers to the current build (it seemed like here would be a good place to chime in, given Ryochan's recent post). My digging led me to HidDevices.cs (v1.4.52) where it looks like two lines are called: int[] pid = { 0xBA0, 0x5C4, 0x09CC }; Basically, I gleaned from the variable names and later confirmed by comparing to v1.4.5 ( the update from which added support to the new DS4) that here is where one would begin to add support for new devices, as the change to add 0x09CC to pid was was the one that added to the new DS4 controller. Looking further still and googling vendor and product IDs, I saw that the 5C4 and BA0 were the product IDs for the original DS4 and USB PC adapter, respectively. I was interested in there someday being support added for the HORI Mini Wireless PS4 controller. Since it was officially licenced by Sony ,I thought it would seamlessly work with DS4Windows. When I arrived at my initial dead-end, I took to the internet to see what was up. So now I am not immediately sure how best to try to add support starting from here since it is a different vendor ID entirely (0x0F0D), so the product ID (0x00EE) couldn't easily just be tacked onto the values in pid like if it were another Sony pad. I also don't know what else, if anything, would be necessary to change, not least since Hori took an unusual approach to the touchbar with this model. (although inputs are meant to simulate or recapitulate touches so maybe it's not necessary to address). I'd be glad in hearing thoughts about if this might be possible! Thanks so much! I actually created a GitHub account just to contribute here. |
|
@kenechoko Please don't hijack a discussion thread. Instead you should open a new issue if the question is not already answered or not related to existing issues. Anyway. Based on the story you told it looks like you are looking at an old Jay2Kings version of DS4Windows app. It is no longer supported. This github site is about newer (still supported) Ryochan7 DS4Windows version. This newer version already supports HORI PS4 Mini gamepad (VID/PID 0F0D/00EE). See the following page for links to download the newer Ryochan7 version of DS4Windows app and ViGem device driver. However, if you decide to move on to this newer version then you have to uninstall the old ScpvBus device driver toolkit because it is no longer supported and may cause all sort of problems especially if using bluetooth connection method. |
|
It is too bad that I have not been able to work on the prototype mapping project more. Still finding plenty to do with DS4Windows and just improving the experience using the DS4. Having some more abstract way to add different device readers would be very useful especially when new hardware like the DS5 controller comes out (2021?). |
|
So sorry for the mistake. I saw an opportunity to contribute to an ongoing discussion. But I understand, and thank you for your help. I've have a new update/question/request regarding this, but I'll begin a new thread. Thank you! |
|
I almost contemplated getting Joy-Cons after seeing the JoyShockMapper video showing Crysis being played with split Joy-Cons. It would be an interesting replacement for my old Wiimote Motion Plus + Nunchuck configuration. It is better that I did not end up buying them though. I haven't gotten much use of the Switch Pro controller still; I don't like any of the options for using it on PC. I ended up starting to work on a mapper for the Switch Pro controller but I only got as far as basic XInput emulation. It took a long time to get the controller handshake and mode change done right; even the popular BetterJoyForCemu program has problems connecting to it at times. I have not tried to get gyro support working with the Switch Pro controller in any form. Play Crysis with Joy-Cons/DS4 (and how Remastered SHOULD play on Switch and PS4) Switch Pro controller custom mapper experiment |
That's exactly why I created this fork -- for me it makes the JoyCons totally useful to integrate them with my other controllers. I'm not sure what the Pro controller would provide over any other standard controller for the PC -- I did the JoyCons because they are small and travel well. Nice to see your code for the Pro, and still interested to see your mapper stuff come to fruition. |
|
The Switch Pro controller is a solid choice for the most part. My main gripe is that the poll rate of the controller is much slower than the DS4. The poll rate is locked at ~16 ms when using BT and ~8 ms when connected via USB. A lot of people have complained that I have DS4Windows set up to use a ~4 ms poll rate by default when connected via BT rather than pushing the fastest poll rate possible (~1.25 ms I believe). The Switch Pro controller feels good in my hands and I like the asymmetric stick layout rather than the stick layout of the DS4. |
|
I will probably consider getting a pair of JoyCons at some point. My use case for the JoyCons would be much more limited than the Switch Pro controller. Playing FPS games like what is shown in the Crysis video would be my desired use for the JoyCons. No matter what, it would be better to figure out how to work with the Switch Pro controller fully first. I am going to start working on utilizing the gyro in the Switch Pro controller. |
|
@jdanders I finally bought a pair of Joy-Cons so I will have a direct use case for your test build. I will give it a try later. Do you have any plans on making an updated build based on a more recent DS4Windows release? |
|
Just checked the Releases section of your fork. I will download the version 2.1.2 Update. https://github.com/jdanders/DS4JoyConWindows/releases/tag/v2.1.2-joycon |
|
Not sure why but I get frequent lag issues with my Joy-Con R. I can use my Joy-Con L perfectly fine and it is a decent controller for playing Streets of Rage 4. It is too bad that there is no way to attempt to merge the two Joy-Con controllers into one XInput output controller with the way DS4Windows is set up. That limits the use cases for the Joy-Cons quite a bit. Also, I cannot try mixed input with the two Joy-Cons. Attempting to use XInput controls for one Joy-Con and Gyro Mouse for the other Joy-Con would be my desired use for the Joy-Cons. |
|
Yeah, as I mentioned in the OP I use xjoy when I want combined operation. I have times when the controller stops updating for less than a second, I'm not sure if that's what you're calling lag, but I haven't had a chance to look into it at all. I've had it happen with either controller. So far I've only really used them for Towerfall which is awesome (except for when they lag 😡). I got to the point of trying to figure out how to optionally combine the two controllers into one that I decided I was in over my head. It would require independently handing Bluetooth devices and XInput controllers. Xjoy creates the single XInput controller after individually initializing the two Bluetooth controllers. |
|
I have tried XJoy and found it very laggy. BetterJoy seems to be a better option for mapping both Joy-Cons to one XInput controller. Even when only using one Joy-Con, BetterJoy still seems a bit slower than your work on the DS4Windows Joy-Con build. I also tried JoyShockMapper but I ran into problems; JoyShockMapper works okay with the DS4. My main use case for the Joy-Cons would be to play games with mixed XInput + Mouse controls. Joy-Con L would be mapped entirely to XInput controls. Joy-Con R would primarily have its gyro mapped to Gyro Mouse with the normal buttons being mapped to XInput. Here is a video showing an example of what type of control scheme I would want. Play Crysis with Joy-Cons/DS4 (and how Remastered SHOULD play on Switch and PS4) It looks like I will have to work out what I can do with the Joy-Cons like I did with the Switch Pro controller. It took a long time to decipher the information that was already out there especially once I started to utilize the gyro. The Switch Pro controller is actually a decent controller and I have used it to play several games. Bulletstorm and Halo 2 are two games I have played while using Gyro controls with the Switch Pro. Halo 2 was a special case as I had to re-create Gyro Mouse Joystick. I will probably start focusing on just mapping one Joy-Con. The main code base will be my Switch Pro mapper project. |
|
Gotten to the point where I can read input reports now. I don't know why but my Joy-Con L seems to work perfectly fine. My Joy-Con R seems to run into frequent latency issues with the latency bouncing around 30 ms at times with an odd outlier of 45 ms sometimes. |
|
I don't know how far I will get but here is the repo with my current experiments. So far, I have gotten either JoyCon to act as a partial Xbox 360 controller. |
|
That looks super clean, nicely done! I notice your not doing anything with stick calibration. If you get around to that, you may find my calibration tool helpful, assuming you don't actually own a Switch. |
|
I don't actively use the stick calibration data with the Switch Pro mapper either. The program does pull the factory calibration data from the device but the stick bounds are hard coded. The bounds chosen are mainly based on testing in the HTML5 Gamepad Tester but some of it is based on the calibration data pulled from my device. I just recently changed both stick bounds and they behave much better for me now and properly map to the full Xbox 360 stick range. It can be very hard, or even not possible sometimes, to reach the stick axes bounds specified in the calibration data from the device. Both BetterJoy and XJoy cannot map to the full range of the Xbox 360 sticks. Rather than interpolating based exclusively on that data, it would probably be better to clamp the axes using values slightly lower than what is read from the calibration data. It does not help either that the axes on the JoyCon sticks are asymmetrical. I have gotten to the point where I can use both JoyCon controllers as a single output Xbox 360 controller; it is listed as Joined mode in my code. Gyro work has started but it does not feel as good as with the Switch Pro controller. Gyro seems to work better when the two JoyCons are attached to the Charging Grip rather than trying to use a split JoyCon config. I will keep working on it. |
|
Some more Gyro progress has been made. Had to take some extra precautions in the code to compensate for sporadic report issues. At this point, my split JoyCon config feels better to me than in JSM. Now that Halo 3 has been released for the Master Chief Collection, I hope to make that the first game I play through with the JoyCons. I still don't know if I would consider the purchase of the JoyCons justified even if I end up making a config that I like for Halo 3. I would say that I have only recently gotten my money's worth with the Switch Pro controller. |
|
I am considering committing these changes to the project. However, it would have to be a modified version with some of the code abstracted into a separate class. Along with this, I would want to add Switch Pro controller support since most of the code would be similar. DS4Device would serve as the base class that the other device readers would utilize. I will pull these changes and experiment with some modifications. |
|
Sounds good. This branch is only prototype code and should not be used as is, especially since you've done so much to understand the controllers. Let me know if you need any help with anything. |
|
Taking another stab at this problem. I took the path of least resistance so the end result is not really how I would probably have initially designed it. I have a working test version that supports the Switch Pro controller and supports some of the extra functionality of the controller like Gyro and Rumble. I will push a test branch in a few minutes. For now, only a Switch Pro controller connected via Bluetooth works. My old Switch Pro code used to work with USB connections but it does not work currently for some unknown reason. I will have to look into that. I am not sure about making a JoyCon reader class though. Once the JoyCon gyro is engaged, the poll rate is so spastic that it makes the controller almost useless. I don't experience problems when the JoyCon controllers are plugged into the Charging Grip but that defeats my initial reason for using the JoyCon controllers. Buying them was a waste for the most part. |
|
The Switch Pro branch has been merged into the jay branch. Switch Pro controller support is slated for the next release of DS4Windows. |
|
That's pretty sweet, good to know! I'll take a look if I can get some time and see about working JoyCon into your current structure. Or maybe I'll just stick with what I have... in any case that's a great addition to a great tool! |
|
I have taken some time to charge and play with the JoyCons for a bit. I think I have discovered the biggest problem that I was experiencing. The BT adapters in the JoyCons must be really weak as it looks like my TV tray was the big culprit causing interference. Funny enough, I unintentionally avoided that issue when I recorded my JoyCon test videos. When using the Charging Grip, I would normally have my hands positioned up and away from the tray enough to not cause issues. I might try to add JoyCon support although it would be fairly limited. It would probably be more useful for playing KB+M driven games rather than games using XInput. |
|
A basic JoyCon reader has been made. Most of the code comes from the current SwitchProDevice class. There is still some code to merge from your fork especially the stick rotation code. I am going to initially stick with the assumption that a single JoyCon will be used being held on its side. Later on, I might test out the current LS and RS rotation code and make people use that setting if needed. Maybe a small ComboBox could be added to the Profile Editor with preset rotation angles for cases like this. |
|
It's a thing of beauty! Much better than my hacks on this branch. Feel free to close this merge request when you'd like. |
|
I would say JoyCon support is pretty much complete with the changes from commit b526492. Some extra options got added to the preset bindings menu to include Rotate items. That should make assigning bindings for a single JoyCon easier. Except for the lack of a real DPad, a single JoyCon is a decent controller for playing Streets of Rage 4. The addition of JoyCon support in DS4Windows 2.1.17 was a little premature but getting a build released with DualSense support was the big priority for that release. If it weren't for that then I would have waited to release a new build of DS4Windows until the preset options were added. I will close this ticket once DS4Windows 2.1.18 is released. That will probably be in the next couple of days. Now that rumble over BT with the DualSense is pretty much figured out, getting a new build with that feature included will be a high priority task. |
|
Version 2.1.18 is now out and Rotate preset options have been added to the Preset Menu. JoyCon integration is considered complete at this point. Thank you for the original concept and code. It was helpful for deciphering the JoyCon more and getting an initial path for integration going. |
For those wanting to use this, I'll put a release in my repo. If you want combined support right now, try XJoy
I'm not sure if this is somewhere you want to go with this project, but I got a pair of Joy-Cons for my PC and thought they'd be a lot easier to use if DS4Windows supported them too. If this doesn't fit, maybe I'll rename my repo to DS4JoyConWindows or something amazingly catchy like that and try to keep it in sync.
This commit adds basic support for Nintendo's Joy-Cons.
Supported:
To-Do:
As for code quality, please review carefully before accepting the pull. This is my first experience with Windows and C# programming, so there my be some subtleties I'm missing that will bite me later. I tried to keep within the project framework and style, but maybe it would be more appropriate to do a separate class or something for a separate controller.
The most dramatic change I made to existing code (besides adding
if joyconeverywhere) was the removal of some the REPORT_LENGTH size constants that did not apply for the Joy-Con. Also, I had to make some changes to the project file itself. I used VS 2019, so maybe that is why.Finally, huge thanks for the geniuses at https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering/
I also pulled heavily from XJoy and JoyCon Driver