1
\$\begingroup\$

So, I intercept the WM_KEYDOWN and other messages.

Thing is, my game can't/shouldn't react to these messages just yet, since my game might be currently drawing to the screen or in the middle of updating my game entities. So the idea is to keep a keyboardstate and mousestate, which is updated by the part of my code that intercepts the windows messages. These states just keep track of which keys/buttons are currently pressed. Then, at the start of my game's update function, I access these keyboard and mouse states and my game reacts to the user input.

Now, which is the best way to access these states? I assume that windows messages can be sent whenever, so the keyboard/mouse states are constantly being edited. Accessing say a list of currently pressed keys in the keyboard state the same time another part of the code is editing the list would cause problems.

Should I make a deep copy of a state and act on that? How would I deal with the garbage generated though, this would take place every frame.

Improve this question
\$\endgroup\$
2
  • 3
    \$\begingroup\$ The whole point of Windows messages is that you can handle the message queue when you finish rendering etc and have time to handle events. You change your state as a result of handling the messages. \$\endgroup\$
    – Kylotan
    Dec 1, 2012 at 18:09
  • \$\begingroup\$ One thing you could try is making a thread that listens for keyboard/mouse events then pushes a message onto a queue (that you create) telling you what buttons were pressed or released and the time it happened. You could then just empty the queue at the beginning of every update. Threading is a bit tricky in games so I am not sure if this will work, but it's an idea. \$\endgroup\$
    – Benjamin Danger Johnson
    Jan 30, 2013 at 17:42

1 Answer 1

Reset to default
1
\$\begingroup\$

If I understand you correctly, it's not the way you should read input in games. Instead of reading Windows messages, keyboard is instead polled in your Update function. In WinAPI you use GetKeyState function for that. So you have something like this:

KeyState prevKeys; //*
KeyState currKeys;

Update() {
    prevKeys = currKeys;
    ScanKeyboard(out currKeys);

    //... 
}

*) You need previous state to detect key state changes.

You can check this out for a attempt to use event instead of polling, and problems discovered during this process.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ I need to use Windows Messages in order to do text input properly, so i might as well just deal with windows messages for everything, no? \$\endgroup\$
    – Bob Coder
    Nov 30, 2012 at 11:43
  • \$\begingroup\$ @BobCoder well I can't say for everyone, but polling is preffered in games for a reason. See last link in updated answer. I will not say it's impossible to do input with events, but it's seems like it's harder compared to polling. \$\endgroup\$
    – Petr Abdulin
    Dec 1, 2012 at 15:28
  • \$\begingroup\$ @PetrAbdulin: you can trivially build your own keyboard state table using the messages, and then poll that table. you can then have both messages for text input and game-oriented input code. you're going to be using the message loop because the actual "recommended" approach for games is actually Raw Input (msdn.microsoft.com/en-us/library/windows/desktop/…) \$\endgroup\$
    – Sean Middleditch
    Dec 2, 2012 at 20:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .