Jump to content
  • Advertisement
Sign in to follow this  
Stoic

Direct Input vs Windows Messages?

This topic is 4833 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all - I've been using Direct Input in my game engine for quite some time now, but recently I've made some rather sweeping architectural changes, such as adding a message passing system for inter component communication. I'm finding that my design is evolving to be very much like the basic Windows Design. People can write "Control" objects which link together and communicate with each other via message passing. It's turning out to be very convenient for writing tools and more sophisticated user interfaces. However, I'm finding that the polling-based interface I'm using with DirectInput is getting kinda stretched out. It's pretty hard to get Ascii character information out of the keyboard, without writing a huge function which polls every key, and I have to manually generate messages for the rest of my system after polling everything. I've noticed that bare Windows Messages are already providing most of the information in a form that would be convenient for me (WM_CHAR, for example). I know that I can't use it for Joystick input, but what are the other major tradeoffs between using Windows Messages or Direct Input for Handling Input? Are there latency or update frequency issues? (BTW, I don't mean for this to become a big religious argument... so I apologize in advance if it turns into one) Thanks in advance for any help!

Share this post


Link to post
Share on other sites
Advertisement
Use the windows messages for any kind of text input; it's all done for you, and it supports things like autorepeat. However, I'v heard of input lag if you try to use windows messages as the input system for a game. Use DI for anything high-performance.

You can also use the windows mouse position by using GetCursorPos and ScreenToClient for an absolute window mouse position. That seems to work just fine.

Share this post


Link to post
Share on other sites
Direct Input(IMHO) is useless when you need the input to be sensible from the user (like from a console). For this, WM_CHAR is the way.

I have a framework alot like what you are describing, where I use message passing.
For this I have a queue which is used to store all I/O messages. When the frame begins the queue is locked and the messages are pumped out of it and dispatched to there appropriate location.

So, I have a WM_CHAR event -> goes into Queue
I have a scan code event (Dinput) -> goes into Queue. You poll the Dinput, but you can poll it in a thread.

I suggest you send message by key and NOT by grab the entire state, it is an unworkable mess.

I hook these on signals. These kinds of events don't make sense as being a mail message, because it needs to be activated on the command ( what is the point of putting it in a mailbox to find out I pressed the key ten seconds ago..).

I hope that makes sense. But yes, I avoid DInput for my console input entirely I could not work out a reasonable scheme for auto repeat or to delay it (it will dump out hundreds of messages if you merely tap a key!).

Share this post


Link to post
Share on other sites
Quote:
Original post by Stoic
Are there latency or update frequency issues?


Yes. If the user presses and holds the 'W' key (moving forward, maybe), DirectInput will show that the W key is down everytime you poll the keyboard. Windows messages, however, will send one message immediately as soon as it detects that the W key has been pressed down. It will then pause, sending no messages. After the W key has been held down for a specified amount of time, it will then begin sending the keydown messages at a regular interval. The pause is short, but the behavior is not what you want for high performance / responsive gameplay.

For text input, windows messages are great. For game controls in a serious game, direct input is much better. I'm not sure how easily it would be to integrate the two systems together. Direct Input suppresses Windows messages depending on the mode it's in (exclusive mode will suppress all windows mouse messages, for example). Maybe someone else has more experience getting Windows messages and Direct Input to cooperate :)

Writing your own text-input scheme using Direct Input is doable but probably a big headache. There are many things you would have to account for (key modifiers being held -- like Shift -- will change the produced character, key repeat rates, system language settings, swapped buttons, etc.) You are definitely better off using Windows messages for text as it already provides all of that functionality :)

Share this post


Link to post
Share on other sites
Ok I understand why people would not want to use immediate DirectInput for character input, etc... but what is the reason for not using buffered input? I have a buffered/immediate DirectInput system that does both and works fine.

Share this post


Link to post
Share on other sites
Quote:
Original post by Saruman
Ok I understand why people would not want to use immediate DirectInput for character input, etc... but what is the reason for not using buffered input? I have a buffered/immediate DirectInput system that does both and works fine.


Did you write your own system that deals with key modifiers, key repeat rates, language settings, etc for generating text from input? If so, did you read these settings from the user-defined ones within the control panel, or did you make your own that are specific to your game?

Share this post


Link to post
Share on other sites
If you need high speed input, Windows Messages will still do the job if you use WM_KEYDOWN, and WM_KEYUP. Quake 2, and Quake 3 use this method for their input, and I would have to say they are pretty fast paced games.

I would recommend using the Windows Messages WM_KEYDOWN, and WM_KEYUP.

Share this post


Link to post
Share on other sites
Quote:
Original post by BatGuy
If you need high speed input, Windows Messages will still do the job if you use WM_KEYDOWN, and WM_KEYUP. Quake 2, and Quake 3 use this method for their input, and I would have to say they are pretty fast paced games.

I would recommend using the Windows Messages WM_KEYDOWN, and WM_KEYUP.


Exactly. WM_KEYDOWN and WM_KEYUP are for key EVENTS, WM_CHAR is for receiving TEXT. These 2 things are very different and if you use one for the other you're asking for pain. For fans of DirectInput replace (WM_KEYDOWN and WM_KEYUP) with DirectInput and it's the same. DI gives you button events. Use it to treat the keyboard as a gamepad with a heck of a lot of buttons and you'll be fine.

Share this post


Link to post
Share on other sites
You might want to look into event-based DirectInput for keyboards and mice. You set up an event object which gets set when input is available, thus eliminating the need to constantly poll your devices.

Share this post


Link to post
Share on other sites
Ditch direct input and use windows messages.

Microsoft have stated that it is preferable to use the windows api for mouse and keyboard input. ( see Meltdown 2005 slides avaiable from here ) Since direct input is DX8 interface it may also be deprecated in Longhorn/Vista ... the slides aren't totally clear on that point.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!