Question about DualSense features

[grill2010]

I saw that there was a pull request 2 years ago

#1

I know that SDL2 can access the motion data and touchpad data but I guess these APIs are not (yet) accessible via Jamepad? Is this correct? For my application it's necassary to support this.

[MrStahlfelge]

Yes it is not accessible via jamepad - yet. Happy to review any PRs

[grill2010]

Okay will check it out. Which class is a good starting point to implement that feature? Did not yet check out the source code to be honest.

[Yontipon]

I'm not really an expert on this, but I think I have some information that will be useful to you, so I'll share what I know.

It sounds like you'll need to implement new native methods that interface with SDL. Assuming the device you're using registers as a "GameController", you'll probably be adding new methods to ControllerIndex.

https://github.com/libgdx/Jamepad/blob/master/src/main/java/com/studiohartman/jamepad/ControllerIndex.java

It uses gdx-jnigen, so the comments after the native methods are the actual code that gets compiled (I think it's either C or C++).

As far as what to put in the methods, you can find a reference of SDL functions here:

https://wiki.libsdl.org/SDL2/CategoryAPI

You'll probably want the functions that start with "GameController". Touch functions have "Touch" or "Touchpad" in the name. Motion seems to be handled with functions containing "Sensor". Sensors have 2 types: Accelerometer and Gyroscope.

https://wiki.libsdl.org/SDL2/SDL_SensorType

[MrStahlfelge]

In addition to what Yontipon wrote, I usually dig through the SDL sources. When you clone Jamepad locally, the sources are available.

[grill2010]

Okay thanks for the information, I will check it out when I have time. I found some examples in other repos which are already supporting some of that features, so I have some kind of reference here. I'm on Windows mainly what's the easiest way at the moment to compile Jamepad on my machine to test my changes?

[grill2010]

@MrStahlfelge saw the build instructions so I guess building takes place on Linux? Are these instructions up to date? I have of course some dev Linux machines as well, just my main dev PC runs on Windows. So if I start to play around with some features I will build them on Linux and will check if the features are working for my DualSense and DualShock controller and if they do I will make a pull request, would that work for you?

[MrStahlfelge]

Best is to take a look at the GitHub workflow file. It builds the snapshot and releases, so yes, it is up to date by definition. :)

Yes, that would work for me. Best is if you test on Linux and Windows at least. I don't own a controller with these special features myself to test. By the way, are you using libgdx/gdx-controllers?

[grill2010]

Okay will try to do that, features should be platform independent as far as I know though (and as far as I have seen on other repos which are using SDL2 for these features). No I'm not using libgdx for my project.

[MrStahlfelge]

Usually the features are platform-independant, yes. But it is always good to test :)

[grill2010]

I will test them of course as my application will be published for Windows and Linux

[Yontipon]

To clarify about the workflows and compiling: if you enable Actions in your Github fork, then push to the main branch, the workflow will automatically run and compile the natives. You can check the Actions tab to find the workflow run, and at the bottom it will have a file called "output-libs", which contains the jar with the natives in it.

The workflow run will always report that it fails, since it can't publish without the original credentials, but it gets far enough to compile the natives. If you want to work on a branch other than "main", you can edit the top of the workflow file to add the name of your branch to the list of branches it runs on.

[grill2010]

@Yontipon thanks, that would be a lot easier I guess. I think it's wort to get familiar with the GitHub actions then. All I want for now is to have a possibility to build and test the lib as fast as possible and this definitely sounds easier then doing it the manual way on my dev machines. Main branch is fine I guess for what I'm doing. So, as far as I have understood you correctly the GitHub actions will be able to build the lib which I can then use for testing but the overall job will fail as it can't publish the libs (as expected of course)?

[Yontipon]

Your understanding seems correct, except that the file produced by the workflow is only the native (C++) code. I believe that a complete jar, including the java code, would be uploaded if the publish script succeeded. There may be a way to get the full jar, but that's not what I did.

I was editing the project as part of an update to gdx-controllers. gdx-controllers uses Gradle to depend on the project, so to test changes, I depended on my local version of Jamepad's source code, and my downloaded copy of the compiled natives. The setup was a bit finicky, but I got by.

I can show you an example of a workflow run from my repository:

https://github.com/Yontipon/Jamepad/actions/runs/4865185521
(Note for the future: this link will break at some point.)

At the bottom, you can see that "output-libs" was produced. It's a zip that contains "Jamepad-2.26.5.0-SNAPSHOT-natives-desktop.jar", which is the natives I provided to make it work.

I was editing an existing Gradle project, so I never learned to set one up, but if you want, I can show you the changes I made to use my code locally.

[grill2010]

If you could show me of how you got it to work it will probably save me some time :)
I will start playing around with it soon so and like I said if I get quickly a test jar which I can test new features easily that would be great.

[Yontipon]

First, I put the two project folders in the same folder. In gdx-controllers (the project using Jamepad) created the "libs" folder, and I put the jar with the natives inside it.

In the file "settings.gradle" of gdx-controllers, I added:

include ':Jamepad'
project(':Jamepad').projectDir = new File('../Jamepad')

In the file "build.gradle" of the Desktop project of gdx-controllers (not the outer project), in the "dependencies" section, I replaced

api("com.badlogicgames.jamepad:jamepad:$jamepadVersion") {
exclude group: 'com.badlogicgames.gdx', module: 'gdx-jnigen-loader'
}

with

implementation files('libs/Jamepad-2.26.5.0-SNAPSHOT-natives-desktop.jar')
api project(":Jamepad")

I imported both projects in Eclipse (though it sound like people don't recommend Eclipse anymore). I know I also played around with adding the native jar as an external library to the Eclipse project, but I forget if that ended up being necessary.

After that, I was able to compile and run with my changes reflected. Note that you need to push to Github and download the natives again if you change any native code. You can check the files I mentioned in libgdx/gdx-controllers if you want to see more of what's in them.