Ds4windows: [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.

[Ryochan7]

It seems like it takes two attempts before the macro will actually work as intended. This also happens with DS4Windows Jays2Kings (1.4.52).

[Filoppi]

It might be the scan code settings, I'll have another look myself, thanks.

[DiabolusExMachina]

Hi. Will the UDP changes be merged into the regular Version? I would be great If I could update again...

[fehmi1907]

@Ryochan7 posts the UDP builds soon after the regular releases. I believe that is fair enough until relevant code is merged into the regular branch - which could take a while.

[DaRkL3AD3R]

This really needs to just be merged already. I didn't know it wasn't so when the program automatically updated I lost the UDP server aspect and was really puzzled why motion controls weren't working. Turns out you have to use custom builds still for this functionality.

[Ryusennin]

"I didn't know"

It's explicitely mentioned in this very topic.

[Ryochan7]

For the time being, you should have the UDP server build saved separate
from the main build and disable Check for Updates.

I have barely worked on this lately but some recent experiments led to
changes in the last version. Having the hooks for the UDP server does add
lag even when it is not used. Recent changes have reduced the difference a
fair amount. A new build should get pushed out soon.

On Sat, Apr 14, 2018, 9:01 AM Ryusennin [e-mail] wrote:

"I didn't know"

It's explicitely mentioned in this very topic.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Ryochan7/DS4Windows/issues/228#issuecomment-381331259,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjhUD6Q_G4pTFbUs2-gmop-gvh6F5NIks5togElgaJpZM4SWA-Y
.

[fehmi1907]

Just curious - have you noted any difference in input lag between ScpToolkit build vs ViGem build? I have recently scrubbed ScpToolkit from my to switch to ViGem and have been a happy camper.

[Filoppi]

So, i tried to do some debugging to understand why mouse and keyboard events don't work with the UDP builds (neither yours nor rajkosto).
I didn't figure out much but this line seems to be called in both cases
uint result = SendInput(1, sendInputs, Marshal.SizeOf(sendInputs[0]));
and in both cases it returns 1.
you can find it in "InputMethods.MoveCursorBy(int x, int y) Line 24", or at least that's were it used to be in build 1.4.94.
So apparently, the "problem" is in the UDP implementation of cemu, as i doubt that "user32.dll" stops accepting our calls if cemu is in foreground.
Somehow cemuhook, when an UDP connection is found, blocks all the "fake" input calls from windows?
It is very weird as it doesn't happen when you are running the normal DS4Windows version (so when no UDP is found).

I'm not sure this problem happens to everybody though, @Ryochan7 you said the DS4 trackpad mouse works fine for you in cemu, but were you running the UDP version of DS4Windows and cemu with cemuhook? (It doesn't only happen in fullscreen by the way, windowed cemu has the same problem)
@rajkosto Do you think anything i said makes sense? I'm not an expert of windows APIs or UDP between apps, but those are the result i got by debugging.

[Filoppi]

Ok i just found out why it happens. I had "Run this program as administrator" turned on in cemu Windows compatibility settings. Apparently turning that off (or turning it on DS4Windows as well) fixes the problem.

[fehmi1907]

I have barely worked on this lately but some recent experiments led to changes in the last version. Having the hooks for the UDP server does add lag even when it is not used. Recent changes have reduced the difference a fair amount. A new build should get pushed out soon.

Just wondered if you have had the chance to update the UDP builds. The reason I am asking is that there have been some important fixes related to the official Sony dongle lately.

[Ryochan7]

I need to get back on this. The only productive thing that has been done lately is that I finally made the other branches for the various builds and committed them to GitHub. At least the code is out in the open again.

https://github.com/Ryochan7/DS4Windows/tree/udpserver
https://github.com/Ryochan7/DS4Windows/tree/vigem-udpserver

[Ryochan7]

Ok i just found out why it happens. I had "Run this program as administrator" turned on in cemu Windows compatibility settings. Apparently turning that off (or turning it on DS4Windows as well) fixes the problem.

Permission problems can come into play when using SendInput. Normally, I have DS4Windows running as administrator so I would not stumble upon that problem when running other applications or games. One game that I can recall that a similar problem would pop up would be Mass Effect 1 since it has to run with administrator privileges.

[Ryochan7]

New builds

http://ryochan7.xyz/ds4windows/test/DS4Windows_1.4.119_UdpServer_x64.zip
http://ryochan7.xyz/ds4windows/test/DS4Windows_1.4.119_ViGEm_UdpServer_x64.zip

[Ryochan7]

New builds

http://ryochan7.xyz/ds4windows/test/DS4Windows_1.4.120_UdpServer_x64.zip
http://ryochan7.xyz/ds4windows/test/DS4Windows_1.4.120_ViGEm_UdpServer_x64.zip

[SiTWulf]

Thanks @Ryochan7 for this updates...

[vico93]

@Ryochan7 i installed vigem using this tutorial. Is this bad or good?

