Added DirectInput support. #174

KungPhoo · 2025-06-26T06:57:12Z

The gamepads are polled into the indices [4..]
so it doesn't break backwards compatibility.

The gamepads are polled into the indices [4..] so it doesn't break backwards compatibility.

f1nalspace · 2025-06-27T06:07:09Z

Thanks for creating a MR for DInput, i really appreciate that!

I looked at the source and it needs a bit of work to make it production ready:

Spacings needs to be real tabs, not spaces (\t) to match the source
We need a "fplGamepadBackendType" enum to control which gamepad backend the users wants:
- fplGamepadBackendType_Auto = 0; -> Automatic detection, use the first one that works
- fplGamepadBackendType_XInput (Preferred over DInput)
- fplGamepadBackendType_DirectInput
- fplGamepadBackendType_Linux
Add the enum to the fplInputSettings structure with a simple field "fplInputBackendType backendType" with default of "fplGamepadBackendType_Auto".
Current gamepad backend type can be stored in fpl__PlatformWindowState, so FPL knows which one to use
Only poll for the current gamepad backend, do not query XInput when DInput is active!
XInput is preferred over DInput when backend type is set to Auto
Linux backend will be automatically be selected on (Auto) when the platform is linux
Some namings of global functions, types or constants needs to be consistent and match fpl syntax, add at least fpl_ or FPL_ prefix to not collide with other API's

f1nalspace

DInput needs to be separate from XInput, using both is dangerous and may be unstable using the same controller on both api's. Also it should not break backwards compability and XInput is preferred over DInput. Therefore adding a backend type enum and its own states is a better approach.

I can prepare that for you if you want, but i would do that in its own branch on master.

Also ensure that namings are correct everywhere, so it doesn't collide with other api's, especially for IID constants or other defines.

Fore more details see the comments for certain code blocks.

f1nalspace · 2025-06-27T05:56:01Z

