I see what you mean. It seems like SDL does a great job at providing cross-platform support, providing cross-technology support (USB, Bluetooth, old-school 15-pin analog, maybe XID, etc), and in simplifying common compatibility problems with joysticks. However, it suffers the common problem that most such APIs run into: lowest common denominator.
I guess there are 6 options I can think of:
- Hope that SDL_JoystickName contains VID & PID as part of the name. Note that non-USB and non-Bluetooth joysticks won't have VID or PID (ex: old-school 15-pin analog).
- Switch to an alternative API similar to SDL but with more features (and maybe more complicated).
- Use the native APIs on each platform. This gives you a lot of control, but at the expense of complexity.
- Look at SDL 2.0 and see if it has the necessary improvements (at a glance, looks like 'no')
- Since SDL is open source, add your own methods to get the VID and PID (if available) from a joystick index. This code will be platform-specific but is limited to just this part of the code.
- Don't change your code.
Well, absent any help from the peanut gallery on the first 5 options (ie. patch submissions to make it work), I'm going to stick with option 6 for now: "Don't change [my] code." Maybe after I get LTO Flash! in the can and shipped I can entertain deeper modifications.
My long term goal is to rewrite jzIntv in C++11 / C++14 as a set of classes with better defined interfaces and better encapsulation away from SDL. This will make it easier for folks to take jzIntv's core and wrap a different platform's APIs around it for native builds, while still offering an SDL build.
The current code base is almost two decades old, and, to put it politely, it has accumulated a fair bit of technical debt. Plus, I think I may actually be a better programmer now than I was when I first graduated college. Not necessarily the case, but I hope it's true for my sake.
One reason I've shunned native APIs is that they're moving targets, and I usually don't have the tools, time or patience to chase those targets. SDL, on the other hand, has been stable for most of jzIntv's existence. The biggest upset to the codebase (aside from moving from early Allegro to SDL 0.10) was moving from SDL 0.10 to SDL 1.2, and that was actually pretty painless. That said, jzIntv has been built with native APIs. Tim Lindner did a native MacOS 9 port years ago. ("MacOS 9" should give you an idea of how long ago that was!)
If I ever do get around to rewriting the jzIntv core as a C++ library, then whoever has the latest TurboXMetroVisualCodeWorksEclipseWarriorStudio.NET for their platform should be able to add a few classes to bridge the core code to their platform with native APIs, all encapsulated appropriately.
Edited by intvnut, Thu Nov 20, 2014 1:53 AM.