MS XInput*.dll implementation

[Alexey Loukianov]

-----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 at mail.ru
System Engineer,                            Mob.:+7(926)218-1320
*nix Specialist
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOr/4kAAoJEPB9BOdTkBULM+QIAKyG73I7BpcWvSqBRpee9ljF
HTEMCRG5mKZymSqi+prTQQnQgYs0rdq/paPTzUlYoCtD4ZsoIaNMYRSQUkQuKLHB
aO0JFdEJEa6liiABR05y3xfjYqd7am2tHDfHSTTO2o1TCmphJau5QquaSNCG5Sh1
Xe1eoVc6RWMxzgQqFuGtEPV34B1s2wiFzjosXv9NZWSwwxL0m9bgBvDeJKvNcNnT
tsymMur2SkWXh9sgKwW0wJ3MENlSk5BP0z4I649EWCHgTf8lfz6HFj8fwShsl3KD
SvmP8woqUXl93g5eEqM18bIVFm/gyRYEzVTZJTize8/E9dZtgUbtWoQv3t/c81s=
=8M6g
-----END PGP SIGNATURE-----