..:: PCSX2 Forums ::..

Full Version: DS4 To XInput Wrapper
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
(02-23-2014, 08:12 PM)electrobrains Wrote: [ -> ]Great news -- I've gotten all of the most interesting features from my development branches integrated, and here is a build based upon the RC3, but with some significant changes...

Out of curiosity, does this build off my recent commit, or off of InhexSTER's?
(02-23-2014, 08:12 PM)electrobrains Wrote: [ -> ]Great news -- I've gotten all of the most interesting features from my development branches integrated, and here is a build based upon the RC3, but with some significant changes:
* Jitter compensation has been drastically improved and the touchpad does not tend to "eat" input like before. It's much easier to move the mouse cursor and tap to click.
* Light bar battery indication is gradual and can show you the entire range of 10%->100%.
* Arthritis mode is in. You can remap the midpoint of your L2 and R2 triggers.
* Multiple controllers should work simultaneously as touchpads.
* HID queue flushing is optional per-controller.

Other than these changes, functionality should be identical.

My To Do for 1.2/1.3:
* Improve two-finger scrolling. Use cumulative mid-point location changes to determine scroll amount, rather than just the Y-delta of the left/first finger. If we scroll toward pure left or pure right, ignore it, otherwise go with whichever X direction the mid-point is pulling toward. Use the distance between both fingers as a scroll distance coefficient so you can move your fingers apart to scroll far or move your fingers closer together to scroll in fine increments.
* Jitter removal via sixaxis sensors. This will replace existing jitter removal for a large part, not augment it. Even before working on this, though, I can do better jitter removal for pushes on the touchpad by applying reduction coefficients to the critical push event similarly to the dejitter performed at the start of a tap gesture.
* Customization of every hard-coded variable (several in the touchpad related to distance, permit defining your exact on/off periods for each battery state from 10% to 100%.)
* Nine different virtual button areas on the touchpad, N/NW/Center/etc only activated on touchpad PUSH. If we drag around, then upon push, only the center button (what is currently left click) will now happen.
* Global configuration snapshots used by the touchpad, custom mappers, etc. There's just no reason to keep reinterpreting configuration data that hasn't changed. This should reduce any latency in the custom mapping path.
* Synthetic rumble events to indicate state changes.
* Touchpad mode switching.
* Controller switch-off via either L1+R1+PS button combination or via resting it on an "off" position (i.e. on the table shoulder down, or face down.)

For 1.3 only:
* Optional dead-zone fix-ups. X360 controller and DS4 have very different behaviors here.
* Try and expose audio.
* Rumble translation into light bar flashes for accessibility (not everyone can feel rumbles in their hands, or feel anything in their hands, despite being able to use a controller effectively.)
* Derive accurate gyrometer and moment of inertia values from the sixaxis sensors and expose these in a basic way. This is tricky for technical reasons because physics.
* Prototype some game-specific modality, i.e. motion controls mapped to thumbpad for sailing in Assassin's Creed 4: Black Flag.
* Associate settings with controllers by MAC address, not by device number.
* Stop stealing Xinput device 0 when an XBox 360 controller is already connected and using it. We can easily avoid renumbering just by querying the API for what controller(s) are active.

Sweet and nice to see gyro support

Just one thing the bottom edge of remap window needs to go a lil lower some things are cut off, either that or allow to custome resize
(02-23-2014, 08:12 PM)electrobrains Wrote: [ -> ]* Stop stealing Xinput device 0 when an XBox 360 controller is already connected and using it. We can easily avoid renumbering just by querying the API for what controller(s) are active.

The XInput Pad ID is assigned by the XInput Subsystem not by the Bus. You can't steal XInput Device 0. XInput Pad Ids are assigned by the order in which devices are connected.