[Ryochan7]

The official way listed on the wiki is the better way to install ViGEm but that method is not very user friendly. The resulting ViGEm installation should be the same whether using that method or the test installer.

[vico93]

So i think i gotcha this time. Installed normally and gamepads are working.

But i still get some issues with non-related bluetooth devices right when reinstalling DS4W, (dropped another issue about)

[HeyItsJono]

This is great! Are you planning to eventually integrate the UDP server into the official releases?

[LuismaSP89]

Yes please, we need the gyro for some emulators such as Cemu or Rpcs3. Please, consider to integrate the UDP server into the official release or at least create a second and updated branch of the DS4Windows. Thanks a lot for your effort and work!

[Ryusennin]

Since a few versions, the UDP builds are up to date and available on the front page.

[HeyItsJono]

Unfortunately, the auto-update function of the program itself still seems to point to the non-server version. 😞

[Ryochan7]

The auto-update code still points to main build. I have encouraged people to turn the auto update feature off previously. Part of the lack of a secondary update file list is due to laziness but some of it is due to worrying about random .NET issues popping up that slow down the program; worrying about .NET quirks has been a real showstopper lately. Since this version has not been integrated, I will at least make an alternative update list for the main UdpServer build; people using the current ViGEm based UdpServer will still have to disable auto updating. I don't think that change should not cause any major code merging problems in the future.

Some minor changes have been made to the UdpServer code so it has not been completely ignored. Some experiments have been done with the UdpServer branch but not enough progress has been made to get it integrated into the main branch. Adding extra threads and copying data to basic structs have gotten performance fairly close to what I would want.

Here is a partial diff with the most recent misadventure; it does not include the new struct type though.

https://gist.github.com/Ryochan7/cefcd5b658f03d7e214fda5b9f6739af

[Ryochan7]

Good news. I tested some newer experiments and I felt that the performance of the final result was good enough to actually integrate the UDP server. The code from the udpserver branch has now been merged into the master (jay) branch. There is no need to have a separate update path anymore since it looks the UDP server will be an option in the main build starting with the next release of DS4Windows.

[mooms06]

Great!
The last build (DS4Windows_1.5.2_ViGEm_UdpServer_x64) doesn't seems to works with UDP server though.
The previous (DS4Windows_1.5.1_UdpServer_x64) works fine.

[Ryochan7]

I just tested that build against PadTest and it worked on my system. You are comparing builds that use two different emulation drivers. If you do not have ViGEm installed on your system then the DS4Windows_1.5.2_ViGEm_UdpServer_x64 build will not work and the controller detection routine will be skipped. Build DS4Windows_1.5.1_UdpServer_x64 uses ScpVBus for Xbox 360 controller emulation just like the main build. The plan is to have DS4Windows use ViGEm instead of ScpVBus in the future.

[mooms06]

My bad, I didn't see there was an UDP server only build. DS4Windows_1.5.2_UdpServer_x64 works fine.
I'm keeping ScpVBus for now since it's working fine, I will switch to ViGEm once it will be mature enough.

[Ryochan7]

ViGEmBus is a good driver that is more capable than ScpVBus. The main problem with the current stable release is that it is slower than ScpVBus. I helped contribute to the ViGEm project a little bit to improve the driver for my system; I mainly enabled some different compiler options in the project. Compiling the driver from the latest source code works just fine although running the driver would mean having to run Windows in Test Mode. Once Benjamin releases a new signed driver, I would like to have DS4Windows stop using ScpVBus.

[vico93]

Oh perharps thats why i have some weird lags and freezes when playing (Dolphin Emulator), i'm using vigem + udp already.

[Ryochan7]

That was my fault. I just discovered that problem last night when I tried to use that build. The ViGEmClient assembly that DS4Windows uses had changed its API recently and I did not carry over a change from the regular vigem branch over to the vigem-udpserver branch. That means that any DS4Windows release posted after 07/08/2018 would have the same problem.

https://github.com/Ryochan7/DS4Windows/commit/561ba5c813f4ac6882915de9a0eb9f0c9df084d4

[Ryochan7]

Version 1.5.3 has been released. The UDP server is disabled by default but it can be enabled in the Settings tab.

https://github.com/Ryochan7/DS4Windows/releases/tag/v1.5.3
https://github.com/Ryochan7/DS4Windows/releases/download/v1.5.3/DS4Windows_1.5.3_x64.zip
https://github.com/Ryochan7/DS4Windows/releases/download/v1.5.3/DS4Windows_1.5.3_x86.zip

[vico93]

I'm kinda lost: these builds are for vigem or scp?

[Ryochan7]

Those are scp builds. The vigem build has been updated as well. There is only the one vigem build now instead of two.

http://ryochan7.xyz/ds4windows/test/DS4Windows_1.5.3_ViGEm_UdpServer_x64.zip

[vico93]

Thanks Ryo!