search

Ryochan7 / DS4Windows

Like those other ds4tools, but sexier
https://ryochan7.github.io/ds4windows-site/
GNU General Public License v3.0
7k stars 809 forks source link

UDP Connection from Unity #213

Closed dhturpin closed 6 years ago

dhturpin commented 6 years ago

Hello,

I can't seem to figure out what DS4Windows is expecting as a request from an external application for UDP data. I'm trying to create a project in Unity that will pull the gyro/accelerometer data from DS4Windows, but I can't seem to open a valid connection.

Is there any documentation on this? How does the DSU padtest successfully connect with DS4 Windows?

dhturpin commented 6 years ago

To be clear, my ability to poll for UDP data from the correct port doesn't appear to be the issue. DS4Windows is waiting for a very specifically formatted request -- I just need to know what information to send so that DS4Windows can start sending back controller data.

Ryochan7 commented 6 years ago

I have not really looked into the way that UDP is handled in the forked version of DS4Windows. Gyro calibration flaws and output performance issues stopped any chance of the changes getting incorporated into this version.

dhturpin commented 6 years ago

Really? The data looks fine in this padtest application, just based on the 3D visualization it renders.

I downloaded the source code to the fork with UDP, and hacked it so that it just spits out the UDP data indiscriminately. Now I'm able to get the data in Unity, so the next step is parsing it all. Hopefully the latency isn't too bad, and hopefully any jittering can be easily smoothed out.

dhturpin commented 6 years ago

One thing I would ultimately love to do is ditch the UDP idea entirely, and output directly to an unused joystick axis. Do you know if this is possible?

Ryochan7 commented 6 years ago

I would have to look at the source code again because I cannot remember all the issues I had with it. If I remember correctly, the calibration routine uses the wrong biases for some axes at least for Sony Wireless Adapter connections if not others. The clamping being done was not very helpful for gyro mouse mode when I want the full data range. The overall design required a lot of extra work and data construction that was not necessary and led to a significant increase in input lag that could easily be felt. One problem between the two versions is that AccelZ is mapped differently and the fork is actually correct. This version has it mapped backwards but fixing it would involve breaking all profiles using gyro controls.

I thought the main problem with outputting the data to a controller is that DirectInput has an 8 axis limit for controllers. The normal configuration would take up 6 axes already so there would be no way to map all the motion data available. Maybe the data could be split so two virtual controllers are created with one representing the base controller and the other being used to transmit the gyroscope and accelerometer values. On Linux, input devices (thinking the Wiimote specifically) get split in that type of fashion sometimes. ViGEm would probably be useful for that use case. A normal DirectInput DualShock 4 could be emulated for the first controller and a second DirectInput controller would be used solely for mapping motion data.

The only problem with that workaround is that I don't know how I would change DS4Windows to be able to distinguish a virtual DS4 from a real hardware DS4. I thought Wobbles mentioned in an update about InputMapper 1.7 being able to do that now so there has to be some value set by ViGEm to mark a controller as virtual; I can't test it myself since no build of InputMapper 1.7 has worked on my system.

dhturpin commented 6 years ago

Thanks for the heads up about the data. I succeeded last night in parsing all six axes in Unity; I'll keep investigating to see if the data is usable for my needs, and I'll report my findings here.

You're probably right about DInput being limited to 8 axes. The secondary "virtual" controller idea sounds compelling though!

czukowski commented 6 years ago

Just to add my 2 cents: doesn't it call for some kind of plugin framework that would allow for 3rd party dlls to subscribe to DS4Windows data? This way Ryochan7 wouldn't need to worry about potential performance issues and the plugin developers will get the opportunity to get the data they need, be it via UDP or any other means and in any format they want. Plugins could be enabled from controller profiles to further minimize their impact on performance by letting them work only when needed.