Actually there is something like you describe as far as having an easy set
of API's to get input data. It is called DirectInput and is a component of
DirectX. As a means of finding a controller and using it in a game it is
brutally easy to implement. During the time I tested devices for DirectInput
our biggest issues with everything working correctly wasn't getting
DirectInput to work as was described in the SDK, but rather making "fixes"
so that things worked as a consumer would expect regardless of what the
manufacturer did. For example there are many wheel controllers that have
drivers that tell DirectInput that they are Joystick devices, not Wheels.
The reason they did this was if their device was described as a wheel it may
not be used over an actual joystick on the system. Game writers usually took
the short and easy method of asking DirectInput for an attached device and
just accepted the first device returned rather than looking at all the
devices in the system and making an intelligent decision based on that list.
A game should ask for all devices that are attached. If Dinput returns a
joystick device the game should have decided that is ok, but is there
somethign better and ask for another. If a wheel was returned next it should
decide the wheel was a better choice and add the wheel to the list of
devices to get data from. However most games don't. So most of the work done
for Dinput wasn't to make gatting data easier, it was already very easy, it
instead went into finding devices that lied about what they were and working
around that to make things work correctly. As far as the issues with force
feedback and control connectivity you are absolutly right, which is why the
IHV community has not been making gameport devices for years. The gameport
architecture was just not that great. Now devices use USB and things are
much better. There aren't any issues of force data going to the wrong
location for USB devices, only gameport. When there is an issue with a USB
device not working correctly in a system it is either due to the USB driver
not working correctly (and there have been updates for this issue for quite
some time), or the game was not written to utilize a joystick at all. That
is a design decision, not an DirectInput problem.
Joshua Smith
OpenGL Test Lab
Microsoft
-----
Get Secure!
www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights
pjp said:
The biggest problem is simply the pain in the ass that one never is sure
the game will actually run until you try it.
Assuming they solve that (which I doubt), the only way I see it solved is
for all games to use a common higher-level code base for ...
There's no standards for games. By that I mean that every game seems to
have it's own way of selecting various options, choosing input device etc.
etc. For example ...
1 - It's clear having a separate 3d config program is desirable even if
normally not neccessary. If #2 below can't be done then at least there
should be some means oif generating a MEANINGFULL log file so some
self-help is a possibility.
2 - all game should be designed to be "downgradable" to level of hardware
support. May not look good but they all should run REGARDLESS. Black
screening and/or exiting to the desktop, rebooting etc. is intolerable.
3 - FIX THE CONTROLLER ISSUE. XP seems actually worse than 9x in this
regard because all it allows is setting the primary controller (id#1 under
9x). Makes using multipule controllers (when game supports it) even
harder. There should be a "default virtual joystick" that also allows a
user to create additional virtual "devices"; e.g. pad, wheel, stick, etc.
The user dictates exactly what constitutes an axis movement, buttons press
etc. e.g. with no limitation on where the actual input is "really" coming
from, e.g. keyboard, mouse, joystick or whatever. Games always use the
virtual joystick and allow a standard common means of selecting from the
list if a user decided to "create" more than the default one. Completely
eliminates the bs of no joystick in Freelancer (unexpected) or most RTS's,
limited support in FPS's, game uses wrong device, game screws up with more
than one device attached etc. etc. etc.
4 - game companies - stop screwing us around with support options (or lack
there-of), unanswered emails, stupid replies that simply waste customers
time. Having to "register on site" for support is intolerable. Even worse
is games being released where it's expected a purchaser will HAVE TO
download a patch to even play the game. They all should be forced to offer
a "limited time after purchase" return policy, e.g. send in cd and receipt
and they send you cash NOT a credit for some future game or whatever. If
you're willing to register the product during install then the company (MS
etc. also take note) should HAVE TO mail you any updates, patches etc. as
required, e.g. snail mail on CD. Bet that'd make them pay more attention
to the "details" before selling to public.
I'll add ... Personally I'm also very tired of driving games that treat a
wheel almost like buttons. NFS-HP2, TOCA series, even Rallisport Challenge
(albeit can be alleviated somewhat by choosing "Loose" before racing)
SUCKS big time. Force feedback going to wrong device is another sore
point. I feel it's basically a problem with how complicated the
programming API's are. Hence the guys actually writing the code don't
always know "how it should be done" but instead are forced to work with
"at least it's working ... sort-of". MS could alleviate this considerably
by simply releasing real world working code for all game manufacturers to
use, e.g. (ex 1) plug this in and it returns a list of all attached
devices along with # of axis, buttons etc. etc., (ex 2) plug this in and
call it like this and you have smooth real time input from selected
device, etc. etc.
Mind you, what one would think such an easy