Sign in to follow this  
littlekid

WM_INPUT, DirectInput

Recommended Posts

Which is better to use WM_INPUT or DirectInput. I have read somewhere that microsoft is encouraging people to use WM_INPUT. Does it mean that I should convert my application from DirectInput to WM_INPUT? And why does microsoft suggest that? are they removing DirectInput in Directx10 or something?

Share this post


Link to post
Share on other sites
A quick search on these forums will answer all of these questions for you...

Microsoft, from my understanding, will be removing Direct Input from DX10. It's basically just a wrapper anyways, that's why I've never used it. There will be a new "input" library for new controllers I do believe also but it won't support things like keyboards etc. Anyways it's all explained on the forums just go hunting :)

Share this post


Link to post
Share on other sites
The general consensus at the moment is that you should use windows messages for mouse and keyboard, DInput for legacy joypads if you need to, and XInput for future control pads (which is just the XB360 one atm)...

I can't remember the details right now, but DirectInput under WinXP sits on top of the windows messages for the system mouse/keyboard, so you're not really gaining anything performance wise by using DInput. I'd argue that things like Action Mapping might add extra features, but seems that very few (if any) developers use that.

Chuck Walbourn mentioned (on DirectXDev) that DInput might be moved to the Platform SDK at some point in the future, but thats all that has been officially stated. There's not been much information about what DirectX 10 will include - currently we've only seen Direct3D 10.

As far as converting to/from DInput... if you've already got DInput working then theres no point in changing it just for the sake of changing it. Conversely you don't really want to be starting any new code based on DInput.

hth
Jack

Share this post


Link to post
Share on other sites
I really hope they rethink some of the decisions concerning this. There are a number of features in DirectInput I prefer to the "new" XInput api, although some for no other reason than I am not limited by the "static" nature of the XInput api. Removing the choices developers had before, solely because they are rarely used should not be sufficient reason in my opinion. Not only that, but crippling a "newer" device under the old system for no apparent reason is just rediculous.

But there are a lot of things present ActionMapping, Buffered Input, Deadzones, Device and Object Querying, etc. I particuar found useful.

I suppose once you rewrite a good framework over XInput to add desired support back it will be fine in the long run, but currently this seems somewhat like a step backwards and in most instances, unwarranted.

Though it may be too early to judge.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
For what its worth XInput is still in beta as of the last release, and does support dead zones. Buffered input I will miss but as I think more and more about it I have never used buffered input for a joystick, I can think of maybe a reason why I would want to but generally my update calls are fast enough that even buffered input would be hard pressed to get more than one message at a time. Anywho since I am moving to an event based system anyways for input, I will just be notifying the rest of my game when button states change which will work just as well buffered as unbuffered.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this