[REQUEST] Any possibility to get Gyro working?

[SiTWulf]

Hi.

We have a Working DS4 Gamepad thanks to your incredible tool, but we cant use the Gyro option of our DS4 in any Game/Emulator. You only can set Gyro as Keyboard/Joystick buttons, not real Gyro. You can test using this tool: https://files.sshnuke.net/PadTest_1011.zip

Example how to work: https://www.youtube.com/watch?v=R0JqXyHQnv0

All Videos on YouTube only recommend to overwrite your updated version with the Old Patched one from rajkosto.

Please RyoChan... we really need a solution for this... maybe a Toggle Option to use/not use Gyro (With Gyro you get Input Lag) and without the option you not get any Input Lag.

Refereed YouTube Videos:

BDsO Tutorial: https://www.youtube.com/watch?v=2hMF245bXww

English: https://www.youtube.com/watch?v=BmWwHb-bTEo English2: https://www.youtube.com/watch?v=1iwK4q01Ffw Spanish: https://www.youtube.com/watch?v=cVvwtNIKEkA Spanish2: https://www.youtube.com/watch?v=kK3uv2ogeI4 Italian SCPToolkit: https://www.youtube.com/watch?v=L3NVRwuCNec

One simply solution maybe can be: Assing Macro to TiltUp = Right Click+Mouse Up Assing Macro to TitDown = Right Click+Mouse Down But you cant Macro Mouse Up, Mouse Down, Mouse Left or Mouse Right, only Mouse Buttons, And unable to get Gyro Acceleration.

[Ryochan7]

The biggest problem with that fork stems from its design. Simply switching Gyro modes would not be enough to work around the problems presented by the inclusion of the code and also from the .NET Runtime.

At this point, it would be up to somebody else to try to get that Gyro system updated and to address some of the original problems that I had with it. I do not have a real use for it and there are other problems that I would like to address instead. Honestly, a fair amount of the necessary work outside of the networking portion has probably been taken care of in this branch already. Some extra data might need to be exposed in the SixAxis class in order for it to conform to the coordinate system used in that version; the only difference that I can remember is that AccelZ is still flipped in this version to avoid breaking Gyro controls in profiles.

It would have been helpful if the fork would have been updated to fit more in line with functionality that had been added in this version. Instead, routines were removed and replaced mostly unnecessarily in order to avoid making a proper updated patch.

[Ryochan7]

The latest branch in the fork does utilize many of the changes made here. However, it doesn't look like it worked out. That branch is based on version 1.4.97. There is no binary release to test.

https://github.com/rajkosto/DS4Windows/tree/ryo_udpserver

[Ryochan7]

Turns out I had downloaded the binary release while it was still available. PadTest does seem to go out of sync with the orientation of the controller fairly quickly with that version. As shown in PadTest, AccelZ is flipped compared to what is used by DS4Windows. Flipping AccelZ in DS4Windows seems to make PadTest work out better and the orientation stays in sync for much longer. Some more extensive testing would have to be done to actually compare the output values of the two calibration routines. The only behavior that I have ever tested is Gyro Mouse mode with the two routines and that version seemed jittery.

I had tested the build out before and XInput performance was still lackluster compared to vanilla DS4Windows. It doesn't help that the build was an AnyCPU build despite my practice of intentionally compiling specific builds for each platform.

http://ryochan7.xyz/ds4windows/test/DS4Windows_v1.4.97-patch1.zip

[czukowski]

@Ryochan7, so long as we aren't talking about the core functionality, and there is a switch somewhere (presumably in profile settings) to turn it on and off, I think you shouldn't worry about the performance too much. If you're considering to implement this feature, the users will appreciate it in any case, and if there will be a way (or need) to improve the performance later, then even more kudos :)

[Ryochan7]

We are aiming for performance at least when it comes to the core XInput emulation functionality. The perceived performance can sway a bit between releases but any proposed feature that results in a very noticeable degradation of performance should be reworked or not included at all.

Looking over some rough data, the two calibration routines produce very similar output data and the minor difference for some numbers comes down to rounding differences. In the gyro fork, the gyro calibration routine rounds output values to the nearest integer. The gyro calibration routine in this version rounds output values to zero (just strip remainder).

With one minor change, both code bases obtain the same values for axes biases. The other version has a copy paste error so the AccelY bias value is used for adjusting AccelZ. With my main DS4 v2, it is only a 1 unit difference.

