dynamic xinput

[Un1q32]

Dynamically load xinput so the game can work on Windows 2000.

[BrentDaMage]

Also, perhaps we put the bindings in some sort of static class inside of the Input.XInput project instead? I'm not a huge fan of having the function bindings/pointers inside of the GameControllerHandler.

[Un1q32]

Also, perhaps we put the bindings in some sort of static class inside of the Input.XInput project instead? I'm not a huge fan of having the function bindings/pointers inside of the GameControllerHandler.

Not sure what this means, like create a whole new source file and class to abstract one xinput function? What would this accomplish?

[BrentDaMage]

Also, perhaps we put the bindings in some sort of static class inside of the Input.XInput project instead? I'm not a huge fan of having the function bindings/pointers inside of the GameControllerHandler.

Not sure what this means, like create a whole new source file and class to abstract one xinput function? What would this accomplish?

Correct. This would ensure that the XInput function bindings remain separate from the GameControllerHandler itself. That way, we can have the ugly macro checks separate from the actual logic for handling game controller input. Additionally, this class should be static.

[Un1q32]

Correct. This would ensure that the XInput function bindings remain separate from the GameControllerHandler itself. That way, we can have the ugly macro checks separate from the actual logic for handling game controller input. Additionally, this class should be static.

Wouldn't this add additional runtime and memory overhead? Doesn't seem worth it to move one macro check somewhere else. Plus it means someone reading the code for the first time has to read yet another file to understand it.

[BrentDaMage]

Correct. This would ensure that the XInput function bindings remain separate from the GameControllerHandler itself. That way, we can have the ugly macro checks separate from the actual logic for handling game controller input. Additionally, this class should be static.

Wouldn't this add additional runtime and memory overhead? Doesn't seem worth it to move one macro check somewhere else. Plus it means someone reading the code for the first time has to read yet another file to understand it.

There would be no additional memory overhead. You're taking a member variable from within a singleton class, and moving it to a static class. Combining function bindings and controller handling logic into one class is stupid imo. Having these two parts separated makes things cleaner and easier to understand. They should be separate, like they are in OGL. If you'd like, you could make a static boolean as well to track whether or not the functions have been bound, then just call the static class's InitBindings function in the constructor of the GameControllerHandler.

[Un1q32]

Wait I was thinking objects