Jump to content
  • Advertisement
Sign in to follow this  
Nairou

Input modularization

This topic is 3868 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

I'm currently rewriting my input system, stripping out the DirectInput code. From what I've read, the best method (on Windows) is just catching the window input messages. However, these messages are coming from the individual windows my application has open, which is posing a design problem. The other thing I'm trying to do as part of this rewrite is to modularize my code as much as possible so that there are as few interdependencies as possible. However, if input is coming from the windows themselves, that means that my window class needs to know about input and continually pass messages to my input class. The window class is also used by the renderer, so I can't just combine it with another system. And, because there may be multiple windows open by the application (i.e. multi-monitor rendering), there would be multiple sources for input to come from. I guess I'm trying to find some alternative to this, so that all player input stays in the input class and the window class can just deal with the creation and management of the window for the renderer. Barring that, is there a logical way to set this up so that pulling input from windows isn't as much of a hack as it currently would be?

Share this post


Link to post
Share on other sites
Advertisement
The entrypoint or OS interface class is the highest level. It uses the renderer, it uses the input access you provide, it ties the various modules together. DX and stuff might need a handle for reference, but that's it.

Take input from the OS, adapt to the engine's needs. The system doesn't care where the input comes from. Your glue code that takes OS specifics and binds it with engine specifics knows of both.

Share this post


Link to post
Share on other sites
I guess its a matter of design tidyness. If I'm trying to modularize my class layout, then having certain classes that handle tasks that are (from the application point of view) unrelated to it bug me, and I try to look for a solution. My window class is currently really simple and does nothing but manage a window (open/close/resize, and issuing events to subscribers). The window objects get passed around as needed, like to the renderer. To have to tack on all of the input handling code, even if just to feed it to another class that "officially" handles input, is rather convoluted and would limit how freely I can create/destroy the window objects. With DirectInput, it at least gave the appearance of being separate. I'm wondering if there is some way to still gather those input messages without needing to butcher my window class to pass them along just because the OS handles it that way.

Share this post


Link to post
Share on other sites
There's nothing that requires that your conceptual window class handle actual windows messages.

Though having it issue events to subscribers (only now keyboard/mouse events) isn't too conceptually oblique. It's just translating OS to engine.

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!