Jump to content
  • Advertisement
Sign in to follow this  
tstrimp

Kernel Event/Input System

This topic is 4419 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 trying to create an event system to make handling user input a lot easier. I've settled on an input class that maps keys to events and then passes an event based on the key pressed to the event handler which then distributes it to the classes that are subscribed to the event. Pretty simple stuff. I'm running into a design issue reguarding tasks and the kernel though. While the input system is a Task it does nothing with the inherited update function. It just sets the function call back when the task starts. The event handler most likely will not make use of an update either. I could queue events and input and then distribute them on update but I'm don't think that gains me anything but consistency. Should I just build these 2 tasks in with the window task since all they need is the Start() method? Should I go ahead an queue the input and events so that they could make use of the Update method? One advantage of that is there is one place to monitor outgoing input and events but is it worth the overhead? Any insight into this issue would be appreciated! Thanks, Tim [Edited by - tstrimp on April 19, 2006 12:32:19 PM]

Share this post


Link to post
Share on other sites
Advertisement
I decided to go with an input and event queue and to push those out to their listeners on the kernel Update. This will let me better control on when messages are delivered. It would be nice if someone had an opinion on it though. [wink]

Share this post


Link to post
Share on other sites
So, you say that code which was going to be put into Input task will be completely transferred to Kernel task, and Input task will be removed (I understood your post this way, I hope that's what you meant)? Sure, why not, if your Input::Update() method was blank and Input::Start() was shorter than, say, 15 lines, then input code probably won't clutter Kernel too much. However, if you plan to improve and extend your input handling capabilities in the future, you may want to stay with separate Input and Kernel classess, just to be safe.


Btw, though I designed my system in different way (getInput.GetKeyNowPressed(SDLK_whatever) etc. used extensively and one way to emulate events, which are used very rarely) I think that your version should prove oneself. Good luck :-)

Share this post


Link to post
Share on other sites
Quote:
Original post by Koshmaar
Btw, though I designed my system in different way (getInput.GetKeyNowPressed(SDLK_whatever) etc. used extensively and one way to emulate events, which are used very rarely) I think that your version should prove oneself. Good luck :-)


Thats what I wanted to avoid. Idealy, a task that needs input will subscribe to an event. The some of the events are subscribed to input. Then when the user presses a key. The input handler fires of the events that are tied to it and the events alert the subscribed tasks that the event has occured.

I'm hoping this will make it very easy to modify user input.

Share this post


Link to post
Share on other sites
Yup, probably it'll prove to be useful, just remember to develop flexible and easy to use callback system , sth more sophisticated than simple pointers to functions (maybe functors? or signals and slots?), since they're rather tedious to use.

...

After second thought, now I think that even simple pointers should suffice :-) All in all, such callback would be just plain void (*function)().

Share this post


Link to post
Share on other sites
The event handler has a pointer to the task that has subscribed to it. All tasks inherit an alert member function that the even handler uses to pass events on to the task. Am I missing any obvious flaws here?

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!