Hi,
Is it possible to use a gamepad on Windows? If I understand correctly, the mapping is read from /usr/share/sdl/gamecontrollerdb.txt and this is hard coded. Would it be possible try loading it from the working directory as well and fallback to a system path if no local config exists? Or is there a simpler way that I could try?
Thanks,
Stefan
which gamepad is this? the gamecontrollerdb.txt is only required for new devices that didn’t make their way into the glfw release. mostly they should be supported out of the box (you have to enable joysticks in the config.rc though).
pushed some code that looks in the cwd first, hth. haven’t tried gamepads on windows myself.
It’s an 8bitdo pro 3. When starting vkdt, the log shows
[gui] found gamepad Xbox Controller
In vkdt some buttons work (like selecting, rating, etc.) but the joysticks do not work and i can’t change parameters or bring up the help overlay with the mappings.
i see. okay, will be a few more minutes before the github ci builds new windows binaries in case you’re not building from source yourself. let me know if it manages to pick up the full definition from the text file.
Thank you! I see now that the config file is picked up, but still the controller is identified as a Xbox Controller.
[gui] loading additional gamepad maps from gamecontrollerdb
[gui] found gamepad Xbox Controller
Do you have an idea why it would be identified wrongly?
What have you set the switch on the back to?
I think it’s normal that the 8bitdos identify as Xbox, Dualshock or Switch Pro Controller, depending on the chosen mode. For me, the D mode shows my Pro 2 controller as 8bitdo Pro to my Linux.
I had it set to S/X. In Windows it then shows up in joy.cpl as “Controller (8BitDo Pro 3)”. This is then recognized in vkdt as Xbox Controller, but the joysticks don’t function. When swtiching to D mode, it shows up as “8BitDo Pro 3” in Windows, but no gamepad is found in vkdt. In S mode, Windows and vkdt show a “Pro Controller”, but no button or joystick work.
sorry i can’t help much with windows, and also don’t have this controller to test. good to hear at least the file is parsed now. apparently there are sometimes issues with different device ids on windows, maybe it’s possible to grab the id and insert a custom entry in some hax0red gamecontrollerdb.txt?
It may be related to this issue: glfwJoystickIsGamepad returns false for an Xbox Wireless Controller · Issue #2797 · glfw/glfw · GitHub.
I added the following code for the gamepad check:
if (glfwJoystickPresent(js))
{
const char* name = glfwGetJoystickName(js);
const char* guid = glfwGetJoystickGUID(js);
int is_gamepad = glfwJoystickIsGamepad(js);
printf("Joystick %d:\n", js);
printf(" Name: %s\n", name ? name : "Unknown");
printf(" GUID: %s\n", guid ? guid : "NULL");
printf(" IsGamepad: %d\n", is_gamepad);
printf("\n");
}
which returns for the controller in D mode:
Joystick 0:
Name: 8BitDo Pro 3
GUID: 03000000c82d00000960000000000000
IsGamepad: 0
The GUID matches the one in gamecontrollerdb.txt, but somehow it is not recognized as gamepad and then vkdt skips it. But also when removing the check to force vkdt to use it, the controls do not work.
hm if it’s in the text file and the entry looks correct, maybe it’s not read in correctly? since you’re compiling… do you have a chance to compile glfw too? with an updated db, say, or place a print somewhere that can prove or disprove that the GUID and button mapping actually made it inside?
I chaged the way the gamecontrollerdb.txt (taken from GitHub - mdqinc/SDL_GameControllerDB: A community sourced database of game controller mappings to be used with SDL Game Controller functionality) is read to
FILE *f = fopen("gamecontrollerdb.txt", "rb");
and
fseek(f, 0, SEEK_END);
long sz = ftell(f);
rewind(f);
char *buf = malloc(sz+1);
fread(buf, 1, sz, f);
fclose(f);
buf[sz] = 0;
dt_log(s_log_gui, "loading additional gamepad maps from gamecontrollerdb");
after which the controller is identified as a gamepad by glfwJoystickIsGamepad(js);.
But still the joysticks do not work.
progress 
oh man windows again.
glfw comes with a joystick test utility. if i build glfw from source, i have a build/tests/joysticks program that displays all sorts of things as joysticks (including my keyboard). but it is very clear at which joystick has gampad mappings and also shows all axes. if i understand the code correctly, you can drag+drop a gamecontrollerdb.txt file onto it to make it parse the updated description. does that thing work with your gamepad?
With that test program compiled from master and the gamecontrollerdb.txt it shows as gamepad and all buttons and axes seem to function. In vkdt somehow the joysticks don’t do anything. When I zoom in however, pressing the left joystick does reset the zoom. So it seems just the axes are not picked up somehow?
and you’re sure you’re looking at the gamepad state and not the generic joystick axes in the program? i.e. the ones at the bottom, below the gamepad state label:
Yes,
Could it simply be that my system is too slow to deal with the rendering and picking up the behavior? I’m testing currently on a Intel Ultra 7 155U without dedicated GPU, although dragging the slider is fluent…
using the sticks to navigate through the image in dr mode should be instant, that doesn’t incur any actual image processing. i’m using exactly the same axes on the gamepad struct as this joystick tester. there is a deadzone of 0.05 that axes need to jump over before the event is passed on, but your screenshot looks like this is safely exceeded.
i don’t think i have an intuition what might be going on. i’d probably put a few printouts in dt_view_gamepad() and gamepad_changed() to see the value of a few gamepad state axes[] and trace back from there where the signal is lost.
When I add debug messages to gamepad_changed(), I can use the joysticks as expected. The function now looks like
static inline int
gamepad_changed(
GLFWgamepadstate *last,
GLFWgamepadstate *curr)
{
int changed = 0;
// check buttons
for(int i = 0; i < 15; i++)
{
if(curr->buttons[i] != last->buttons[i])
{
printf("button %d changed: %d -> %d\n",
i, last->buttons[i], curr->buttons[i]);
changed = 1;
}
}
// print all axes
printf("axes:\n");
for(int i = 0; i < 6; i++)
{
printf(" axis %d = %f\n", i, curr->axes[i]);
}
float deadzone = 0.05f;
if(fabsf(curr->axes[GLFW_GAMEPAD_AXIS_LEFT_X]) > deadzone) changed = 1;
if(fabsf(curr->axes[GLFW_GAMEPAD_AXIS_LEFT_Y]) > deadzone) changed = 1;
if(fabsf(curr->axes[GLFW_GAMEPAD_AXIS_RIGHT_X]) > deadzone) changed = 1;
if(fabsf(curr->axes[GLFW_GAMEPAD_AXIS_RIGHT_Y]) > deadzone) changed = 1;
if(curr->axes[GLFW_GAMEPAD_AXIS_LEFT_TRIGGER] > deadzone) changed = 1;
if(curr->axes[GLFW_GAMEPAD_AXIS_RIGHT_TRIGGER] > deadzone) changed = 1;
return changed;
}
This spams the terminal with messages like
axes:
axis 0 = -0.007797
axis 1 = -0.007797
axis 2 = -0.007797
axis 3 = -0.007797
axis 4 = -1.000000
axis 5 = -1.000000
Is it possible that the update loop breaks/always reports a change because the triggers are always reported as -1 (beyond the deadzone)?
uhm did you also change something else? i may be blind but this function looks semantically equivalent to the current version, with added printouts and deferred return.
oh, i didn’t consider the triggers start at -1 instead of 0. anyways that only makes it a veeery large deadzone and wouldn’t affect the code flow for the other axes?
i was thinking maybe it’s a weird interaction with the gui going to sleep when idle? as opposed to actual game engines, vkdt doesn’t always poll/refresh but only in case input events take place. for gamepads there is the unfortunate situtation that this requires an extra polling thread. maybe this one quits maybe like here just before the new gamepad descriptions are loaded? looking at the order of things this shouldn’t be possibe though.
thanks for all the deep dive debugging so far! this is really helpful because i can’t reproduce this case here.
No, this was the only change. When reverting the change, the joysticks don’t function again.
Is glfw threadsafe or could there be a race condition between the joystick thread and main thread that somehow works with the additional print statements?
argh you’re right:
Thread safety
This function must only be called from the main thread.