XInput wrapper
How are people wrapping up XInput? Many games only care when the player starts or stops pressing a button. State changes. Edges. XInput lets you check if the button is currently down or not, but leaves the rest to be handled at a higher level. Is XNA Framework planning to handle any of this? I wrote a quick wrapper that just checks for state changes and fires off events using delegates. This is a good start, but requires an update from the game loop to check for those changes. Even at 60Hz, I imagine it's easy to drop edges, and god forbid the game hitches due to some nifty effect. Losing an input would be pretty annoying for a fighting game. Lacking interrupts, it seems the best solution might be to dedicate a thread to monitoring controllers and queueing up events in some synchronized event queue shared with the game thread. Then put that thread on some unused core, or otherwise give it fairly high priority. This seems like something most games might want to do. It also seems like a waste for everyone to roll their own. Maybe there's already a solution I missed? Maybe I'm over thinking the problem?
And then there are keyboards on the 360 that are supposed to be handled through XInput...
The XNA input system doesn't do edge detection, so you're right, this is something you will have to check for.
In practice I don't think you'll see any problems just polling the
input state at 60hz, though. In fact the underlying gamepad hardware is
based on polling rather than events, so at the lowest level, this is
the only possible way to read it! That means even commercial fighting
games always have to poll the inputs and then do their own edge
detection. I suppose it's possible that some games might want to read
input at a higher rate than 60hz, but I've never heard of anyone doing
this in practice as it doesn't really seem to be a problem.
Pooling at a higher level rate than 60hz may not be useful for buttons but in a case of a force feedback system, pooling an axis value at higher rate could mean improving a spring effect. I do understand that the XInput is limited to the Xbox360 controller, rumbbles and communicator. For a steering wheel, I expect the XInput to deal with all forces type like on DirectInput and pool and response to a device at a higher rate than 60hz.
Also, the other point talked in the prior message, was the frame rate which could drop easily base on the complexity of the scene to draw. Most games are tweaked graphically for 1 player game. And when 2 players required split screen we often see the frame rate to drop around 30-25 FPS (33-40 ms). This still make it for most players, unless a gamepad compatible with xbox360 came out with autofire.
Otherwise, maybe XInput could add informations to their structures to make sure that nothing has been lost in between two pooling.
regards,
Yann
