Sticky analog input is unusable in combination with mouse input

[kalimag]

Summary

(follow up on a question in the scripting channel by tortoiseplaysvr)

Sticky input (used by the virtual pad, joypad.setanalog etc.) is applied with the XorAdapter, which is forcing the axis to its neutral value if both the regular input and the sticky input are non-neutral. Mouse inputs are basically never neutral unless the mouse is very precisely positioned at the center point, so it's effective unusable. This particularly affects NDS touch input (which has mouse bindings by default), and potentially other systems (e.g. DOSBox). The only workaround seems to be unbinding the mouse.

Not sure what to do about this, maybe it's just "working as intended", but it seems very inconvenient and unintuitive. At least Lua/tools should be able to force specific input.

Repro

1. Load an NDS rom (with default controller bindings)
2. Load NDS/StylusInputDisplay.lua
3. Enter joypad.setanalog({["Touch X"]=10, ["Touch Y"]=10}) in the Lua console
4. Crosshair will be stuck in the center of the bottom screen, unless the mouse is positioned exactly over the X/Y center of the touchscreen

Host env.

• 3af5b7a onwards (BizHawk 2.10+)

[Morilli]

Yeah xor logic for axis values is questionable at best, I'm not sure there is one "right" implementation.
The previous logic effectively applied or logic for axis inputs, aka autofire axis value (even if neutral) (if that could even be set with the existing UI) OR autohold axis value OR user axis value. We could change the logic to do that (even though that makes no sense with the current naming, but whatever), but that would cause neutral stickies to be treated the same as no sticky at all, aka ignored. We could potentially make AxisValue nullable to solve that and deal with the fallback everywhere else.

Regardless of those fun considerations above, I think the main issue is that mouse input is unconditionally applied when bound and you can't really "not" input (except by putting the mouse in the exact middle of the screen). It's an unfortunate side-effect of using the mouse position as input axis. It doesn't help that for touchscreens, the "neutral" value has no semantic meaning either.

Nobody would complain about the xor logic for normal buttons because you can't "accidentally hold B", but I wonder if xor logic is even useful here. Is there some (useful) advantage to having user input be xord instead of `or´d with sticky input?

[vadosnaprimer]

From some old talks with zeromus, I don't think analog values were ever seriously meant for those autohold/autofire patters, because those patterns make no sense for them. There's no 2 default values to be switching between, and neutral value is still some value as well, and there's no default non-neutral value.

Maybe those adapters should not even be a thing with analog inputs? @CasualPokePlayer @zeromus

[ThomasR95]

Adding to this, still present in version 2.11.2 - no method (in Lua) of setting the "Touch X" or "Touch Y" on the joypad has any effect unless you unbind the mouse from the controller Touch, Touch X and Touch Y controls.

[SuuperW]

The button values set with joypad.set behave different. They are overridden when set to true (not XOR) and do nothing when set to false (you cannot make a button be unpressed if the user is holding it). Also, any buttons that are set are only applied until the next frame. The analog method should behave similar to the button method for that last point: it should only apply until the next frame. (Unless we decide buttons should also persist.)

Before fixing the analog, I think we should decide how buttons should work. Being unable to force it off means the API is buggy or at least incomplete. Since Lua doesn't have a sensible value we can set to clear a button (assigning nil removes the key from the table), I propose we split joypad.set into three methods.

• joypad.set_on(array-like table): the parameter lists the names of buttons that should be held
• joypad.set_off(array-like table): the parameter lists the names of buttons that should be forced unheld
• joypad.unset(array-like table): the parameter lists the names of buttons that should be cleared/unset, returning control of them to the user
  each method could also have the optional controller parameter that set currently has.

These three methods have clear analog versions that could be implemented. (on and off variants would just need to be combined into one, that takes a value as parameter or a table with analog names as keys and their values as table values. which, the button variants could do that too and maybe that makes more sense)

[RetroEdit]

[joypad.set button values] are overridden when set to true (not XOR) and do nothing when set to false (you cannot make a button be unpressed if the user is holding it).

This is wrong. From a test just now of BizHawk 2.11.1 and experience with prior versions, any button values explicitly provided to joypad.set override user input. So if true, the button will be pressed, and if false, it will be unpressed. (Buttons pressed by the user that were omitted in the latest joypad.set call on that frame will still be received.)

So with that in mind, I'm decidedly against adding joypad.set_on and joypad.set_off.

I'm also not sure adding a joypad.unset API is strictly necessary because it seems like it could be avoided by Lua script authors not calling joypad.set until they're absolutely sure of the buttons they want set for that frame. But maybe it's still useful for other reasons? Or wait, each joypad.set call resets the entire state, so it effectively acts as an "unset" for buttons that are absent. So the current API does allow unsetting.

[YoshiRulz]

WTF are you on about? There's already an unset mechanism for both axes and buttons. It's even documented.

OP is describing a bug where, in the case where an axis is both set sticky via the API / Virtual Pads and bound to a joystick, any inputs on the stick will result in a neutral effective value, and returning the stick to neutral will make the effective value jump to the sticky value.