-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
01.11.2011 11:58, Dan Kegel wrote:
Hi, I doubt anyone's working on it (would like to be wrong about that). Things to keep in mind: ...
Dan, thanks for a quick answer on topic. Besides these general and very valuable keypoints there are some other things that should be clarified (or at least discussed) before proceeding with writing code.
Most important things to talk about that I can think of at a first glance:
a) Obtaining specs. Black-box testing is always a good thing (had learned it with pain when been studying how to write programs for the Window 3.x). What I've got available to do the tests are three Windows-based PCs, each running different version of OS, namely W2k Prof, WXP Home and Win7 Starter. XP and Seven are surely a good targets for XInput black-box testing and implementing test cases. Not sure for W2k, would need to investigate further. Things getting worse when it comes to hardware: the only "game input device" I have on hand is the aforementioned gamepad by Thrustmaster. MSDN XInput docs state that XInput was primarily targeted at supporting Xbox360 gamepads, and it looks like that there are a bunch of different subtypes of these devices out there in the wild. At the best case I only would be able to investigate XI behavior for most generic XINPUT_DEVSUBTYPE_GAMEPAD type which my gamepad most closely corresponds to. Would try to ask my friends in case they've got some controllers that fit into other XINPUT_DEVSUBTYPE_* categories.
b) I'm pretty limited with Linux-only as a host system for Wine. Thus it would be impossible for me to write the code that supports FreeBSD and/or Mac OS X.
c) Separate challenge would be to detect the correct XINPUT_DEVSUBTYPE for game input controller under linux. As far as I understand event-driven linux input API correctly, it doesn't have any means of distinction between different game controllers types. What is possible though is to detect VID/PID, the product brand-name and the number of axis and buttons. It makes possible to implement some kind of "device database" and determine the correct XINPUT_DEVSUBTYPE basing on the info from this database, but I don't think it would be the most clear and maintainable solution ever (database should be maintained, populated with new HW defs, e.t.c).
d) Code duplication issues. XInput API mirrors DirectInput API at some part and it might be reasonable to re-use code parts from the existing DirectInput linux event-based joystick driver. I am thinking about implementing XInput on top of DirectInput + extending existing DI linux event-based joystick driver COM API with Wine-specific extensions (this is required to add support for "rumble" FF effect). There are Windows drivers out there that work in exactly this way (XBCD in a good example offering drop-in XInput wrapper dll that maps to the DI calls).
e) List of games that might benefit from XInput support is pretty big, one may wish to take a look onto this Wiki page for examples:
http://en.wikipedia.org/wiki/List_of_XInput_enabled_games
Chances are some titles out there are free and open source but investigation is needed to name exact titles. I own some of the commercial titles from that list (for ex. Braid, Borderlands, DiRT, DiRT 2. Fallout 3, Fuel, L4D, L4D2, LIMBO, Grid, RAGE, The Witcher 2, titles from The Orande Box, Portal 2, UT3) so it would be possible for me to test the XInput implementation on the broad range of native apps. Still I would try to search for free (and maybe OSS) Win32 game that might be used by anybody as the "example testcase".
- -- Best regards, Alexey Loukianov mailto:mooroon2@mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist