2/6/06: Added link to Xinput/DirectInput managed code detection

An interesting post regarding the future of user input on the directx-l mail list this week from Chuck Walbourn at Microsoft. Chuck states that using DirectInput for mouse and keyboard gives you no advantage over using regular windows messages (in fact it is not 'Direct' at all and just uses the underlying windows messages itself). He adds that XInput is the strategy going forward for game pads. The only remaining reason to use DirectInput is for legacy support of game controllers. DirectInput code has a lot of gotchas to avoid and the code is, in my opinion, not the the most straightforward to follow so this is great news. The article Chuck refers to regarding mixing DirectInput and XInput can be found here, though the example code is in C++. I converted the sample to C# here

Of course in managed code you generally do not process windows messages directly, relying instead on the windows forms classes to interpret them and call relevant events. So it will be interesting to see what the performance implications of this are. We have already seen how some windows forms constructs such as DoEvents have memory implications which are acceptable for occasional calls, but unsuitable for repeated calls inside game loops. Tom has already stated that Managed DirectX is having its hard wired connection to Windows Forms removed in part so that people looking for ultimate control of memory footprint and performance can handle this kind of thing themselves. Its not common code in the managed world, but windows messages can be handled just like C++. It will be interesting to see some tutorials on handling things in this way.