..:: 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.
(03-11-2014, 12:22 PM)electrobrains Wrote: [ -> ]Yes, this was the schema I devised for making it not interfere when you have a game that supports both Xinput and mouse input -- i.e. Assassin's Creed 4 and Final Fantasy XIV. You just gave me an idea: add a minor mode for "mouse lock" when you are in the button-mouse mode. We'd use the push button on the touchpad to toggle between the current behavior and the behavior you are describing which is similar to the behavior you had for mouse mode back in the 1.1 days. I like having both easily available. Tapping support is something I could add back, using the rewind methodology I came up with on my 1.2 branch. But I want to keep jitter compensation out of that particular mouse mode for now.

yeah this is what makes that mode great, it stops the buttons interfering otherwise. Its probably my favourite part of the whole wrapper!!
(03-11-2014, 12:18 PM)electrobrains Wrote: [ -> ]Sounds like you should try binding them as scancodes instead.

Thanks for the tip. I'll try it out when I get home from work. Though I am not exactly sure what that means, I'll peruse through the settings and see if I can't find something obvious.
(03-11-2014, 03:41 PM)zappadappa Wrote: [ -> ]Thanks for the tip. I'll try it out when I get home from work. Though I am not exactly sure what that means, I'll peruse through the settings and see if I can't find something obvious.

Yes, Scan Codes was going to be my answer as well. We don't have any control over what other programs do, but logically since the sticks are very sensitive the other program likely does not have a threshold.

Using Scan Code (instead of virtual key default) provides a hardware friendly alternative which games tend to require. Some games also try to prevent emulated input, so those ones shouldn't work unless the program gets very low level and plays around with your physical keyboard, which generally you do not want.
(03-11-2014, 02:51 PM)delt31 Wrote: [ -> ]any reason why my controller sometimes moves left right up and down by itself? Lasts for only a couple of seconds but wondering if anyone else has experienced this.

I have seen my right analogue stick twitch every now and then, but never in game and always in tiny amounts. It also stops if I use it. I've seen the effect in default DirectInput so I imagine its the controller.

(03-11-2014, 12:36 AM)electrobrains Wrote: [ -> ]That sounds good. We don't need to treat touch1 versus touch2 any differently, any motion either contributes should work fine. You should put that bit of code in a common place so both Mouse (could we rename this TapMouse?) and ButtonMouse can call it, both would need it for big enough drag-and-drops.

I've been wanting to add that for a while actually...

I imagine though that the click of the pad would need to stay down while the second touch keeps moving the cursor. And also that for tapping this is only after a double-tap (otherwise it might be a scroll). That'd then have to not issue a left mouse up until the pad is not receiving touch, as well as ignore the second tap (not do the Click). For normal pad clicks, we can make this explicitly check for the Left Click mapping first.
(03-11-2014, 04:51 PM)HecticSeptic Wrote: [ -> ]I have seen my right analogue stick twitch every now and then, but never in game and always in tiny amounts. It also stops if I use it. I've seen the effect in default DirectInput so I imagine its the controller.


I've been wanting to add that for a while actually...

I imagine though that the click of the pad would need to stay down while the second touch keeps moving the cursor. And also that for tapping this is only after a double-tap (otherwise it might be a scroll). That'd then have to not issue a left mouse up until the pad is not receiving touch, as well as ignore the second tap (not do the Click). For normal pad clicks, we can make this explicitly check for the Left Click mapping first.

One thing that seems potentially-intuitive is this timeline:
1. User puts finger near pad. Cursor stays still.
2. Finger hits pad clicks by pushing down until the switch hits. Cursor starts floating with finger motion and finger no longer has to keep the button down, just leave the finger on the pad and the drag will still occur. So push is a "drag" button.
or 2. Two fingers click, so we initiate a right-click drag. Same rules apply for dragging it further than the side of the pad by alternating fingers in sort of a walking motion.
or 2. The sixaxis sensors oscillate a bit, indicating that the finger landed (because otherwise we REALLY don't know. my pad registers with a 1-mm finger hover, so that's where a lot of my jitter comes from, its oversensitivity). Then we start moving the mouse cursor with no buttons held.
unless 2. It's actually a tap! This should be a different sixaxis oscillation but very distinct. Then we set a threshold where the first X seconds of data from the touchpad sensors when transitioning across the no-Touch to one-Touch boundary is given less contribution toward mouse motion. See here:
https://code.google.com/r/brianfundakows...66c1473#16
3. upon finger lift we perform dejitter based upon similar principals to what I just listed

Oh, and if it's a tap, we don't have to do anything really special. We register the tap after Touch1 has been set for X seconds/the sixaxis triggers, and then we maintain the leftdown until 3. is complete.
(03-11-2014, 05:46 PM)electrobrains Wrote: [ -> ]2. Finger hits pad clicks by pushing down until the switch hits. Cursor starts floating with finger motion and finger no longer has to keep the button down, just leave the finger on the pad and the drag will still occur. So push is a "drag" button.
I'm not sure if you mean that clicking the pad is now the only way to do a drag? Some people will map the pad click to something else, so I think the option to drag with a tap should still be there. Also, if the drag is made via pad click, I think it should be up to the user whether the mouse up occurs after the pad click finishes or after the pad touch finishes.

Edit: The drag could also be entirely determined by the second touch input (as you say, whichever of the two happens to move).

Edit 2: I'm actually just working on the notion that this jitter is in fact a problem for some people, I've never had any issues with it myself.
I just wanted to point out that Dark Souls, MKKE and most older games work flawlessly with the 1.1 beta3 and earlier.
Basically speaking, before "hide DS4 controller" option appeared all games worked well. But I personally store both versions due to much nicer GUI of the latter ones.
However most of the time only the latest incarnation of the utility recognizes my controllers, so I have to reboot PC sometimes to use older versions.
Hope this info may be useful to someone.
(03-11-2014, 07:11 PM)Eichhorn Wrote: [ -> ]I just wanted to point out that Dark Souls, MKKE and most older games work flawlessly with the 1.1 beta3 and earlier.
Basically speaking, before "hide DS4 controller" option appeared all games worked well. But I personally store both versions due to much nicer GUI of the latter ones.
However most of the time only the latest incarnation of the utility recognizes my controllers, so I have to reboot PC sometimes to use older versions.
Hope this info may be useful to someone.

It used to be the case that Hide DS4 was always on with no control over it,was hidden from user creating issues with uplay.
(03-11-2014, 07:15 PM)InhexSTER Wrote: [ -> ]It used to be the case that Hide DS4 was always on with no control over it,was hidden from user creating issues with uplay.

That's rather strange. When I use "Hide DS4" option MKKE, for example, shows my controller as a generic dinput one, resulting in inability to press more that one dpad button at a time, while older versions result in xbox360 controller being shown. If I don't use this option, however, I end up with expected double input.
With newer games, such as "Thief" and "South Park" there are no problems whatsoever, which I find to be rather strange.
IS it the same for you guys that the battery of the Controller runs out when it's not on use? for me the battery gets completly drained out if it's not on charging over night