(02-22-2014, 06:15 PM)InhexSTER Wrote: [ -> ]Just remark nibble is an incorrect term, it is actual 4 bits,16 values not 0-127
In the sense that a byte had the full 255 range I suppose I could have called it 'halfByte', but I felt like trolling. Strictly speaking it is half an octet, not half a byte, anyway.
So im using the newest verson of this but when I try to play some games it still acts like it would without the wrapper.
(02-22-2014, 06:39 PM)InhexSTER Wrote: [ -> ]Here is an RC2 for 1.2.1
Its very close to final release:
Fiixed some custom mapping issues:
Now all mapping should work, except for emulating key hold for keyboard (keystroke atm)
Fixes issues with some mappings not being saved into xml file
Refactored and rewritten underlying code for custom mappings
In the future release:
unbinding the button will reset input to nothing, instead of using regular mapping
Keyhold/Keystoke support
Solid build here. Going to do performance test logging and see how it compares to regular 1.2, which was a phenomenal improvement in performance.
I wonder, does having full custom key mapping (and in the future, keyhold) mean we pretty much never need another program like Xpadder/Pinnacle ever again? Seems like it to me
Keep up the excellent work guys. You are the heroes we need.
Performance tests in:
Idle cpu usage is the same, around 0.02% or 0.03%. Excellent.
In-game and using the controller, we have double the cpu usage, which is still a meaningless amount but important to note. Where-as on 1.2 average cpu usage in-games was about 0.18%, now it's averaging 0.32%. For most people with gaming machines today, this is going to be a completely insignificant change, but for someone on say a laptop with an incredibly low power CPU, who struggles to play games currently, it might mean a few FPS.
I also noticed that we can see the motion sensors now in the app when in the options menu. That's neat and all, but there are virtually no games that utilize these sensors. Furthermore I noticed that if I left the controller idle on my desk, CPU usage dropped to about 0.02% but if I picked up my controller and started spinning in wildly to stimulate the motion sensors, CPU usage immediately spiked up to 0.10% almost instantaneously. This is staring at a blank desktop and not in any game that uses the controller. So this tells me that the server is constantly looking for and calculating those motion sensors even when they're not utilized.
Possibility to disable motion sensor logging to further reduce performance? I know of no way to even utilize these sensors, let alone find a game that could make use of them in any possible way. Would be a nice little optimization to have an option to disable them in the server, if only to help reduce CPU utilization.
(02-22-2014, 07:15 PM)DaRkL3AD3R Wrote: [ -> ]I wonder, does having full custom key mapping (and in the future, keyhold) mean we pretty much never need another program like Xpadder/Pinnacle ever again? Seems like it to me
Yep, that's exactly what it means
I'm currently looking at InhexSTER's new code to see how we might change key hold from the way mine did it. I'll also look at sixaxis custom mapping soon.
(02-22-2014, 07:10 PM)Opportunitysoap Wrote: [ -> ]So im using the newest verson of this but when I try to play some games it still acts like it would without the wrapper.
You might not be using it correctly, or you may need to do the Disable/Enable on the SCP driver. Could you post more details to help us see what might be wrong? See first post for troubleshooting post guidelines.
Note to everyone using old Custom Mapping XML files:
The X/Y Axes have been renamed from the 'Left X-Axis 2' style to the 'Left X-Axis+' and 'Left X-Axis-' style that InhexSTER uses in his new version. My next version will also use this format. Please delete your old custom mapping config files or manually edit them (if you really want to).
(02-22-2014, 03:08 PM)HecticSeptic Wrote: [ -> ]Are you using custom mapping, and if so are you using InhexSTER's 1.2.1 RC1 or mine? If you're not using custom mapping, have you enabled the 'Hide DS4 Controller' checkbox?
I am not using a custom mapping. I tried both of yours, both with the hide ds4 controller checkbox enabled and it didn't work.
@DaRkL3AD3R
its not to do with sensors but with reports, controller has mechanism where it sends data only when its been changed over BT. So when its idling there is less reports coming in as sensors change less often. So when there less reports/s sent tool uses less cpu. And most cpu intensive addition is having a checking if controller is unplugged. It might be possible to make it less frequent (right now 500ms), maybe 1s
Mappings don't seem to add much cpu usage at all.
(02-22-2014, 07:47 PM)InhexSTER Wrote: [ -> ]its not to with sensors but with reports, controller has mechanism where it sends data only when its been changed over BT. So when its idling there is less reports coming in as sensors change less often. So when there less reports/s sent tool uses less cpu
Yeah I didn't know how to properly word that but I understand it.
The thing is on 1.2 and prior, there was no receiving reports for the sixaxis sensors so I could wave my controller around all I want and SCPserver.exe has an average CPU usage of 0.00% while not gaming.
Now on 1.2.1 RC, because the sixaxis sensor's are being read by SCPserver, now if I wave the controller around even on the desktop not doing anything, I can watch the CPU usage of the server jump immensely.
So my point was that it's great to have the ability to report and in the future, map, the sixaxis sensors but it would be great if we could toggle disabling receiving reports from these sensors as they're kinda pointless and wasted CPU cycles.
Other than that everything is working perfectly, keep up the great work.
(02-22-2014, 07:58 PM)DaRkL3AD3R Wrote: [ -> ]So my point was that it's great to have the ability to report and in the future, map, the sixaxis sensors but it would be great if we could toggle disabling receiving reports from these sensors as they're kinda pointless and wasted CPU cycles.
The controller sends full reports every time, the frequency just increases when values are changing more. The reports aren't modular, so we cannot opt to not receive sixaxis reports.
If you have the Options window open, then the reports are being 'used', but with the current implementation it will check regardless of whether it has changed, it therefore redraws the axes each time so the CPU usage should be consistent. Unless of course .NET intelligently does not redraw when values are set to the same value, then you would see slight CPU spikes - but that is only with Options open. Custom Mapping will soon behave the same way when we have it checking if you've pressed anything.
(02-22-2014, 08:13 PM)HecticSeptic Wrote: [ -> ]The controller sends full reports every time, the frequency just increases when values are changing more. The reports aren't modular, so we cannot opt to not receive sixaxis reports.
If you have the Options window open, then the reports are being 'used', but with the current implementation it will check regardless of whether it has changed, it therefore redraws the axes each time so the CPU usage should be consistent. Unless of course .NET intelligently does not redraw when values are set to the same value, then you would see slight CPU spikes - but that is only with Options open. Custom Mapping will soon behave the same way when we have it checking if you've pressed anything.
Hmm would you and Inhexster wanna follow these quick steps and see what's going on then?
1. Use 1.2.1 RC2 and connect your controller with Bluetooth
2. Minimize DS4 Tool and open Resource Monitor
3. Tick SCPServer.exe and look at the Average CPU column
4. If it isn't already at 0.00% then wait for it to get around 0.05% or less
5. Now pickup the controller and shake it around for about 3 seconds
6. Watch CPU usage spike up as the minimized DS4 Tool is receiving reports for the Sixaxis sensors
7. Now uninstall 1.2.1 RC2 and setup original 1.2
8. Do steps 2-6 again and watch how SCPServer.exe average CPU remains a constant 0.00% no matter how much you shake the controller
I'm no coder but to me this says that, because in 1.2.1 we can now monitor the sixaxis sensors in the options menu, that it means the server is reading these reports from the controller. Whether the controller sends them or not is regardless and only affects the controller battery, no big deal. I am looking at CPU usage and optimization from SCPserver and if we are now receiving reports on sensors that we are physically unable to use, and of which no games use anyway, it seems to me like wasted CPU cycles.
I hope you understand what I'm trying to say and that your findings are similar to mine. The test should only take a few minutes real simple and easy to see. Thank you gentlemen.
Apologies, ignore this. I re-tested 1.2 and apparently the performance impact is delayed in being shown in ResMon but still quite there.
1.2.1 is good to go. Sorry guys x.x
Merged all the branches together into
https://code.google.com/r/brianfundakows...ource/list now, and also committed a fix to the rumbles being reversed. Next I'll add a toggle for HID queue flushing (should not be necessary except on ancient systems afaik), the linear trigger remapping (Arthritis mode), and I'll work on a replacement touchpad mode. We can simply use the sixaxis sensors to perform jitter compensation around critical events (button press/unpress, finger tap/touchpad push/unpush/release, etc.)