Re: [AD] pressure support

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On 21 Feb 2010, at 9:14 , Elias Pschernig wrote:
> 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).

From one point of view, yes. :)
From another point of view, I want to write code that I can actually read and understand. ;)
It's true that when you have a fully customisable input screen where the user just selects controls and buttons for actions, then what happens in the game doesn't matter so much. That's quite a bit of code you have to write, test and implement first though. I agree it's something that all games should have (really), but it's not something I want to have to make before doing anything else.

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

Thing (with gestures) is that I don't see them as something that replaces something as generic as a button.
In a space shooter, say, I'd see a "rotate" gesture as something that would be an alternative to keyboard or gamepad based "arrow keys" for rotation. Ok, so I guess that means it would map onto an axis instead. Still, it's a different type of "axis" than a normal left/right or up/down 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.

Well, one thing is clear: we cannot have special events for all types of input peripherals out there. There's too many, and new ones get introduced all the time. So we do need to draw the line somewhere.
The question is how cleanly things map onto a "generic" input device.
We may need to strike a balance between "generic" and "particular". From a generic point of view, a rotation gesture or the pressure at the tip of a pen may be two very similar things: it's an event with an associated floatint point value (to indicate the amount of rotation, respectively the pressure on the tip of the pen). If I'm looking for a generic control scheme where I could replace one with the other, it makes sense to treat them the same (forgetting for the moment that pressure on a stylus probably comes with a pointer location value and a rotation gesture doesn't).
On the other hand, if I'm writing a program with the explicit intention of using a stylus (or a rotation gesture) as an input method, then such a generic interface is confusing and annoying.
I guess you're arguing from the first point of view whereas I'm more arguing from the second.

Anyway, I'd be happy with a keyboard/mouse/gamepad/other identification scheme if we can come up with a nice way to do it (and I don't think mapping things like rotation and pressure to an "axis" is it), even if "other" is really another name for "sortof gamepad".

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

Ok.

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

I like that better.

> Well, myself, I always thought that in any game, the controls should be
> completely up to the player, and *not* the programmer.

Yes...

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

Oh, no question of it. However, it's not typically the first thing I want to do when I write a program. I'd like to get something working first, and then improve it.
If I first need to program a generic and fully configurable input system I'll never actually start work on the game. While it may seem like a good idea to force people to do the correct thing from the beginning, doing so too strictly means you may turn away casual or beginning users - which isn't what we want to do.

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

Hardcoding joysticks is a bad thing to do anyway. I've always had different button mappings for my gamepads on Linux than on Windows (and DOS was different again, back in the day). :)

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

Well, truth be told, I have something similar (for A4, I haven't had time to port it to A5 yet). I have an abstraction layer that just tells me "player 1 pressed button to move left" or "player 2 pressed the 'action' button", where one of them might be using a gamepad and the other might be using the keyboard. Or they both use different gamepads. Or the same keyboard. Or one uses a mouse and the other a gamepad.
However, I think that's not an abstraction layer that should be forced on the user by Allegro.

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

I hear you. ;)
I don't think this needs to make it into 5.0, however - as long as 5.0 has something that we're all reasonably happy with. Afterall, we need to have something to put in 5.2 or there'd be no reason to continue development after 5.0 is reached (and in fact, 5.0 will never be reached).

I'll see if I can think of something that I'd be happy with and make a proposal.
For now, I'm thinking of something that will tell the user about an "action" with an associated value ("pressure", "rotation", "zoom factor") and an optional location (makes sense for stylus events, not so much for rotation or zoom - unless we simply report the current mouse position for those as well, I guess that might work). Not sure how that handles things like tilts (vector actions?) yet, but also something that allows me to ask for something specific (like a gesture, or a pen pressure event).

I'll think about it.

Evert