How should I handle input in a windows game engine?

Started by
7 comments, last by szecs 14 years, 4 months ago
Hi I am currently trying to plan out a simple game engine and I was wondering what the best way would be to handle keyboard and mouse input? The game engine will be on windows, I would like for the input system to be a modular subsystem like the rest of the game engine systems but I am wondering how I would do that without using DirectInput. My current plan is to use Evil Steves idea to create a less restricting message pump in the window class and then sending the messages to the input system to be handled however necessary. Any thoughts? Thanks. :)
Check out my new blog: http://beefmachinegames.wordpress.com
Advertisement
Why would you bother writing windows specific code when you could use a great cross platform library like SFML (http://www.sfml-dev.org/)? No platform-specific code required, and you can get input events easily. All you need to do is think of a way to handle it -- personally I like to use the chain of responsibility design pattern for this, see http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern
I've used windows messages, and specifically WM_INPUT, with raw input devices, and EvilSteve method. But that was just messing about. It works, that's all I can say!

Everything is better with Metal.

Quote:Original post by Wizecoder
but I am wondering how I would do that without using DirectInput.


In short, for keyboard and mouse; dont.

DirectInput isn't recommended for this task, window messages are a much better solution and even what MS recommends.

Quote:Original post by WizecoderMy current plan is to use Evil Steves idea to create a less restricting message pump in the window class and then sending the messages to the input system to be handled however necessary. Any thoughts?
Well, it's exactly the same method I use (with a small difference: I use params to pass this instead of window's user data, no, I am not aware of the drawbacks).

It is very handy, but I suggest to layer another system (action-based or trigger-based rather than input-based) on top of it and then build the system around higher level input system.

Also, please, make sure to properly manage input by correctly recognizing the difference between 'A' (the character) and 'A' (pressing the button which got the 'A' glyph on a QWERTY kboard layout) - I find horrible that in 2009 people still don't know what the hell keyboard input is...

Previously "Krohm"

Quote:Original post by phantom
Quote:Original post by Wizecoder
but I am wondering how I would do that without using DirectInput.


In short, for keyboard and mouse; dont.

DirectInput isn't recommended for this task, window messages are a much better solution and even what MS recommends.


Wait why are windows messages recommended over DirectInput for keyboard and mouse? And can you link to the place where Microsoft recommends this? Windows messages have more lag than using DirectInput because it has to go through a message queue and notifications can be delayed by other messages in the queue.

You also have no control over the frequency at which the keyboard / mouse state is queried.

[Edited by - cache_hit on December 5, 2009 12:24:27 PM]
Quote:Original post by cache_hit
Wait why are windows messages recommended over DirectInput for keyboard and mouse? And can you link to the place where Microsoft recommends this? Windows messages have more lag than using DirectInput because it has to go through a message queue and notifications can be delayed by other messages in the queue
Direct Input pretty much uses the windows message queue internally.

As for where it says Direct Input shouldn't be used, check it out:
Quote:The use of DirectInput for keyboard and mouse input is not recommended, Windows messages should be used instead
And from the associated link it says, plain as day
Quote:Internally, DirectInput creates a second thread to read WM_INPUT data, and using the DirectInput APIs will add more overhead than simply reading WM_INPUT directly.
right here

C++: A Dialog | C++0x Features: Part1 (lambdas, auto, static_assert) , Part 2 (rvalue references) , Part 3 (decltype) | Write Games | Fix Your Timestep!

Thanks! That's good to know, albeit a bit surprising. How hard would it have been for them to go below the message queue level entirely and just provide an interface directly to the hardware? I thought that's what it was doing, but I guess not.. Seems weird, there must be a reason but I can't imagine what.
And Where is getCursosPos in the comparison (called every updates)?

I tried WM_MOUSE_MOVE, WM_INPUT messages and getCursosPos too.

I used WM_MOUSE_MOVE long ago, but I didn't notice difference between GL_INPUT messages and getCursosPos (precision, delay, performance hit).

But it's easier to use getCursosPos I think.

(Clicks handled with messages.)

This topic is closed to new replies.

Advertisement