Besides worrying about the calibration routine portion, CRC32 validation and UDP server integration will have to be examined. Technically it would be better to have CRC32 evaluation being performed for data coming from BT connections and it is performed with similar projects like the hid-sony Linux driver. The UDP server routine runs synchronously on every gamepad poll so the time that it takes for a packet to be sent should be measured.

[czukowski]

I know, but in my opinion, this is not the core functionality, basically because it is useful only for a relatively small portion of applications, and it can easily be disabled by default to not affect performance for a majority of users. Although it's your call, of course.

As for the added latency for sending packets, what do you think about a setup like this:

• Invoke some kind of event in each loop of gamepad poll with the current state (will probably add to latency, but perhaps not a lot if there's nothing subscribed to the event - aka the 'disabled' state)
• An event handler for sending data to UDP server receives the state synchronously and pushes it to a queue
• UDP server runs in a separate thread and retrieves the states to transmit from the queue

This will probably cause UDP and Xinput outputs to be slightly out of sync, but since they are to be transmitted over different channels, I think it's kind of inevitable anyway. Also such approach may prove useful in the future for providing any other optional functionality.

[Ryochan7]

After spending a day working on it, I have CRC32 validation working at an acceptable level. The pre-made packages that I tried did not help much. I found an updated version of the one Crc32 class that was being used before and modified it to use an adaptation of the Slicing-by-16 routine documented on the following page.

http://create.stephan-brumme.com/crc32/

Acceptable levels of performance were achieved starting with the Slicing-by-4 routine but the other routines gave better results at the cost of a larger lookup table.

https://github.com/dariogriffo/Crc32

[fehmi1907]

Thanks for investing time in this - I am sure all Cemu community appreciates your efforts!

[Ryochan7]

Putting out a new release now is likely a mistake. Version 1.4.113 now performs CRC32 data validation for BT connections.

https://github.com/Ryochan7/DS4Windows/releases/download/v1.4.113/DS4Windows_1.4.113_x64.zip

[fehmi1907]

Thanks for the update. Please correct me if I am wrong but what I understand from the previous communication is that we will still need the UDP server integration for gyro implementation to work in other applications (i.e. Cemu)?

[Ryochan7]

That is correct. UDP server integration will be the next step to test.

[Ryochan7]

Here is just a straight port for now. Output performance is a tad worse off but it is still fairly usable and the performance is better than the older binary builds. PadTest works with the UDP server. I do not have Cemu on my system so I cannot test the gyro controls in any games.

http://ryochan7.xyz/ds4windows/test/DS4Windows_Test_x64_20180305.zip

[Ilitd]

I tested with Cemu and my DS4, gyro works great !

[Ryochan7]

Tweaked a couple of weak points that the VS performance profiler found. Some other tweaks outside of the UDP server routine have also been incorporated.

http://ryochan7.xyz/ds4windows/test/DS4Windows_Test_x64_20180306.zip

[Ryochan7]

This is what I get for not testing the build with PadTest before pushing it out. A couple of bugs were introduced with the last build that made it not work with PadTest. This build has been tested to work with PadTest.

http://ryochan7.xyz/ds4windows/test/DS4Windows_Test_x64_20180307.zip

[vico93]

Sorry to bother, but this build is compatibile with this cemuhook solution (its from the same rajkosto's fork)??

[Ilitd]

Yep, I tested it myself and it works with cemuhook.

[Ryochan7]

The most recent test build should work with cemuhook. I have only been using the PadTest application to test if the UDP server is working. With my old system (circa 2012), I doubt it could run any Wii U games at a reasonable frame rate.

[fehmi1907]

I believe you can run Cemu just fine if you have a 3ghz or faster i5 with and an Nvidia card. My Haswell from ‘13 doesn’t have any trouble with Wii U games as long as they are supported by Cemu. However, you would most probably run into issues if you have an older Amd processor or an Amd GPU in general.

[Ryochan7]

I got Cemu configured and downloaded Breath of the Wild. The game was able to run but not that well. Once Link traveled to the Great Plateau, Cemu was only rendering a little over 10 FPS with frequent freezing. Ended up playing through to the beginning of Oman Au Shrine and the frame rate jumped up to around 25 FPS. That is at least good enough to test.

Gyro motion controls seem to work fairly well from what I can test so far. XInput performance is a lot better in Cemu with the most recent DS4Windows test build compared to 1.4.94. Also, the 1.4.97 gyro controls build was messed up as the controls feel really wonky.

[fehmi1907]

Constant freezes sound like you don’t have the shader cache for the game and Cemu is creating that for you as you play - do you have the most recent shader cache in your transferrable folder? Also, is your BoTW updated to the last version (i.e. 1.5.0) and are you using the latest FPS++ graphics pack? You will need all of these for a decent performance on BoTW. Other games do not really require any complicated setup - for example, Mario Kart and Splatoon are really fun with motion controls.

Anyways, I haven’t had the chance to install your test build yet but I am hoping to do so over the weekend. It is great that the XInput performance is improved now!

Edit: Forgot to add that enabling dual-core or triple-core recompiler really helps for BoTW.

[Ryochan7]

I mainly followed the recommendations given in the following YouTube video.

https://www.youtube.com/watch?v=nLIdX03ks4U

The main exceptions are that I am not using any extra graphics packs and I have not downloaded the DLC update for BoTW; I am running BoTW version 1.1.0. Also, I am using the dual-core recompiler rather than the triple-core recompiler since my system's CPU has 6 cores (AMD FX 6200 @ 3.82 GHz) and it is recommended to use the triple-core recompiler if your CPU has 8 cores.

[fehmi1907]

on the test build dated 20180307 - gyro is working great! Also, it definitely feels snappier than the 1.4.94 fork.

on BoTW - Latest DLC will not matter but I'd strongly recommend that you update to the latest patch 1.5.0. You will have 2 problems if you decide to stick to a previous version -

1. Shader cache you have downloaded will not be compatible with your game version and Cemu will start to create shaders for the version you are using. You will experience frequent freezes.
2. FPS++ will not be compatible either.

I would also suggest deleting contents of your shaderCache\precompiled folder once you update to the latest patch so that Cemu can load the proper shader cache.

[vico93]

In a side note: i would love to see something similar coming for Dolphin - mapping gyro to wiimote motion controls (without resort to mapping it to keyboard, what kills sensitivity) would be amazing!

[Ryochan7]

I am not sure how well that would work out. I actually prefer the two handed form factor of the Wiimote and Nunchuk for playing games with gyro controls as opposed to the DS4; more range of motion and it is more comfortable. The big advantage the DS4 has is that the IMU is much more stable.

Personally, I would like to see better support for Motion Plus on some Windows controller mapping applications such as Touchmote. That is one area that Linux has Windows beat as using Motion Plus on Linux is a viable option although it is a bit difficult to set up and needs frequent re-calibration.

Wiimote Motion Plus - Borderlands: TPS: https://www.bitchute.com/video/7XdNtklMeRoJ/

[Ryochan7]

New test build based on DS4Windows version 1.4.115

http://ryochan7.xyz/ds4windows/test/DS4Windows_UdpTest_x64_20180311.zip

[mooms06]

Thank you very much Ryochan7, I've tested the latest build (20180311), it works great with Cemu & BOTW !

[SiTWulf]

@Ryochan7 Works like a charm!!! Thanks! Perfect now... we have a functional DS4 in Windows....

... only need the Speaker... LOL!!!!

[epigramx]

@vpontin dolphin uses low level emulation to do wiimote stuff; i.e. they don't even have to understand the high level implementation, the Nintendo statically linked code in each game does it for them. One would have to do that high level work on top of this in order to port motion from other controllers to it. PS. This is true not only for the bluetooth-passthrough mode but also their more basic true controller mode.

[grymfel]

Working great! Thanks for the good work.

Any chance of changing the port the UDP Server listens on from ipaddress.loopback (127.0.0.1) to ipaddress.any (0.0.0.0)? Cemuhook supports specifying a different IP address and/or port number in the .ini file. Integrating this into your version of DS4Windows would open up the option of running it on a different computer, for folks like me that are streaming from one computer to another using tools like Parsec or Moonlight.

[rajkosto]

im sure that if he integrates into actual releases he would add some configuration options (at least enable/disable checkbox, maybe listen ip/port boxes as well)

[reecespieces]

Any chance of a version with the UDP server that also uses ViGEm like the test build posted in #147??

This UDP test build gives me the same issue in #147 (on Win 7), but the ViGEm version seems to work fine.

[rajkosto]

for windows 7, you must install the xbox 360 accessories from here, https://www.microsoft.com/accessories/en-au/d/xbox-360-controller-for-windows

[reecespieces]

I have the xbox 360 accessories........ that is not the problem in #147.

The problem in #147 is that the X360 controller will fail to connect and it will default to Dinput only (despite having the X360 controller drivers installed). This didn't start occurring until version 1.4.97. Re-installing the SCP driver fixes it, but I have to do it after every reboot.

I would just go back to your fork of version 1.4.94, but that version now refuses to detect my controller.

The main point here is that from 1.4.97 onwards on Windows 7, SCP driver will fail and need to be re-installed constantly. ViGEm (that's a newer Xinput wrapper by nefarious) doesn't have the same issue.

Read through #147 for more details. The test build posted there uses ViGEm and works flawlessly for me, so I am just asking for a test build that has the UDP server and also uses ViGEm instead of SCP.

[rajkosto]

If you have other SCP-driver-using software on your computer maybe you should choose a higher port than 1 in the ds4windows settings ? I just tried this build on my win7 x64 (fully updated today with the march cumulative update) and it works just fine.

[reecespieces]

I don't have any other software on my computer that uses SCP driver, just DS4Windows.

The thing is that I didn't always have this issue. It started happening a few weeks into using v1.4.97 and it has continued happening in versions 1.4.97 and newer. I am not the only person to report this (look at #147).

Ryochan7 has released 2 test versions recently: ViGEm test build he released a link to in #147, and the UDP test build that he released here.

I am just asking for a combination of the 2, a test build that uses ViGEm instead of SCP, but also has your UDP server.

[mooms06]

I can reproduce the issue of @reecespieces: once I disconnect then reconnect the DS4 a few times it will only use Dinput only mode:

After a reboot it works again:

Windows 7 x64 SP1 up to date. Generic Bluetooth Dongle by Cambridge Silicon Radio Ltd. DS4 v2

I also confirm that 1.4.94-patch1 (fork of @rajkosto) is not affected (and I remember now that's why I don't used 1.4.97-patch1).

[Ryochan7]

I should be able to bundle a test build that uses both patches. There should be no conflict between the two patches. These builds need to be consolidated at some point and functionality needs to get integrated into the main build.

There are two major factors holding back ViGEm integration: the driver installer and the wait for a new release of ViGEm. Without some of the optimizations that have been included in the source code, I found ViGEm had a bit of lag so I would not want to use it on a regular basis. Once a new release of ViGEm is made, that version will be the minimum recommended version. It would be nice to have access to a currently supported driver and maybe be able to integrate DS4 emulation support at some point.

Although ViGEm support is set to be used with a version 1.5 release, there is no set plan to include the UDP server yet although it will definitely not make the 1.5 release. I still haven't tested what performance would be like with the UDP server included in the code but disabled even though that would only mean commenting out a few lines of code. Some extra options would need to be included in the settings tab related to the UDP server: option to enable UDP server (defaults to disabled), port number and possibly the inbound IP address option.

As for the DInput only issue, trying to diagnose the problem before did not lead to any understanding of why the problem occurs. The commit where functionality breaks did not present a clear reason why this problem happens. I guess I will have to blame some voodoo happening with the .NET Runtime that is out of my control. If the problem does not occur when using ViGEm then that is even more reason to try to migrate to ViGEm.

[Ryochan7]

Combined ViGEm and UDP test build

http://ryochan7.xyz/ds4windows/test/DS4Windows_ViGEm_UdpTest_x64_20180315.zip

[Filoppi]

I've been using rajkosto build with cemu for some time, and i've now tried your updated version with UDP, i can confirm that none of them can execute macro "Special Actions" while cemu is in fullscreen: for example, i've created a Scan Code macro (Win+Print Screen) to take screenshots and bound it to the PS button, and it doesn't work. It doesn't matter what keyboard keys i try or what controller buttons i bind it to, they just don't work, the trackpad doesn't even move the mouse when cemu is in fullscreen. I'm certain that cemu does sometime to lock other inputs, but that just makes everything more complicated, as i can't use motion controls (UDP) or touch controls (trackpad to mouse) from the controller, and i can't take screenshot. Of course outside of fullscreen cemu, all of those things work.

So i was just wondering what was the reason behind this and if it could be fixed. Thanks.

[fehmi1907]

I have a bug report - DS4Windows crashes if I launch Cemu with my DS4 turned off. I don't have any issues if DS4 is already on when I launch Cemu. Let me know if you need further details.

Below are from the event log:

.NET Runtime

Application: DS4Windows.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.NullReferenceException at DS4Windows.UdpServer.NewReportIncoming(DS4Windows.DualShockPadMeta ByRef, DS4Windows.DS4State) at DS4Windows.ControlService.On_Report(System.Object, System.EventArgs) at DS4Windows.DS4Device.performDs4Input() at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) at System.Threading.ThreadHelper.ThreadStart()

Application Error

Faulting application name: DS4Windows.exe, version: 1.4.115.0, time stamp: 0x5aaae71c Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc0000005 Fault offset: 0x00007fff8afed07b Faulting process id: 0x21e0 Faulting application start time: 0x01d3be78b874298a Faulting application path: C:\Users\Fehmi\Documents\DS4Windows\DS4Windows.exe Faulting module path: unknown Report Id: 8675fcb3-ecfa-4b6b-bf22-68835240008e Faulting package full name: Faulting package-relative application ID:

[Ryochan7]

It looks like this bug only affects people using the Sony adapter. The variable specifying the mac address is set to null at that point because the blank serial is ignored when populating the meta data. There are a couple of workarounds that I could probably implement so I need to decide what to do.

[fehmi1907]

That is correct - I'm using the Sony adapter.

I recently uninstalled the SCP driver and switched to the Combined ViGEm and UDP test build. However, I believe the same crash happened with the previous UDP test builds. I also tried the ViGEm test build without the UDP server and there were no crashes.

[fehmi1907]

Just wondered if you are planning to offer test builds for the UDP server versions (SCP and ViGEm) on a regular basis. I know the latest 116 build is mostly a small maintenance update but it would be good to know what to expect going forward.

[Ryochan7]

I finally got around to building some newer test builds.

http://ryochan7.xyz/ds4windows/test/DS4Windows_UdpTest_x64_20180322.zip http://ryochan7.xyz/ds4windows/test/DS4Windows_ViGEm_UdpTest_x64_20180322.zip

Also, even though I am not including these changes in the repository currently, I will at least post the current progress patches being used. I could keep the changes separate using branches but my normal routine is to use patches.

ds4windows_vigem_udp_test_20180322.diff - https://gist.github.com/Ryochan7/a8aaa5234d55259da83b395ab373efd1 ds4windows_udp_test_20180322.diff - https://gist.github.com/Ryochan7/67446921a4e96b2dfe7a9cabdf2c7012 UdpServer.cs - https://gist.github.com/Ryochan7/8e56193662130a0460e692ce63293641

[fehmi1907]

0322 ViGem test build runs great on my system. However, DS4Windows still crashes if I launch Cemu with my DS4 turned off - this is with the official Sony adapter.

[vico93]

Sighly off-topic, but i think it doesnt deserve a issue itself: @Ryochan7 i have DS4Windows 116, updating all way from the builds using sole SCP server. If i want to update to any build based on ViGem, i need to uninstall everything first because the switch from SCP to ViGem? What are the instructions in this case?

[Ryochan7]

Well, I'm an idiot. I did not port that fix before compiling the new builds. Got the fix ported over to the relevant patches and tested the builds. They should work fine now.

http://ryochan7.xyz/ds4windows/test/DS4Windows_UdpTest_x64_20180323.zip http://ryochan7.xyz/ds4windows/test/DS4Windows_ViGEm_UdpTest_x64_20180323.zip

Regarding vpontin's question, you do not necessarily have to remove anything to use the ViGEm build. You can have ViGEm installed alongside SCP although I usually have the device that I am not currently using disabled on my system. One big problem is that you will have to disable auto updating for DS4Windows. If you do not then DS4Windows will download the latest version that uses ScpVBus when a new release is made.

Installing ViGEm can be done using the test driver installer utility. This version is a bit old but it works.

http://ryochan7.xyz/ds4windows/test/DriverInstaller_Test_20180218.zip

[Filoppi]

What about my last comment? Isn't that an issue?

[Ryochan7]

That type of macro seems to be working on my end both on the desktop and when Cemu is in fullscreen mode. I will have to look into this a little further. Personally, I don't like the macro system so I don't use it nor work on it except when an obvious bug or regression is discovered. It is really just there for backwards compatibility with older profiles.

Also, I would not use the scan code option. It is also only left in the program for backwards compatibility with older profiles and I think it is a bad idea to use it. Both virtual codes and scan codes are generated when outputting regular keyboard key events since the early days of this fork. The scan code option lets you only have a scan code generated instead.

Using the touchpad to move the mouse cursor works fine for me when Cemu is in fullscreen mode.