Anyone available for some SDL+Win32 help?

Hey folks. I've run into a bit of a snag with a particular Steam-released game called SteamWorld Dig. Many players found their joypads didn't work at all, and are being told to use nonsense like JoyToKey.

The game itself has a file called gamepads.cfg that you can edit and actually add your own joypad definition, which the game will hnour. The file format wasn't documented, but the default file looked familiar to me:


After much prodding, I finally got the developers to explain what the heck they're doing: the first two fields are something SDL 2.0 itself refers to/comes up with/can compile/generate:

http://wiki.libsdl.org/SDL_GameControllerAddMapping

...based on Windows USB device strings and so on. I can tell the last hex values in the first field end in "HIDVID" but the rest is a bunch of SDL 2.0 API-generated abstract gobbledegook. I've dug through the Device Manager and I can work out small bits/pieces but nothing really adds up that would match exactly what SDL 2.0 expects.

I was wondering if there was someone here who could write me a simple Win32 application using SDL 2.0 that basically would dump all of those strings and capabilities of every joypad found:

http://wiki.libsdl.org/CategoryGameCont ... umerations

...to stdout, so that I could add a proper entry into gamepads.cfg and get my USB gamepad working with the game (it's a Playstation 2-to-USB adapter but it's pure USB HID, no drivers).

Or if someone here has familiarity with the SDL 2.0 code -- no I am not going to reverse-engineer it and spend days looking at github source or whatever else -- that can tell me how these strings are generated on Windows (i.e. how to create the string myself), that would absolutely awesome. All I have available to me are the standard tools that come with Windows XP SP3.

I just have little faith that the developers are really going to do anything about the issue, since they're already advocating Joy2Key (and if you think this is a solution, trust me, it isn't; try running something in windowed mode with Joy2Key using the profile for the game, then switching to a browser window and accidentally doing something like bumping a button on your joypad... yeah...).

Thanks guys.

504944564944 is ASCII for "PIDVID". VID is vendor ID, PID is product ID. Perhaps the 79 and 11 are related to the HID device's VID and PID, which you can get from Device Manager. (Endian warning?)

I don't know about SDL 2, and I don't have access to a Win32 development toolchain today, but there are similar programs for Pygame (Python wrapper around SDL 1).
http://www.pygame.org/wiki/Joystick_analyzer

SDL 1 and SDL 2 are pretty different in this regard, so I would not be surprised if SDL 1 didn't offer or do the same thing. One would really have to look at the SDL source to know.

Okay, so there's a Python program that does some magic. Great -- now either I have to find someone who can compile me an .exe of that Python program (yes it's possible to do this, trust me), or I have to install Python for Windows and risk making a mess of my system. I have a friend who compiles Python stuff like this (his workplace demands compiled Python apps on Windows because, and I quote, "installing Python on Windows is painful and makes a mess"), so I'll ask him if maybe he can do that.

I've never had problems with Python (2.7) on Windows, and installation was pretty much just tapping Next a couple of times. The only somewhat annoying thing was that the default install directory was C:\Python27, and I didn't want to change it out of fear of breaking something.

Okay, so I've installed Python 2.7 (stock location), and now I'm stuck on this SDL crap.

The PySDL (which I assume is SDL 1 -- going off of this because of what Tepples linked originally) stuff I found is here:

http://pysdl.sourceforge.net/

There are no instructions. So I referred to these two downloads:

http://pysdl.sourceforge.net/pysdl-win32-0.0.6.zip
http://pysdl.sourceforge.net/pysdl-depend-win32.zip

The first contains something called a sdl.pyd file, which from viewing looks like a Win32 executable but it doesn't have an .exe extension so I have no idea what to do with this thing. Edit: http://docs.python.org/2/faq/windows#is ... e-as-a-dll answers the question of what it is, but I still have no idea where to place this file.

