Re: [AD] pressure support

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On 20 Feb 2010, at 21:15 , Elias Pschernig wrote:
> I never looked at it much before, but our joystick API can already do it
> all. For example for a drawing tablet, al_get_joystick_name() would
> return
> 
> "pen", "eraser"
> 
> for its two "sticks". And al_get_joystick_axis_name() could return, for
> 5 "axes" of each "stick":
> 
> "x-position", "y-position", "pressure", "x-tilt", "y-tilt"
> 
> Each gestures of an OSX touch pad would similarly be an axis with an
> appropriate name.
> 
> So I'd say, we rename all our al_*_joystick_* functions to
> al_*_input_device_* functions. Instead of multiple "sticks" we have
> multiple "devices". Same for events - ALLEGRO_EVENT_JOYSTICK_AXIS gets
> ALLEGRO_EVENT_INPUT_DEVICE_AXIS, and so on.
> 
> Then it's just a matter of all the different drivers implementing the
> new vtables for whatever underlying devices can be reported. I volunteer
> to rename... I mean implement it for iphone, instead of a 3-axis
> joystick the accelerometer will be a 3-axis input device :) Maybe can
> also add a single button to it which is reported as pressed when we
> receive a shake event.

I can't convince myself. On the face of it it makes sense to map things like trackpads and tablets to joysticks - even a mouse can be mapped onto the joystick API if we wanted to, and treating things that are, in a sense, similar in the same way seems sensible.
And yet.

One of the things I don't like about it (maybe the main thing) is the extra abstraction. My laptop has a keyboard and a trackpad. When I use it at my desk at home I plug in a mouse and a keyboard and when I play a game I may plug in a gamepad. When I want to read input from any of these devices in an Allegro program, I want to know when a "mouse button" is pressed, or what's happening with "the gamepad". I don't want to ask for the status of "button 3" on "input device 2" if I want to know about the middle mouse button. Similarly I want to ask about "joystick 2" rather than "input device 4".
By the same token, if I wanted to know about the pressure on the tip of a pen (a scalar quantity) then I don't want to have to check which axis (something that my mind links with a vector quantity) represents "pressure" and check that one.
Admittedly, treating a tablet and stylus as a mouse is almost as arbitrary as treating it as a gamepad. I guess in practice you use a tablet and stylus more as you would a mouse than a gamepad, which is some justification for pretending it's a mouse (plus Apple's API actually generates mouse events for tablet/stylus actions - I don't know if you could even tell them apart easily).

The extra layer of abstraction is also what I don't like about identifying gestures with buttons or axes. I would find an API that makes this identification very clunky and confusing, more so because these things physically *aren't* buttons or axes. I think novice users would find this even more confusing. Similarly for identifying a "shake" event on an iPhone ("shake event", seriously?) with a button press event. I'd personally prefer adding an "ALLEGRO_JOYSTICK_SHAKE" or "ALLEGRO_IPHONE_DROPPED" event just for that. Sure, it means the user needs to stick in an extra event if they want to have their game respond to a particular type of input on an iPhone and they'll need to come up with an alternative control scheme on the non-iPhone port of their game. In practice that may be what they'd need to do anyway and they can always say "if (left_mouse_button_down || iphone_shook)".

Still. We might be able to have a bit of both, say a "generic" input device that generates "generic" input device events. Or, if it's a joystick, we can tell it to generate "joystick" events. Or one could be an alias for the other. That would require some thought though. Or we use such a system internally but still tell the user about "joysticks".

On the topic of our joystick events. I guess you could actually map something like a Wii controller onto them without extra work or difficulty. That's pretty neat.

Evert