Needing gamer advice
Cedron Apr 20, 2019
Hi,

First time poster here.

To begin with, I'm a programmer, not a gamer. (Simple difference in genre there?) I'm nearing completion on a EvDev wrapper shared library and a set of Gambas code files to make reading gamepads super simple in Gambas. I want the terminology I use to be gamer compatible/acceptable, so please correct any misuses I may commit.

For those of you who aren't familiar with it, Gambas is a dialect of BASIC language and IDE that is currently Linux specific. Very similar to VisualBasic, but a huge improvement. Since I am not a gamer, I am not in a position to judge how good of a game development platform it is, but for me and what I want to do, it will do just fine. (PPA: gambas-team/gambas3)

I've put a lot of effort into making the code "gamecontrollerdb.txt" and SDL2 name and file compatible. I've even included lookup arrays for SDL2 values. What I haven't found an answer to is where is the standard place for these configuration files to go. The only references I have found is "drop them in your game's asset (or executable) folder. This doesn't seem to be a very good approach to me.

This is how I decided to go:

ControllerDb File Search Order:
~/.local/share/GamePadDB/gamecontrollerdb_local.txt
~/.local/share/GamePadDB/gamecontrollerdb.txt
/usr/local/share/GamePadDB/gamecontrollerdb_local.txt
/usr/local/share/GamePadDB/gamecontrollerdb.txt

Files are searched in the order shown until a match is found on the GUID. The last definition in a file for a repeated GUID is used.

The first gamepad program I have allows you to define these configuration files by pressing the buttons on your gamepad and a few mouse clicks. It writes one line of results to the first file listed, so it will be found quickly by the first program running. (Yes, I know there are other programs with this functionality, but they don't demonstrate the use of my code.)

I'm also building in the ability to define custom "joystick response curves" on a per axis or per gamepad for a user/application basis. The files for those definitions will also be stored in these directories. So far, for the three different gamepads and the joystick I have, all the axis EvDev ranges are 0 to 255 with a flat value of 15. I am converting this to -32K to 32K to be compatible with the SDL (and other) values.

With all that as an explanation, I have these three questions:

1) Is there a standard directory location I should be using instead?

2) Is there a standard format for response curve definitions?

3) Does anyone know of a gamepad that has an axis return value that is not 0-255?

Thanks,

Ced
Cedron Apr 21, 2019
Thanks for the link. For my purposes, I think I am close enough. After a little thinking, I'm going to search in this order instead:

  • ~/.local/share/GamePadDB/gamecontrollerdb_local.txt

  • /usr/local/share/GamePadDB/gamecontrollerdb_local.txt

  • ~/.local/share/GamePadDB/gamecontrollerdb.txt

  • /usr/local/share/GamePadDB/gamecontrollerdb.txt



With the understanding that the best configuration is for any given system to just have the "/usr/local/share/GamePadDB/gamecontrollerdb_local.txt" file present. That is, a definition file following the format with only locally used gamepads included. Having the ~/.local directory available will allow somebody without administrator access to get a file defined and working.

As for the response curve (is that the correct term?) definitions, I am going with a simple text file with one value per line. If the number of values doesn't match the gamepad range, then the first and last lines will match the gamepad extremes and the interior values will be linearly interpolated. On the range scale, the min and max found values will be mapped to the min and max Axis Range values (-32K to 32K) with a linear mapping there as well. This is the simplest and most flexible format I can think of.

I am also curious if there are any X-Y mappings out there or needed.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.