final_platform_layer.h

 			fplClearStruct(outStates);
 			for (DWORD controllerIndex = 0; controllerIndex < XUSER_MAX_COUNT; ++controllerIndex) {
 				XINPUT_STATE controllerState = fplZeroInit;
+            auto rv = xinputState->xinputApi.XInputGetState(controllerIndex, &controllerState);


No auto! Its not a C++ library!

Sorry. bad habbit.

f1nalspace · 2025-06-27T06:10:57Z

final_platform_layer.h

+#if defined(FPL_PLATFORM_WINDOWS)
+#include <xinput.h> // XUSER_MAX_COUNT
+#else
+#define XUSER_MAX_COUNT 4


Do not include XInput here, just change the FPL_MAX_GAMEPAD_STATE_COUNT to 8, so it is sufficient for XInput or DInput gamepad backends.

Also seperate both states, xinput has its own states and dinputs has its own states, even though indexing it with 4 was a good idea. But i would rather have them separate, see my other comments below.

f1nalspace · 2025-06-27T06:12:17Z

final_platform_layer.h

+#define DIRECTINPUT_VERSION 0x0800
+#endif
+#include <dinput.h>
+#if defined(FPL_IMPLEMENTATION)


Use win32 video software backend as an example, how the implementation is defines and where it is located.

I don't understand that. Can you give me some pointers?

f1nalspace · 2025-06-27T06:13:27Z

final_platform_layer.h

+            ctrl->device->Acquire();
+            ctrl->instanceGuid = instance->guidInstance;
+            ctrl->productGuid = instance->guidProduct;
+            wcsncpy_s(ctrl->name, instance->tszProductName, _TRUNCATE);


Do not use WCSNCPY, use fplWideStringToUTF8String() or (fplUTF8StringToWideString) instead.

f1nalspace · 2025-06-27T09:52:19Z

I started a new branch, that origins from develop that prepares for having multiple game controller backends:
https://github.com/f1nalspace/final_game_tech/tree/dev/gamepad-input-backends

It will be similar to the video/audio backend system, but much easier to implement because it has just a couple of functions and states.

I will comment here, when this system is merged in the develop branch.

KungPhoo · 2025-07-01T04:08:38Z

The spacing is a problem. My IDE auto-formats on save. Maybe you consider providing a .clang-format file with the code?
I put the controllers after the 4 XInput devices, because I thought people might have older DirectInput devices and XInput controllers at the same time. I don't have an XInput to test. Does it show as DirectInput as well? Selecting the backend at compile time it a very hard descission.
I have not found a global function that doesn't start with fpl. Did I miss one?

f1nalspace · 2025-07-05T06:39:34Z

The spacing is a problem. My IDE auto-formats on save. Maybe you consider providing a .clang-format file with the code?

I put the controllers after the 4 XInput devices, because I thought people might have older DirectInput devices and XInput controllers at the same time. I don't have an XInput to test. Does it show as DirectInput as well? Selecting the backend at compile time it a very hard descission.

I have not found a global function that doesn't start with fpl. Did I miss one?

After thinking it through, it is a very good idea to support both XInput and DInput using 0-3 for XInput and 4-11 for direct input.
Therefore i dropped the idea of adding another backend layer over it. I will checkout your MR and try to put it into the develop branch. I would love to merge it into master, but the master branch is meant to be the stable and the production branch - which is always based on the released version. But this may change in the future, because it breaks the defaults of how open source projects with git typical are defined.

The spacing is special in FPL, because i want to save as much as "chars" as possible. There are a lot of indentation in FPL going on - therefore i use a single tab character \t instead of 2/4/6 space characters (this saves a lot of memory!). Also each editor has its own number of spaces to visualize a tab-control, which is another reason why i use tabs instead.

Regarding the formatting of FPL, i use visual studio 2022 C++ formatting rules which i adjusted a bit, because i don't like certain defaults in there. But i don't auto format everything, just a couple of selected lines! Occasionally i run the VC++ auto formatter to clean up over the full source, but even the current master would have a ton of changes when i do that.

Maybe i will create formatting guideline document for the FPL code style, so we can create a .EditorConfig or .clang-format file from that.

Each global variable is defined as "fpl_globalvar" and has the prefix "fpl__global_whateverTheNameIs".

f1nalspace · 2025-07-05T06:59:12Z

I added a .editorconfig file. Feel free to generate a clang-format config for that.

https://github.com/f1nalspace/final_game_tech/blob/develop/.editorconfig

Also i reformatted FPL in the develop branch. So it matches that editor config.

f1nalspace

I checked out your pull request into a new branch, but i can't compile it. There are just too many errors to fix. So i extracted the DInput part and put it directly into the develop branch.
Will report back when this is done, so we can close that pull request.

KungPhoo · 2025-07-06T12:34:41Z

Sorry for generating so much work. I'm quite new to git etc.

Make sure you check the joypad name in DirectInput. I think I didn't map it at all and it's a nullptr. (I had no need for it in my project).

With Visual Studio 2022, when you add a .clang-format file, Visual Studio will automatically use it for reformating, when you save the file.

Added DirectInput support.

34e9f54

The gamepads are polled into the indices [4..] so it doesn't break backwards compatibility.

f1nalspace requested changes Jun 27, 2025

View reviewed changes

f1nalspace reviewed Jul 6, 2025

View reviewed changes

Added DirectInput support. #174

Are you sure you want to change the base?

Added DirectInput support. #174

Uh oh!

Conversation

KungPhoo commented Jun 26, 2025

Uh oh!

f1nalspace commented Jun 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

f1nalspace left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

f1nalspace Jun 27, 2025

Choose a reason for hiding this comment

Uh oh!

KungPhoo Jul 1, 2025

Choose a reason for hiding this comment

Uh oh!

f1nalspace Jun 27, 2025

Choose a reason for hiding this comment

Uh oh!

f1nalspace Jun 27, 2025

Choose a reason for hiding this comment

Uh oh!

KungPhoo Jul 1, 2025

Choose a reason for hiding this comment

Uh oh!

f1nalspace Jun 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KungPhoo Jul 1, 2025

Choose a reason for hiding this comment

Uh oh!

f1nalspace commented Jun 27, 2025

Uh oh!

KungPhoo commented Jul 1, 2025

Uh oh!

f1nalspace commented Jul 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

f1nalspace commented Jul 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

f1nalspace left a comment

Choose a reason for hiding this comment

Uh oh!

KungPhoo commented Jul 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

f1nalspace commented Jun 27, 2025 •

edited

Loading

f1nalspace left a comment •

edited

Loading

f1nalspace Jun 27, 2025 •

edited

Loading

f1nalspace commented Jul 5, 2025 •

edited

Loading

f1nalspace commented Jul 5, 2025 •

edited

Loading