JamepadController Usage

[klianc09]

Hi!
I'd like to use the 'desktop-jamepad' project to get all controllers correctly mapped automatically.
But I don't understand how I can do this, since I still need to access the buttons by id, since it is just a wrapper over the libgdx controllers interface.

Digging into the code I saw that there exists a JamepadController, but I'm still not sure what is the intended way to access gamepad buttons independent of hardware button id mapping.

Any help or pointers would be highly appreciated.

PS: Also would like to know if it could work with the LWJGL3 backend too, or if LWJGL2 backend is required. I can open a separate issue for this if preferred.

[MrStahlfelge]

It is correct that you have to deal with button and axis ids, because libGDX does it this way. The id's are mapped to Jamepad's constants. You can find the list of available axis and buttons in Jamepad's ControllerAxis and ControllerButton classes:

Axis:

LEFTX,
LEFTY,
RIGHTX,
RIGHTY,
TRIGGERLEFT,
TRIGGERRIGHT;

So axis id 0 is Jamepad's LEFTX, axis 1 is LEFTY and so on.

Buttons:

A,
B,
X,
Y,
BACK,
GUIDE,
START,
LEFTSTICK,
RIGHTSTICK,
LEFTBUMPER,
RIGHTBUMPER,
DPAD_UP,
DPAD_DOWN,
DPAD_LEFT,
DPAD_RIGHT;

Button 0 is A, button 1 is B and so on. Jamepads (or better SDL's) database handles the mapping from hardware to the constants. It is quite the same as on the GWT backend. (You will find some more information and links on the mapping documentation).

Jamepad should work without problems with LWJGL3, just try. But the LWJGL3 controller implementation supports hotplugging itself so the need for replacing libGDX' own solution is not as urging.

[klianc09]

Thanks for your quick answer!

I see now, that's what that line in the mapping documentation is meant to mean. That's not obvious at all. Would be great to add this explanation to the desktop-jamepad wiki page. I never used controllers with GWT so I have no frame of reference there.

I was asking about LWJGL3, because I tried and it didn't work. But it's an easy fix, since LWJGL3 just tries to instantiate a different ControllerManager. I can make a pull request if you like but essentially it is just adding this file:

package com.badlogic.gdx.controllers.lwjgl3;

import de.golfgl.gdx.controllers.jamepad.JamepadControllerManager;

public class Lwjgl3ControllerManager extends JamepadControllerManager {
}

I initially only switched to LWJGL3 backend to get hotplugging, but it still doesn't do automatic remapping, so I still see an urging reason to use jamepad instead. But now I'm at least free to switch back to LWJGL2 backend, if the LWJGL3 backend creates problems.

The only issue I encountered so far is, that hotplugging doesn't work on Linux. But this should be an issue with jamepad itself and not this gdx controller extension. And losing hotplugging support for Linux seems a much smaller evil than having to worry about manually mapping all gamepad buttons.

[MrStahlfelge]

Added it to to the wiki under work to be done because I think adding core constants is the correct way to go.

Feel free to make a PR for the change. It's indeed the same trick as done for Lwjgl2, but I'd prefer if you commit your tested and wortking version.

[klianc09]

That addition to the wiki is great.

Regarding the Lwjgl3 fix, I only created the class inside my own project to fix it.
I tried to fork and add to the project to test it, but I'm having issues to get the project to build, so I can only offer an untested PR at the moment. Sorry.

[MrStahlfelge]

What's the problem, it should build on your system. Anyway, if you provide a PR, Travis will also do the build and check if it is compileable.

[klianc09]

Yeah, for some reason gradle would keep telling me I need the 'android-25' sdk although I already had it installed. Re-opening the project today suddenly fixed the error *shrug*. Anyway, I made the pull request.

[MrStahlfelge]

Thanks. New snapshot is published. I'm closing this for now.