Re: Expand of WG’s Target Input Devic es - related new chater

> I agree. But the very fact that the input data is between the mentioned  
> input
> devices (Joystick, Gamepad, and Racing wheels) are getting more and more
> aligned, I think it makes sense to group them into a single  
> specification that
> can cover all three.
>
> The catch here is probably the fact that analog input (analog sticks and  
> wheels,
> not buttons) won't fly on a event driven specification due to massive  
> amount of
> events that the listener will have to deal with. (unless the  
> specification strongly
> suggests usage of workers, but I'm a bit skeptical about that approach)
>
> A polling mechanism _could_ work, although not very elegant.
>

Opera's wiimote API is based on polling, and that is IMO the only decent  
solution for an analog input, while events are for discreet actions in  
time. A mix of both could work. The gamepad object being an event target  
would receive the "joystick" information and key events. The "joystick"  
part would be the analog part, the key events for the rest you know.

It does make sense to have one single unified API for all of these  
controllers. They all have some quantity of buttons and analog inputs, the  
way the controller is used (wheel vs. stick) is not of much interest to  
the API. The latter only needs to convey the information.

Received on Wednesday, 2 November 2011 12:34:18 UTC