Jump to content
  • Advertisement
Sign in to follow this  
YengaMatiC

Input subsystem, active or passive?

This topic is 5092 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 designing the input subsystem and i want to show you both approaches i thought. Active: event driven system that propagates mouse/keyboard events to system that wants some input. -Pros: you can set a priority queue of callbacks which receive the input, so systems that are gathering for input don't overlap others (a menu has more priority over the rest). -Cons: there are so much function calls, one for every event (key pressed, released or still-pressed). Passive: saving old and actual keyboard/mouse state and waiting for other modules to querying it. -Pros: the input system doesn't have to bother about who wants input, it only has to answer questions like 'is left arrow pressed?'. -Cons: you have to control the way other systems have priority over a system that wants input (menu-ingame example). Sure there will be more pros-cons to each system, but that's what i want you to discuss here :) EDIT: it's an input module for a game engine.

Share this post


Link to post
Share on other sites
Advertisement
You don't mention what you're actually making. In an application the additional function call overhead a push-model would incur would be negligable. In a game, it depends.

Share this post


Link to post
Share on other sites
Hmmm, well. Although it's for a game input subsystem, i've thought that there are not many function calls because there aren't that much key events each frame. We only have 10 fingers! :) So that fact wouldn't really be a con.

Share this post


Link to post
Share on other sites
I would use your active approach. Almost all the game programming books I've seen that touch on the issue uses similar strategies. I seriously doubt that it will add much overhead, even for a game. Even on an input-intensive game, you will almost never have more than 8 events in a given frame, and most of the time it will be less. Also, given the extra programming that would be required for each input listener to figure out if it has priority, I doubt that the passive model will be all that more efficient, and the implementation would probably be more messy.

Share this post


Link to post
Share on other sites
I did it the second way, for an active game and it worked fine, i simpley had all input publicly available to the class that wanted it.

ace

Share this post


Link to post
Share on other sites
I would say that you should primarily use the Active system. The number of function calls is really minimal. The way to do this is to have a binding system for each key: have the system register a callback to be called when a particular key is pressed. Then when you receive an input event from the OS, you check if it has a binding - if it has call the callback. Likewise you only generate key released events when the key has a binding - its pointless to tell your engine about release events on keys that do nothing! You don't need to have a still-pressed event - just ignore key repeats from the OS - you can generate your own key repeat system if you want key repeats for text input etc.. - the engine should hold a latched state as to whether the key is down or not. The only problem you will get then is if the app loses focus - you may not receive a corresponding key release event - so if your app loses focus just send a key release event for all keys that are down.

James

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!