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...
XInput wrapper
K.V.Bharath
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
Madmax71
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.
Zero WangXin
Blast
*sigh*
Talking about force-feedback : where IS the mean to use ff racing wheel when managed XNA doesn't implement it !
I suppose we'll have to wait for another XNA SDK release....or an Xbox 720... *grin*
Krutika