SDL2,SDL3: Use events to update gamepad inputs

[RT2Code]

Makes use of SDL events to update gamepad inputs on SDL2 and SDL3 backends. This way, inputs are only updated when required instead of systematically on every frame, and it provides the benefit of handling multiple input events between frames accurately, which should behave better on low framerates.

Apart from input update frequency, there should be no differences: Gamepad modes are supported, and events are merged between multiple gamepads if necessary. The only exception is how the ImGuiBackendFlags_HasGamepad flag is updated. I don't know if there was a specific reason for this or if it was an oversight, but currently, this flag is only updated if ImGuiConfigFlags_NavEnableGamepad is specified, which can lead to situations where there are gamepads connected but ImGuiBackendFlags_HasGamepad is not set. I changed it to always be updated, regardless of ImGuiConfigFlags_NavEnableGamepad status (but gamepad inputs are still not processed if it's not set of course).

[ocornut]

FYI historically I think gamepad inputs were gated by ImGuiConfigFlags_NavEnableGamepad partly because people had performances issues with gamepad access on some platforms. I'm not sure how relevant it is now.

Also linking to #8329 and #6559.

[ocornut]

FYI historically I think gamepad inputs were gated by ImGuiConfigFlags_NavEnableGamepad partly because people had performances issues with gamepad access on some platforms. I'm not sure how relevant it is now.

See #8075 for GLFW

[ocornut]

The only exception is how the ImGuiBackendFlags_HasGamepad flag is updated. I don't know if there was a specific reason for this or if it was an oversight, but currently, this flag is only updated if ImGuiConfigFlags_NavEnableGamepad is specified, which can lead to situations where there are gamepads connected but ImGuiBackendFlags_HasGamepad is not set. I changed it to always be updated, regardless of ImGuiConfigFlags_NavEnableGamepad status (but gamepad inputs are still not processed if it's not set of course).

For that part I have pushed 979c7d7 separately for SDL2, SDL3, OSX backends.
Actually submitting gamepad inputs.

I am a little worried about the potential effect of unstable/always changing analog inputs on input tricking code (ImGui::UpdateInputEvents()), it might in theory severely interfere with other inputs pretty badly. It will tend to set key_changed=true in that loop, and the order of events may have side effects.

[ocornut]

I am a little worried about the potential effect of unstable/always changing analog inputs on input tricking code (ImGui::UpdateInputEvents()), it might in theory severely interfere with other inputs pretty badly. It will tend to set key_changed=true in that loop, and the order of events may have side effects

Pushed a fix 102f3f3 for this + basic test ocornut/imgui_test_engine@99d4ed8

[RT2Code]

For that part I have pushed 979c7d7 separately for SDL2, SDL3, OSX backends. Actually submitting gamepad inputs.

Oh, I thought that disabling inputs with ImGuiConfigFlags_NavEnableGamepad off was done to actually disable the nav feature, I didn't think of it as two different things, but it effectively still makes sense to handle inputs even with the nav off. I updated my PR to emit input events even with ImGuiConfigFlags_NavEnableGamepad off.

I am a little worried about the potential effect of unstable/always changing analog inputs on input tricking code (ImGui::UpdateInputEvents()), it might in theory severely interfere with other inputs pretty badly. It will tend to set key_changed=true in that loop, and the order of events may have side effects

Pushed a fix 102f3f3 for this + basic test ocornut/imgui_test_engine@99d4ed8

Awesome, I would have suggested to only use events for gamepad buttons as a workaround, but this is better.