Re: [AD] pressure support

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Sat, 2010-02-20 at 23:44 -0500, Evert Glebbeek wrote:
> 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.

Why? It's enough if the user of your game knows (by displaying a name
string of the device, which is the device name ("gameplad") and
axis/button name ("pressure") - but in the end, just a string).

If I make a game, I'll for example map it to mouse and keyboard. Since I
develop it in Linux, there's no way I'd code in support for gestures.
However, I always provide a config screen where the user can select any
game action and then map it to arbitrary inputs by pressing a
button/moving an axis.

If we had support for generic input devices for everything besides
keyboard, mouse and joystick, it means when coding a game what I have to
do is:

- check keyboard
- check mouse
- check joysticks
- check other devices

This is hard enough, but at least a finite task - I don't have to hunt
the documentation for each possible event and input devices, which in
the end is just a rename of the joystick buttons/axis we already have.

It will even keep working once we add support for additional devices in
the future as such devices can be added without requiring any extra
structs or events or enums - they are just a button or axis with a
string name which is displayed to the user.

With using explicit, hard-coded A5 events it's impossible to write my
game in a way so it can deal with a future device.

> 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).

Yes, my thinking is, we provide keyboard, mouse and joystick in Allegro.
And map everything else to generic devices (and not one of those three).

> 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.

That's just a naming issue then. We can call both "action" with a
floating point value. A button would then simply set it to 0 or 1 and an
axis work like now.

> 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)".

Well, myself, I always thought that in any game, the controls should be
completely up to the player, and *not* the programmer. As a programmer,
it means more work of course, since you need to code in an input config
screen. But for the player, it's much nicer. I always hated it when I
had to change the keyboard layout to English because someone hardcoded
x/z for left/right - or worse if someone hardcoded a joystick for a game
which was perfectly playable with keyboard and mouse.

So myself, I would in fact prefer generic input events even to our
keyboard and mouse events. It's what I'm doing in my A5 wrapper (my
former A4 wrapper). I just get an input event which is mapped by the
user - I never want to know if this comes from the keyboard or mouse or
joystick. It simply comes from the config file.

> 
> 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".
> 

Yes, it sure would be nice to have both. If you register a generic input
device, you get generic events (say when coding the input config
screen). But if you register a mouse or keyboard (or even gesture
source) then it works with a hard-coded API.

In practice, I don't think I'm up right now to code that in though...
writing mails here about it is probably as much as I have time for.

> 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.
> 

Yeah, I think yesterday is the first time I realized that, it's a really
nice API we've got for joysticks :)

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>