Stephen Anthony wrote:
I originally reported this issue in 2007 (!) and then eventually forgot about it. Now it’s popped up again, both in SDL1.2 and still present in SDL2.0.
The adaptor I’m using is RetroUSB SNES controller, but others have reported similar issues with the Genesis controller. The following output from Stella (multi-platform Atari 2600 emulator) is as follows:
For Windows: Joystick name: SNES
Attributes: 2 axes, 4 buttons, 0 hats
Joystick name: RetroUSB.com SNES RetroPort
Attributes: 2 axes, 8 buttons, 0 hats
My first thought here is that the Windows driver is broken.
I’m curious which buttons are reported to Windows. I’m kind of betting it’s reporting B, Y, Select, and Start. If that’s the case, it’s only reporting the first 8 shifts off the shift register as if it were reading a NES controller. Here’s the difference:
SNES: 1 1 1 1 RT LT X A Ri Le Dn Up St Se Y B
NES : - - - - - - - - Ri Le Dn Up St Se B A
Buttons are active low, and the high order nybble is always 1111 for a SNES controller. (I assume you don’t care about the SNES mouse and probably, sadly, your USB adapter probably tries to at least mimic a HID device in some way, meaning that it’s probably not smart enough
If you’re not using any special driver for Windows, it might be that the SNES was made to read both NES and SNES controllers?just read 8 more bits of serial data into the microcontroller. It may simply be that it’s operating in NES mode. This much is probably significantly beyond the SDL list to fix, if it is in fact a Windows driver bug. If the driver has source code somewhere, it’s probably not hard to fix. Obviously it’s supported in Linux, so any necessary initialization is already done somewhere you can find source and read it.
I personally cannot help with Windows driver code much?beyond my expertise, but I just had a quick look at some modern Linux HID driver code, and I think I remember enough to at least read it.
Can you look up the USB vendor/device IDs? I can at least check the kernel source to see if Linux has a specific driver for it, or if it just uses a generic HID joystick driver.
Stephen Anthony wrote:
Note that this is also confirmed in testjoystick in SDL1.2 and SDL2.0, so it isn’t an app-specific problem. And I’ve seen similar reports through Googling, but no solution.
Any advice on how to proceed? I’m willing to attempt to debug this, but would like some idea on where to start. I have fairly extensive experience with debugging SDL in Linux, but not in Windows at all. I have access to all compilers and WIndows versions from XP onward (MSDNAA).
If Linux uses a generic HID driver, you may have the option of a vendor-supplied or Windows generic driver. If it’s not a HID device, or if it’s doing something custom, you might be able to find an open source Windows driver that either supports it or can be tweaked to support it.
Personally I like the notion of assigning the DPad to a hat, as modern controllers do, because I’ve never been a fan of the whole analog/digital thing. But I see why they did it the way they did since older games tended to assume all you had was a PC game port.