[Android] Gamepad Support

So I’m trying to ship a game on Android soon with gamepad support. It mostly works, and kudos to the team for the fast work on that. But I had a few design questions about it that I need to work out in the next few days…

The buttons on Android seem pretty clearly labelled in the SDK, but the buttons are passed through in the numerical order as given in the SDK instead of corresponding to the Xbox 360 layout. I was under the impression that this was intentional, but the talk at Steam Dev Days seemed to indicate that this was just because the gamepad support was not finished yet. Is this the case, or is the intent to keep the current android button layout, and pass them on directly to the application? I need to make controller layout files soon, so this would be useful information.

The DPAD is driving me crazy. Currently it looks like the plan is to forward the DPAD events as hat stick events and swallow the actual DPAD digital button presses? After fighting with it for a bit, that honestly seems reasonable. But the controller mapping file doesn’t seem to support setting specific axis directions as digital buttons, so there’s no way of truly mimicking a 360 controller on Android with SDL right now. Is there any plan on how to handle this properly? For the time being, I am just forwarding the DPAD axis as button events on our end.

Axis IDs are simply swallowed, and the gamepad axes are sent to SDL in a semi-random order. Sorting the array by axis ID would seem to mimic the behaviour on other platforms, as they would have sequential ids. But it would really be nice to tell the application exactly what the axis is for… Perhaps a SDL_JoystickGetAxisID() function would be nice?

2014/1/20 dbrady

So I’m trying to ship a game on Android soon with gamepad support. It
mostly works, and kudos to the team for the fast work on that. But I had a
few design questions about it that I need to work out in the next few
days…

The buttons on Android seem pretty clearly labelled in the SDK, but the
buttons are passed through in the numerical order as given in the SDK
instead of corresponding to the Xbox 360 layout. I was under the impression
that this was intentional, but the talk at Steam Dev Days seemed to
indicate that this was just because the gamepad support was not finished
yet. Is this the case, or is the intent to keep the current android button
layout, and pass them on directly to the application? I need to make
controller layout files soon, so this would be useful information.

Gamepad support on Android is finished (there may be bugs though). What
gamepad are you referring to? What SDK and what labels? If you are using
the Game Controller API (and you should!), you need to create a mapping for
your gamepad. I’ve only ever tested this with a XBox 360 wireless receiver
and controller, and I had to hack around to get that working (at the
Android level since the only Android system I had with USB port didn’t come
with the right specs for the controller), and it seemed to work fine. We
ship a small app called “controllermap” in the test folder that you can use
on Android to create this mapping. You can build it quickly using the
build-scripts/androidbuild.sh script (see the README-android.txt file for
more details). To get at the actual mapping, you need to "adb logcat"
because that’s where the mapping is sent when you finish the process.

If you already did all this and you still are having problems, please let
me know (as I said, there may be bugs :slight_smile: )

The DPAD is driving me crazy. Currently it looks like the plan is to
forward the DPAD events as hat stick events and swallow the actual DPAD
digital button presses? After fighting with it for a bit, that honestly
seems reasonable. But the controller mapping file doesn’t seem to support
setting specific axis directions as digital buttons, so there’s no way of
truly mimicking a 360 controller on Android with SDL right now. Is there
any plan on how to handle this properly? For the time being, I am just
forwarding the DPAD axis as button events on our end.

This may be a bug, can you explain this in a bit more detail.–
Gabriel.

gabomdq wrote:

Gamepad support on Android is finished (there may be bugs though). What gamepad are you referring to? What SDK and what labels? If you are using the Game Controller API (and you should!), you need to create a mapping for your gamepad. I’ve only ever tested this with a XBox 360 wireless receiver and controller, and I had to hack around to get that working (at the Android level since the only Android system I had with USB port didn’t come with the right specs for the controller), and it seemed to work fine. We ship a small app called “controllermap” in the test folder that you can use on Android to create this mapping. You can build it quickly using the build-scripts/androidbuild.sh script (see the README-android.txt file for more details). To get at the actual mapping, you need to “adb logcat” because that’s where the mapping is sent when you finish the process.

