On Fri, May 3, 2013 at 6:03 PM, Ignaz Forster <ignaz.forster@xxxxxx> wrote:
> I don't think this will work as you expect it.
>
> Let's take my own gamepad adapter for example: You can connect PlayStation, Dreamcast and GameCube controllers to it. The Dreamcast controller has the A button on the bottom and the B button on the right side, the GameCube controller has the A button in the middle and the B button on the lower left side:
>
> | A | B | X | Y
> - ----------+--------+------------+-------+-----
> Dreamcast | bottom | right | left | top
> - ----------+--------+------------+-------+-----
> GameCube | middle | lower left | right | top
>
> In any case the A button is reported as the first button, the B button as the second one etc.
> Now the question is: Which button is BTN_WEST? You cannot tell, as it depends on what controller is connected.
Correct, What you're missing here is that as a game developer I
don't *care* what the labels are on the buttons or how those buttons
set bits on the wire, I care how they're laid out on the pad. I want
BTN_EAST to be generated by:
- B on the dreamcast controller
- Circle on ps/ps2/ps3 controllers
- B on xbox and xbox 360 controllers
- A on snes, n64, gamecube, wii classic and wii classic pro controllers
- A on ouya controllers
- green on gravis gamepad
All of these controllers have a four button layout under the
player's right thumb, with the buttons laid out at the compass points.
For all of them, the SOUTH and EAST buttons are the easy ones to
reach, and the NORTH and WEST are reachable but take slightly more
effort.
The gamecube controller is a slight anomaly in that it distorts
the layout, but seen in the context of the history of Nintendo
controllers it's obvious which button should be which. Every Nintendo
gamepad from the snes forward has had a cluster of four face buttons
that are (clockwise from the top) x, a, b, y.
Yes, there are some pads that don't map perfectly; the Dreamcast
controller has no right stick. The gamecube controller has two
shoulder triggers but only one shoulder button, no select button and
no system button. Those controllers just won't export those events.
The problem I'm trying to fix here is that at least for game
controllers the data coming out of evdev requrires a priori knowledge
about the controller plugged in, exactly as you say. And that's
horrible from a game development point of view. As a game developer,
I want to be able to say "BTN_SOUTH is shoot", and know that button
will be in more or less the same place on every reasonable gamepad.
Yes, this requires remapping to happen somewhere.
Right now, to make games on Linux that use a gamepad, I have to
manually remap every controller, and as far as I know nobody has a
database of *how* that remapping has to be done. Have you seen the
events a ps3 controller dumps? The right stick is ABS_Z for the x
axis, ABS_RZ for the Y axis. It spits out a massive stream of MT
events that I can only assume are mislabelled accelerometer data. And
that's a controller I can expect a lot of players to have.
My only recourse is to ship a game with support for all the
controllers I can find, and then wait for bug reports from angry
customers.
I want a standard that all gamepads conform to when reporting
data. Anything else is madness. There can be dispute about where
that standard is applied; whether it should be in-kernel or whether it
should be in some middle layer between the kernel and the world, but
without that standard mapping the data as currently reported is
essentially useless for non-toy projects.
There will be exception cases with hardware. If someone plugs in
a racing wheel or a DDR pad and tries to play a gamepad-based game,
they get what they get (which will hopefully be some controls working
but no incorrect control mappings). But for the standard case, where
they've got something resembling a standard gamepad (basically any
gamepad from the past three or four console generations, plus PC
gamepads) they'll get a standard mapping that can be explained with a
simple diagram.
> This may be a special case, but there are probably other controllers with "weird" button layouts out there (e.g. 6 button pads, the SNES pad, ...); moreover you don't have the guaranty that every gamepad has all the buttons you expect.
A controller can export the parts of the spec it can cover. Any
functionality beyond the standard controller can be exported as well,
and it would be nice if there was some sort of spec for that, but
that's not what I'm concerned with. What I'm concerned with is the
standard gamepad case, which covers (a) the use cases of nearly all
games, and (b) the hardware that most people actually have.
I've got a mouse that has only two buttons and no scroll wheel.
If I plug it in, it still works as a mouse, I just don't get a scroll
wheel or a middle button.
Razer makes a crazy 17 button MMO mouse with controllable DPI and
controllable color lighting. It works as a mouse too; maybe I don't
get access to all the buttons, and maybe I can't control the DPI or
the colors through the standard mechanism, but the parts that are
supported work as expected.
I want the same for gamepads. I want to know as a game developer
that if I follow the protocol then I'll get sane results on sane
hardware. Most users have sane hardware, so it covers most real-world
use nicely.
> To make it usable "out of the box" you would have to limit the interface to gamepads with a certain layout, but this will probably break if any of the major manufacturers decides to develop a new gamepad layout. Those "features specific to a gamepad" you are mentioning in another mail are probably everything that a gamepad has, as you can never be sure about it's layout ;-)
Likewise, why build roads when someone might make a flying car
some day? Sure, lots of people have cars and bikes and things *now*,
but...
Sure, five years from now we may be in a place where every gamepad
has a touchpad on the back (like the vita), maybe the C and Z buttons
come back, maybe accelerometers become more widespread. If that
happens, then maybe we talk about extending the spec to cover the new
functionality.
But right now we have a consensus amongst the platform
manufacturers about what constitutes a standard gamepad, and that
consensus has been pretty consistent for quite a while. There are a
hell of a lot of gamepads out there that can be fit into the model I'm
proposing without breaking the conceptual model. Remapping those
parts to a standard layout doesn't break anything else, either; if
something wants to use the full suite of sensors and buttons on the
ps3 controller, or some crazy future controller, it's all still there,
just mapped beyond the range of the standard events.
> While I totally agree that the situation is not ideal there is probably nothing to do about it. Using a default layout which fits for most controllers (these days probably the Xbox 360 controller layout) and offering some kind of ingame mapping to adjust it for non-standard controllers should be the way to go. You will have to offer an ingame remapping option anyway if you don't want to force your users to use your button mapping even if they may prefer another one.
There is an easy fix. Use a standard mapping where it applies and
where possible. That fixes tons of stuff here in reality where we
actually live, without breaking anything. Yes, games should in theory
allow remapping the controls, but it shouldn't have to be something
every player has to do in order to render the gamepad functional at
all. Expecting the developer to own a large cross-section of gamepad
hardware so they can expose sane mappings is unreasonable.
Would you find it acceptable (as a developer OR a user) if every
time you started a new program for the first time it brought up a
screen to configure your keyboard and mouse?
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
