DirectInput? WM_INPUT? WM_CHAR?
Author
Hey there....
I'm making a simple game engine with Visual C++, and I'd just finished programming my game engine's input module with DirectInput when I read a post that said that DirectInput should NEVER be used for standard input. Then I read that WM_INPUT should be used for hi-res mouse input, WM_CHAR should be used for keyboard input, and WM_MOUSEMOVE (or something like that) should be used for mouse pointer input. Just a few questions....
1. How should I respond to WM_INPUT and WM_MOUSEMOVE? I'm trying to keep my modules as independent as possible (three cheers for OOP!) and I'm not sure how I should let my input module receive those messages. I saw some post about hooking into a window to acess its messages, but I'm not sure I'm up to that. Should I have my Windows module automatically send the received messages to my input class?
2. How do I use the before stated Windows messages? Could someone give me a link to some tutorial site? Does it show how on the MSDN site?
3. This isn't really related to the rest of this post, I guess, but it's something I've been wondering for a while. Is there some function that sets the position of the cursor RELATIVE to an existing window (unlike SetCursorPos(), which sets the absolute cursor position), or do I have to calculate the offset myself?
If someone could answer these questions, it would be much appreciated.
--ProgrammerZ
Quote:Original post by ProgrammerZThat's the way I do it. I have an input manager singleton (I know, I know, singletons are bad), which is updated with the current input state by messages recieved by the window proc.
1. How should I respond to WM_INPUT and WM_MOUSEMOVE? I'm trying to keep my modules as independent as possible (three cheers for OOP!) and I'm not sure how I should let my input module receive those messages. I saw some post about hooking into a window to acess its messages, but I'm not sure I'm up to that. Should I have my Windows module automatically send the received messages to my input class?
Quote:Original post by ProgrammerZWM_CHAR and WM_MOUSEMOVE are pretty simple, the docs should be enough for them. There's a blurb in the DirectX SDK about how to use high-DPI mouse inpiut, with example code for mouse input.
2. How do I use the before stated Windows messages? Could someone give me a link to some tutorial site? Does it show how on the MSDN site?
Quote:Original post by ProgrammerZYou have to calculate the offset yourself. GetWindowRect is what you'll need to get the position of the window in screen coordinates, or if you want to convert from client coordinates to screen coordinates, you can use ClientToScreen.
3. This isn't really related to the rest of this post, I guess, but it's something I've been wondering for a while. Is there some function that sets the position of the cursor RELATIVE to an existing window (unlike SetCursorPos(), which sets the absolute cursor position), or do I have to calculate the offset myself?
Author
Thanks for the answers! So, just wondering, would I do something like this in my window proc
MainApp->GetFramework()->GetEngine()->RespondToMessage(msg);
where the framework is a class that owns the engine, the game class, and the windows management class, and the engine is a class that owns the input module?
(MainApp is a global variable (yes, yes, global variables are bad) that points to the main windows management class, so I can use a static member func as a window proc.)
MainApp->GetFramework()->GetEngine()->RespondToMessage(msg);
where the framework is a class that owns the engine, the game class, and the windows management class, and the engine is a class that owns the input module?
(MainApp is a global variable (yes, yes, global variables are bad) that points to the main windows management class, so I can use a static member func as a window proc.)
Quote:Original post by ProgrammerZIt depends on how the rest of your code is laid out really, but that's sort of how I do it.
Thanks for the answers! So, just wondering, would I do something like this in my window proc
MainApp->GetFramework()->GetEngine()->RespondToMessage(msg);
where the framework is a class that owns the engine, the game class, and the windows management class, and the engine is a class that owns the input module?
I have functions of my input manager like OnMouseMove(), OnKeyDown(), and so on. You could even make your window into a message dispatcher, and have modules register themselfs as message listeners. Example code (Psuedo-code, not compiled):
class MessageListener{public: virtual MessageListener() {} virtual ~MessageListener() {} virtual void OnMessage(WPARAM wParam, LPARAM lParam) = 0;};class InputManager : public MessageListener{public: // Other methods here virtual void OnMessage(WPARAM wParam, LPARAM lParam) { // Blah }};class Window{public: // Other methods here void RegisterListener(MessageListener* pListener, UINT nMessage) { // I forget the syntax for multimap offhand m_listeners.insert(pListener, nMessage); }private: std::multimap<UINT, MessageListener*> m_listeners};// In the window message proc:// I forget the syntax for multimap offhandforeach(MessageListener* pListener in m_listeners where message = uMsg){ pListener->OnMessage(wParam, lParam);}Quote:Original post by ProgrammerZThere are ways around that. One way I use.
MainApp is a global variable (yes, yes, global variables are bad) that points to the main windows management class, so I can use a static member func as a window proc.)
Quote:Original post by ProgrammerZ
WM_CHAR should be used for keyboard input
WM_CHAR should be used for text input. WM_KEYDOWN/WM_KEYUP should be used for keys. There is a difference.
Author
Okay! I think I got it:
WM_INPUT for hi-def mouse input,
WM_MOUSEMOVE for cursor input,
WM_KEYDOWN and WM_KEYUP for key press input, and
WM_CHAR for text input.
Just one more question....
I know that the Windows OS takes the raw input from the mouse, applies pointer ballistics (isn't that what they're called?) and moves the cursor accordingly. The cursor, though, has limits (the edge of the screen). That means that if you move the cursor far enough, it will stop at the edge of the screen. If, for instance, I wanted to make a FPS where you move the mouse to aim, and I used WM_INPUT for my mouse input, would I have to center the mouse every frame to stop it from running into the edge of the screen? I hope you can understand what I'm trying to say!
--ProgrammerZ
WM_INPUT for hi-def mouse input,
WM_MOUSEMOVE for cursor input,
WM_KEYDOWN and WM_KEYUP for key press input, and
WM_CHAR for text input.
Just one more question....
I know that the Windows OS takes the raw input from the mouse, applies pointer ballistics (isn't that what they're called?) and moves the cursor accordingly. The cursor, though, has limits (the edge of the screen). That means that if you move the cursor far enough, it will stop at the edge of the screen. If, for instance, I wanted to make a FPS where you move the mouse to aim, and I used WM_INPUT for my mouse input, would I have to center the mouse every frame to stop it from running into the edge of the screen? I hope you can understand what I'm trying to say!
--ProgrammerZ
Quote:Original post by ProgrammerZ
Just one more question....
I know that the Windows OS takes the raw input from the mouse, applies pointer ballistics (isn't that what they're called?) and moves the cursor accordingly. The cursor, though, has limits (the edge of the screen). That means that if you move the cursor far enough, it will stop at the edge of the screen. If, for instance, I wanted to make a FPS where you move the mouse to aim, and I used WM_INPUT for my mouse input, would I have to center the mouse every frame to stop it from running into the edge of the screen? I hope you can understand what I'm trying to say!
AFAIK, yes. This isn't a big problem in FPSes; after all, you're going to be hiding the cursor and running full-screen mode, yes? :) (You could always offer separate support for windowed mode if need be.)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement