TASEmulators
Sticky analog input is unusable in combination with mouse input
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
- Load an NDS rom (with default controller bindings)
- Load
NDS/StylusInputDisplay.lua - Enter
joypad.setanalog({["Touch X"]=10, ["Touch Y"]=10})in the Lua console - 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.
- 3af5b7a7f0ae512523eae4d93be150dde2384560 onwards (BizHawk 2.10+)
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?
From some old talks with zeromus, I don't thing 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