The second contains DLLs, but I have no idea where to extract those to (I want to assume C:\Python27\DLLs but I'm not sure -- and I am not going to install them in C:\Windows\System32, thank you very much).

You need to install pygame, not PySDL. Download from: http://www.pygame.org/download.shtml

Use the .msi installer, it's the easiest to use (just Next, Next, Next once again).

Thanks -- yep, that works, and joystick_analyzer.py also runs. I added some code (os._exit(1) and some print statements) to get what I wanted.


Which gets me:

http://www.pygame.org/docs/ref/joystick ... k.Joystick doesn't appear to list off any way to get the actual string I'm hoping for. :/

Perhaps the GUID thing is new in SDL2. There is a separate project called PySDL2, which appears to be the successor to Pygame. If I wanted to take a guess, I'd guess that the GUID is somehow formed from the VID and PID, which you might be able to find in Device Manager. The example might be VID 0x0011 and PID 0x0079 or vice versa.

I'm currently writing some Python with SDL2 (and the PySDL library) to figure this out.

Success. Now I'm just waiting for the developers to disclose what all the "name mappings" are that they refer to in their game code so that I can map the correct buttons/axes/hats to the names they use:

http://steamcommunity.com/app/252410/di ... 6139881342

Code (with SDL 2.0 installed in C:\Python27\SDL2):

If you can wait a little bit and still need it, I can throw something together in C for you later tonight. It looks like tepple's python solution has worked though. I've barely touched SDL, but this doesn't sound like something super difficult. Maybe it will be a good excuse for me to learn a little.

In Windows, it looks like the GUID comes directly from directx; SDL doesn't synthesize it.

I also checked the Linux code, and SDL creates a GUID starting with the bus type and then either some string literal that comes from the joystick's path, or it's created with the (16-bit) vendor code, the product code, and the version code each followed by 16 bits of 0. I'm not going to pretend I know how Linux works, so I have no idea what any of this is.

Joystick support in PCs is such a pain in the ass due to a lack of any kind of standardization (until recently), that it feels like it's not worth the effort to do anything other than keyboard/mouse and wrap your joystick with utilities like joy2key (despite protests ). At least it'd always work!

No, Tepples' thing didn't actually get me what I wanted exactly -- BUT, it did get me to look at *how* I could get what I wanted out of Python and PySDL2, which in effect allowed me to accomplish what I wanted. So I thank him for that. :-)

I'm about 90% done with it at this point. I'm just waiting for the developers to disclose what button mapping names they use for what features (ex. "lefttrigger" should act as a modifier to run fast, etc.) and I can figure out the button-to-name mappings myself.

Almost makes me long for the ancient DA15 4-axis 4-button joystick interface ... except that I know that's worse.

I too agree that joysticks on PC are babel. But I've been thinking through this problem. The autodetection that I implemented for PyFHBG is based on the name of the joystick, with no GUID stuff because SDL 1 (and hence Pygame) doesn't expose the name. Here are some tips:

1. Make configuring an unknown brand of joystick idiot-proof.
2. Allow saving and loading controller configuration in a text file, so that configs can be copied and pasted on forums and in e-mail.
3. Include reasonable defaults for keyboard, Xbox 360 controllers, and the most popular HID controllers. Possibly determine popularity by polling your forum members and beta testers.

Now that you have Python and Pygame installed, I'd like you to try Wrecking Ball Boy and PyFHBG and see if configuration is easy enough for mortals to figure out.

Here's what it gives for my N64 controller:

And for my EMS USB2 (PS1 controller to PC) adapter:

And done: http://steamcommunity.com/app/252410/di ... 8458207044



What would have helped me was a User Manual or *something* telling me what button on the 3DS or PC actually did what thing. Not a single 3DS review (video or blog/web page) nor PC review disclosed this info; but at least the 3DS version displays on-screen what some of the buttons do, so I was able to sort of work it out from there.

Also for Tepples I guess: in case you want to know what button names map to what physical button on this adapter:


And the h0 through h3 (for "POV Hats") work/map identically in functionality as long as the "Analog" mode of the PS2 controller is enabled (by pressing the "Analog" button).

SDL "button names" are a new feature in SDL 2, something I happen not to have tried yet. SDL 1 just uses button numbers.

And your PS Converter appears to use the same order as my EMS USB2, except for putting the D-pad on a hat instead of four buttons. (Dance games such as StepMania require the four buttons because they use Left+Right and Up+Down presses.)

The D-pad behaves differently depending on if the Analog button on the PS2 controller is pressed (LED lit):

Analog off: D-pad uses X/Y axis
Analog on: D-pad uses POV hat

The controller defaults to the Analog mode being off, which also disables the analog sticks. When Analog is on, the analog sticks affect Z-axis. All this is according to Control Panel / Game Controllers / Properties in Windows XP. I prefer the Analog mode be off anyway, barring situations where a game might play better if I had analog control.

And yeah, it works with rumble too (I know because I used to use that feature using FFXI as well). It's just some little PS2-to-USB adapter I got off Jandaman's site, but it doesn't look like the product is made or sold any more.