🔒 Locked 🎮 Unity

Kernel Event/Input System

Started by tstrimp Apr 19, 2006 at 12:13 PM 4 replies 900+ views

Original Post

Apr 19, 2006 at 12:13 PM

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]

tstrimp

Apr 20, 2006 at 8:52 AM

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]

Koshmaar

Apr 20, 2006 at 9:28 AM

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 :-)

tstrimp

Apr 20, 2006 at 9:45 AM

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.

Koshmaar

Apr 20, 2006 at 11:23 AM

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)().

tstrimp

Apr 20, 2006 at 11:35 AM

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?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.