Re: [w3c/gamepad] Should fire events instead of using passive model (#4)

I have a use case that hasn't been precisely addressed yet: network gaming.  When my game detects a change in input state, I want to send that off as soon as possible.  I don't want to wait up to another 20ms (or whatever) for the game loop to pick it up and send it off.  I currently handle keyboard input outside the game loop and am wondering what to do about gamepads.  Latency is already bad enough across the web.  Why add to that?  Even more important than total latency is variation in latency.  Any polling solution (buffered or otherwise) adds to that variation.

I believe a proper gamepad solution would have the buttons performing just as well as keyboard keys (and/or mouse buttons) in regards to responsiveness, and can be implemented with the same coding patterns (events and/or polling).  Do that and you can stop second-guessing use cases.

Thus, while buffering events could solve the button-press-duration-sensitivity problem, it does not solve the responsiveness problem overall.  True, _most_ use cases will not need responsiveness tighter than a typical game loop interval, but that is no reason to ignore it either.

----

Personally, I don't see a good use case for analog-change events* and I've built a variety of games.  Yet, to be fair, I haven't looked at mouse-versus-gesture cases like others have, so I can't comment much on those details.

If a mouse fires positional events, then it makes sense a joystick should too... except for a possibly-important detail: potentiometers (joysticks) versus spinners (mice and trackballs).  Sure, the output may look similar in some floating-point-vector ways, but the source and meaning of the data is not similar.  Pots have extents, spinners do not.  (Ignoring touch pads/screens for now.)  Pots are notoriously much more twitchy producing spammy data (that should probably be smoothed as well).  Pots also often have centering springs attached which, well, just makes them more weird and noisy.  Thus, perhaps, if looking for an excuse to not tie joystick positioning to events, the origin of data from pots would be a good one.

* This does not include the case of using analog controls as digital controls, such as faking a button press when an analog value hits 0.5.  Such an action is fuzzy to begin with and the use case can tolerate additional slop from the poll timing.

Again, personally, if needing an event system for pot changes, I wouldn't be surprised if I needed to do that myself in a loop with a 1ms interval or whatever.  Then, I could also cache it, smooth it, or whatever else it needed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/4#issuecomment-757675909