If you already did all this and you still are having problems, please let me know (as I said, there may be bugs :slight_smile: )

I’ve not actually. And I’m just switching our code over to use the GameController API instead of the Joystick code we’ve been using (GameController rocks btw). I have attempted to create a mapping with the controllermap program, but it didn’t go well. The problem is that when you touch an analog stick or trigger, the mappings get screwed up. (I haven’t debugged it thoroughly yet, but I believe the problem is that all sticks are updated when you touch one, and it thinks that the triggers have moved because they have values of 0, instead of 0.5)

The button mappings seem messed up by default though. In SDL_sysjoystick.c, there’s a function called keycode_to_SDL. I would expect that this function would remap the android button IDs to the IDs that SDL expects by default (SDL_GameControllerButton), but it doesn’t, and that behaviour seems deliberate. It seems a bit awkward to me to have to provide gamecontroller mappings for every controller, even if it follows the android standard.

I’m using API 12, NDK9b, and I’ve tested the controller with a Nyko gamepad, Nvidia shield, and Ouya Controller.
?

gabomdq wrote:

This may be a bug, can you explain this in a bit more detail.
Gabriel.

Android behaves oddly with regards to the DPAD. When you press a button on the DPAD, it’s sent first as a hat stick motion event, then if false is returned from the motion handler, the event is sent to your onkey handler with the actual DPAD value. To make matters more interesting, the left stick behaves the same way. Since all motion events seem to be sent at once, it becomes a bit interesting separating the hat stick motion from the DPAD digital press. I don’t particularly want to get DPAD events for the left stick, so receiving the DPAD events as hat stick values seems like the best option, unless there’s some way that I haven’t found of identifying which stick caused the onkey event.

Okay, so now that I’ve rewritten the controller support in our game with the GameController API, I am starting to see the idea with that. I guess the idea is that we would only support controllers that are known to SDL, sort of like XInput. That makes a lot more sense, but I would still like the values coming in to map a bit easier even at the josytick level, given the youth of the android gamepad support. Would there be any objection to mapping the buttons to the SDL conventions by default?

I’ve created an enhancement request with a proposed patch. In general, the first 4 buttons usually correspond to something important on a game controller on any platform. Since they map to the DPAD on Android (which aren’t even sent), this results in a very sub-par user experience when falling back to the Joystick API on Android. I would really appreciate it if we could get this in.

https://bugzilla.libsdl.org/show_bug.cgi?id=2358

could you maybe please send your ouya controller mappings to Gabriel -
he maintains a database here:
https://raw.github.com/gabomdq/SDL_GameControllerDB/master/gamecontrollerdb.txt
Would be cool to get that in there.Am 22.01.2014 03:17, schrieb dbrady:

I’ve created an enhancement request with a proposed patch. In general,
the first 4 buttons usually correspond to something important on a
game controller on any platform. Since they map to the DPAD on Android
(which aren’t even sent), this results in a very sub-par user
experience when falling back to the Joystick API on Android. I would
really appreciate it if we could get this in.

https://bugzilla.libsdl.org/show_bug.cgi?id=2358


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

http://www.caveproductions.org
http://www.ufoai.org

2014/1/22, dbrady :

In general, the
first 4 buttons usually correspond to something important on a game
Since they map to the DPAD on Android (which
aren’t even sent), this results in a very sub-par user experience when
falling back to the Joystick API on Android.

Off-topic, but I had this exact same issue with 360 controllers, they
decided to make the D-pad map to the first four buttons instead to the
hat for whatever reason. GameController is not being of much help when
I need to make the UI respond to both GameController and
non-GameController joysticks properly! (not to mention it looks
horribly ugly in the control mapping screen)

Martin, I’m not sure that my controller mappings would be useful to anyone right now… I really want to see if SDL will accept my changes first, since those changes would change the button mappings for Android.