Input management

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

Recommended Posts

Hello, I'm writing a input management system (using Windows messages) and i wonder what would be the beset way to aquare it. Is it better to have a separate thread with the message pump?
Example:
while(...)
{

if(GetMessage(...))
{
Store the key and the exact time when was pressed or released
...
}
}
while(1)
{// on each frame:
Aquare_the_input_queue();
Assemble_input();// this will result in a accurate delta time
// equal with the length of time for when the key was down
...
}

Or, check if the key is down at the start of each frame? As a consequence of this, the key is down or up for the entire frame. Thanks, Raxvan.

Share on other sites
A separate thread really isn't necessary for basic input. As long as you handle Windows messages at least once a frame you should be fine. Whenever you get a WM_KEYDOWN or WM_KEYUP message, turn it into an event and send it to the appropriate system(s). The time and duration of the event don't really matter, since systems aren't polling the input. By virtue of the fact that they see an input event in their queue, they consider that event to have happened right now.

Share on other sites
Quote:
 Original post by ZipsterA separate thread really isn't necessary for basic input. As long as you handle Windows messages at least once a frame you should be fine. Whenever you get a WM_KEYDOWN or WM_KEYUP message, turn it into an event and send it to the appropriate system(s). The time and duration of the event don't really matter, since systems aren't polling the input. By virtue of the fact that they see an input event in their queue, they consider that event to have happened right now.

I found out that the MSG structure has the time for when the message was sent.
So i created a function ProcessMessage(MSG &m) and called it right in the frond of the DispatchMessage. My WndProc is now empty and all the message processing is done by my function. I believe that this solved all my problems very nicely because i can calculate delta time for a key with very little effort and ProcessMessage is a class member function , so it has access to all the information instantly (unlike WndProc which is static and every time you call it
you have to invoke GetWindowLongPtr to get my data).

Thanks anyway,

Raxvan

Share on other sites
Quote:
Original post by Makaan
Quote:
 Original post by ZipsterA separate thread really isn't necessary for basic input. As long as you handle Windows messages at least once a frame you should be fine. Whenever you get a WM_KEYDOWN or WM_KEYUP message, turn it into an event and send it to the appropriate system(s). The time and duration of the event don't really matter, since systems aren't polling the input. By virtue of the fact that they see an input event in their queue, they consider that event to have happened right now.

I found out that the MSG structure has the time for when the message was sent.
So i created a function ProcessMessage(MSG &m) and called it right in the frond of the DispatchMessage. My WndProc is now empty and all the message processing is done by my function. I believe that this solved all my problems very nicely because i can calculate delta time for a key with very little effort and ProcessMessage is a class member function , so it has access to all the information instantly (unlike WndProc which is static and every time you call it
you have to invoke GetWindowLongPtr to get my data).

Thanks anyway,

Raxvan

You have to be very careful with that, not all messages arrive at your WndProc through the message loop.

Share on other sites
Quote:
 Original post by pablo24You have to be very careful with that, not all messages arrive at your WndProc through the message loop.

Well i'm only interested in WM_KEYDOWN,WM_KEYUP,WM_INPUT and WM_MOUSEMOVE. As far as i tested it it worked perfect.

1. 1
2. 2
3. 3
Rutin
18
4. 4
JoeJ
14
5. 5

• 14
• 10
• 23
• 9
• 32
• Forum Statistics

• Total Topics
632631
• Total Posts
3007528
• Who's Online (See full list)

There are no registered users currently online

×