Think of ScpVBus as a USB Hub - doesn't matter which Port # you plugin to, it's the order that they are used which defines which XInput Pad ID is assigned. (eg. X360 Controller already connected and assigned XInput Pad 0, Pugin port #4 on the Bus -> DS4 is assigned XInput Pad 1)
(02-23-2014, 08:12 PM)electrobrains Wrote: [ -> ]Great news -- I've gotten all of the most interesting features from my development branches integrated, and here is a build based upon the RC3, but with some significant changes:

I just tested 1.2.1 RC3 (by clicking the 1.2.3. link, is that right?), and turning the touchpad off with L2+Touchpad doesn't work anymore. Turning it on works fine. I got it to work once accidentally, but it's definitely not working the way it was.

Also, will we see the return of your Touchpad modes in 1.3?
(02-23-2014, 08:55 PM)HecticSeptic Wrote: [ -> ]Out of curiosity, does this build off my recent commit, or off of InhexSTER's?

This is branched from your branch's latest commit. You can view that relationship here: https://code.google.com/r/brianfundakows...ource/list
(02-23-2014, 10:04 PM)Scarlet.Crush Wrote: [ -> ]The XInput Pad ID is assigned by the XInput Subsystem not by the Bus. You can't steal XInput Device 0. XInput Pad Ids are assigned by the order in which devices are connected.

Think of ScpVBus as a USB Hub - doesn't matter which Port # you plugin to, it's the order that they are used which defines which XInput Pad ID is assigned. (eg. X360 Controller already connected and assigned XInput Pad 0, Pugin port #4 on the Bus -> DS4 is assigned XInput Pad 1)

That can't be completely correct because I've had connection of one controller shuffle the other controller into a different spot, without disconnecting it, before. I am not sure what circumstances caused that renumbering but it happened a number of times. Also, I can cause it to race and have the Xinput interface essentially be completely dead. If you want to see what I mean, you really need to have X360 controllers available, too. It's not that important, though, because settings are going to be saved by controller unique identifiers instead. BTW, do you know how if battery level can be communicated to the XBox 360 controller dashboard?
(02-23-2014, 10:23 PM)pedrovay2003 Wrote: [ -> ]I just tested 1.2.1 RC3 (by clicking the 1.2.3. link, is that right?), and turning the touchpad off with L2+Touchpad doesn't work anymore. Turning it on works fine. I got it to work once accidentally, but it's definitely not working the way it was.

Also, will we see the return of your Touchpad modes in 1.3?

Oops, thanks for testing that. It was a one-character bug (accepting trigger value 127 alone instead of values 128-255, when going to disable the touchpad, like 128-255 now work for enabling it. Previously, only 255 or "full trigger" worked, and no games actually use that kind of behavior of requiring a full trigger pull to indicate "on" versus "off." Here's a fixed version, maps 0-127 of either trigger to "off" and 128-255 as "on."

Yes, I will support several touchpad modes selectable through pressing the Guide/PS button while you have finger(s) touching the touchpad. The existing one HecticSeptic and InhexSTER designed will be one mode. Another mode will be the one I derived from the original InhexSTER did, where buttons act as mouse buttons, but also including tap, two-finger scrolling, and the up-to-9-programmable virtual button zones on the touchpad. Then, of course, there will also be an "off" mode and maybe a cursor-movement-but-no-clicking mode as well.
Man I must be annoying to you guys by now Tongue

Anyway it doesn't look like you can assign multiple inputs to click, right click, middle click, which was possible with Hectic's previous version (the one w/o custom touchpad mapping) and the build of it from InhexSTER.

Also setting the touchpad to more than clicks would be nice.

EDIT: even though the touchpad says unbound, clicks still would, as does for multitouch and upper area.
(02-23-2014, 11:07 PM)Jays2Kings Wrote: [ -> ]Man I must be annoying to you guys by now Tongue

Anyway it doesn't look like you can assign multiple inputs to click, right click, middle click, which was possible with Hectic's previous version (the one w/o custom touchpad mapping) and the build of it from InhexSTER.

Also setting the touchpad to more than clicks would be nice.

EDIT: even though the touchpad says unbound, clicks still would, as does for multitouch and upper area.
I intend to overhaul that completely. Instead what touchpads will support is up to nine zones corresponding to North, Northeast, East, Southeast, South, Southwest, West, Northwest and Center. In the middle between zones will be a configurable amount of dead-zone so ambiguous presses are just ignored. BTW, bug reports are never annoying! Testing is very valuable. We can't test everything ourselves, as you guys can atTEST Wink
@electrobrains: I've got 2 X360 Controllers, 1 wired and 1 wireless. I did extensive testing while developing the bus, that was the behaviour on XP, Vista, Win7. It may be MS have since changed the behaviour on Win8/8.1 (or introduced bugs) - but the Bus has no control over which XInput Pad Id is assigned, it just informs Windows that a controller has been connected. Everything from then on is controlled by the XInput Subsystem. Which OS are you using?

The Bus implements X360 Wired Controllers - they don't have a battery, so no way to get the MS overlay to display it.