CrazyRedMachine / LUFAHybridFightstick

Nintendo switch AND XInput controller for Arduino Leonardo and Pro Micro
GNU General Public License v3.0
54 stars 16 forks source link

Adds configurable SOCD cleaning and better default handling #4

Closed AshenColors closed 3 years ago

AshenColors commented 3 years ago

Currently, if an SOCD input is made, convert_dpad() isn't terribly happy about that. Since I use a hitbox-style DIY controller, I added handling for both the default case and (if the define is enabled) on-the-fly configuration. Stick players shouldn't see any changes, since joysticks can't make SOCD inputs.

I've been using this particular implementation for a while, and it seems to work okay — I can't perceive any additional input lag, although that comparison is made using amateur feel and not usblag. I've also tested it with Switch mode on my PC, and the output appears to be fine, but I don't have a Switch to perform further testing on.

I did my best to retain existing formatting, but vscode appears to be less picky with judging equivalent whitespace than github's online interface is and apologize for any mess.

CrazyRedMachine commented 3 years ago

hi, thanks for your contribution.

I'm not sure I understand why you'd want to make it configurable, socd should be banned and that's it...

Also it seems to me the switch code won't make socd inputs given this block : https://github.com/CrazyRedMachine/LUFAHybridFightstick/blob/155cc538f8d2d240b89af6a4cb3e0836c05318ee/XS_HID.c#L151

wouldn't it be easier to just write the equivalent for the xinput mode on line 112 ?

AshenColors commented 3 years ago

Right now, if left+right or up+down is input, both xinput and switch will always choose one direction over the other — up over down, and left over right, since that's the order the if/else handles them in. In addition, since the code is currently only looking for falling edge events, holding down both left+right and then releasing right will cause unexpected behavior — the normal expectation is that this would resume outputting left, but will instead output neutral until left is also released. This tends to be the least desirable default option over just outputting neutral (equivalent to x_socd_type = NEUTRAL; y_socd_type = NEUTRAL;)

SOCD cleaning is mostly of interest to those using a stickless controller setup instead of a joystick (that is, four push buttons, one for each joystick microswitch, which has ergonomic advantages for many people who experience pain with a traditional controller), since those allow the user to press left and right, or up and down, at the same time. Joysticks do not have this problem. Some games work better with a certain configuration than others: for instance, with your average 2D fighting game, UP+DOWN always resulting in sending only UP works well because that's how jumping works, but in an overhead-view shmup that has movement in all directions, UP+DOWN=NEUTRAL works better.

This particular configuration scheme is equivalent to the options offered by the Bit Bang Gaming Magicians SOCD cleaner, which is the current gold standard in tournament-legal configurable SOCD cleaning. Brook boards (and most commercially sold encoders these days, I think) also include either fixed or configurable graceful handling of SOCD inputs. If this is out of scope, the request can just be closed out, although at the very least I would still recommend putting something like if (internalButtonStatus[BUTTONUP] && internalButtonStatus[BUTTONDOWN]) internalButtonStatus[BUTTONUP] = internalButtonStatus[BUTTONDOWN] = false; where the calls to clean_socd() currently are.