Yeah, I didn't write a DirectInput version because there is no way to guarantee the inputs will correspond to the same buttons between controllers. Sometimes Button 1 is X, sometimes it's Square, and the input handler on its own doesn't know anything beyond Button 1 is Button 1. In addition to giving much more difficult data to work with, I'd have to spend even more time setting up some kind of system that allowed people to map their own controller to a different layout, and all that on top of whatever misconceptions people will have about implementing. I decided it wasn't worth it when there are other DirectInput plugins for RGSS already.
XInput is different in that it is a unified standard: A is always A, X is always X. State data is always passed as a single string of bytes, in a specific order, that can always be parsed into consistent data. Controllers that use XInput also tend to share a similar layout, and and input mappers that turn DirectInput controllers into XInput controllers will always provide the same data.
Basically, since most modern PC games no longer use DirectInput, I figured it was safe to just write an XInput version. Since people with DirectInput controllers would have already found a solution to get their pads to work in newer games, I wanted to be compatible with whatever solution the end users had found for themselves and not reinvent the wheel.
Rather than modify any game code to make it work with your gamepad specifically, look into using a program like x360ce to map it into XInput (see earlier in this thread). That way, anyone who plays your game with a different controller can have the same experience. That same configuration can also be used in other PC games. I wrote this module originally with an older Logitech pad mapped into XInput, so I know for a fact that it works.
But you should also be sure you're including bindings for the standard Input module. That's what I wrote PadConfig for.
