Input System
Moderator: PPS-Leaders
Input System
Recently I have been thinking a little bit about the input system.
First of all, the basic concepts are of my major concern.
I've got two different approaches:
i) Write an input manager that can handle different input modes, esp. game play and GUI. That means we would have to tell the input system which mode it is at the moment and then the system distributes the input accordingly (e.g. to the CEGUI or to the whatever, I haven't thought about this very clearly yet).
ii) Input listeners. The issue is that OIS can only have one listener for each device. So we would have to create a mid-way manager that can handle multiple listeners (exactly like the class InputManager in src/orxonox).
This approach however has the obvious disadvantage of the listeners behaving "politely" in order to prevent a chaos.
For my taste, the second approach sounds better since the input manager has less responsibility. So whenever the Orxonox mode switches from game play to GUI, the input switching has to occur in the GUI or game play.
First of all, the basic concepts are of my major concern.
I've got two different approaches:
i) Write an input manager that can handle different input modes, esp. game play and GUI. That means we would have to tell the input system which mode it is at the moment and then the system distributes the input accordingly (e.g. to the CEGUI or to the whatever, I haven't thought about this very clearly yet).
ii) Input listeners. The issue is that OIS can only have one listener for each device. So we would have to create a mid-way manager that can handle multiple listeners (exactly like the class InputManager in src/orxonox).
This approach however has the obvious disadvantage of the listeners behaving "politely" in order to prevent a chaos.
For my taste, the second approach sounds better since the input manager has less responsibility. So whenever the Orxonox mode switches from game play to GUI, the input switching has to occur in the GUI or game play.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
So far I have coded the basic construct for the InputHandler.
What I'm going to do next:
Capture all the input and then either plug it into CEGUI OR encode the keys (like up, down, a, s, d, enter, etc.) into 'orxonox actions' like MoveForward, Fire, ShowMenu. Each of them has an integer number assigned.
To actually get these messages, any class can (via Listener) register an object in the InputHandler (multiple listeners allowed).
That of course means that every part of the program who wants input needs to encode the actions (instead of keys) once again. But I don't see a problem in that.
Now I've got a serious question for the network guys:
Am I doing things in a way that it works with your network support?
As far as you have explained to me, you have already programmed such a scenario.
What I'm going to do next:
Capture all the input and then either plug it into CEGUI OR encode the keys (like up, down, a, s, d, enter, etc.) into 'orxonox actions' like MoveForward, Fire, ShowMenu. Each of them has an integer number assigned.
To actually get these messages, any class can (via Listener) register an object in the InputHandler (multiple listeners allowed).
That of course means that every part of the program who wants input needs to encode the actions (instead of keys) once again. But I don't see a problem in that.
Now I've got a serious question for the network guys:
Am I doing things in a way that it works with your network support?
As far as you have explained to me, you have already programmed such a scenario.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
oh, thanks for the reminder that we've already got a lot of source code. I think I've never had more than a glimpse at the old code..
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
I've just had a quick look at EventHandler and EventListener in the old orxonox code. But as far as I can see an object had to subscribe for every event it wanted to capture.
I was rather thinking of something like the inter process messages. In that case every object receives all the events (key binding independently) and can choose which to process.
This would also simplify network communication.
I was rather thinking of something like the inter process messages. In that case every object receives all the events (key binding independently) and can choose which to process.
This would also simplify network communication.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Everything should be possible so far The question is, whether the chosen solution will also be the best (fastest, most stable) solution ...1337 wrote:Now I've got a serious question for the network guys:
Am I doing things in a way that it works with your network support?
As far as you have explained to me, you have already programmed such a scenario.
I might have found a new problem. This is the line we inserted in the InputManager to resolve the linux OIS crash problem when key repeat wouldn't work anymore:
However, it's not without side effects: Last time I tested the new console on tardis, the key repeated in orxonox when holding. And on windows they wouldn't.
That of course messes with KeyPress and KeyRelease events...
Maybe, I can find another solution for the OIS problem, but the only thing I can think of is the signal handler.
So, I've written a ticket to extend the SignalHandler. Unfortunately I have absolutely no idea about signal handling...
Code: Select all
paramList.insert(std::make_pair(std::string("XAutoRepeatOn"), std::string("true")));
That of course messes with KeyPress and KeyRelease events...
Maybe, I can find another solution for the OIS problem, but the only thing I can think of is the signal handler.
So, I've written a ticket to extend the SignalHandler. Unfortunately I have absolutely no idea about signal handling...
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
I've just found this link. It's not directly talking about your problem, but it's something about tcl and autorepeat, maybe there is some input you could use... http://wiki.tcl.tk/20299
Thanks, I read part of it. But as I see it, this is more low level than we have. We would have to fiddle with OIS internals (compile our own OIS) if we were to to apply the suggested methods.
This problem has to be solved in another fashion.
This problem has to be solved in another fashion.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Some time ago there was a problem with the OIS specific code.
Today, I've updated my libraries to ois 0.7.2, 1.0 and 1.2.0. I was hoping to make all three of them run. However, 0.7.2 makes problems. As soon as the mouse is moved I get a segfault. Somehow, the event argument seems to be empty, i.e. not allocated.
Spending some time on google and the ois forum, I have decided that it would probably take too much time to make the input system work with OIS 0.7.2, so I'm not going to support this version.
That means, running orxonox would require OIS version 1.0 or above (only 1.2.0 currently), but the tardis boxes are already prepared.
I don't think that old versions should pose a problem: 0.7.2 is dated mid 2006 , 1.0 December 06 and the brand new 1.2.0 is only 5 weeks old.
I hope those of you wither older versions (if any) can update without trouble.
Today, I've updated my libraries to ois 0.7.2, 1.0 and 1.2.0. I was hoping to make all three of them run. However, 0.7.2 makes problems. As soon as the mouse is moved I get a segfault. Somehow, the event argument seems to be empty, i.e. not allocated.
Spending some time on google and the ois forum, I have decided that it would probably take too much time to make the input system work with OIS 0.7.2, so I'm not going to support this version.
That means, running orxonox would require OIS version 1.0 or above (only 1.2.0 currently), but the tardis boxes are already prepared.
I don't think that old versions should pose a problem: 0.7.2 is dated mid 2006 , 1.0 December 06 and the brand new 1.2.0 is only 5 weeks old.
I hope those of you wither older versions (if any) can update without trouble.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Another matter: Does anyone have 2 joysticks? I would be very interested to see whether my plan to support n joy sticks actually works.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
I think that game pads qualify as joy sticks in OIS. If not, well then there is no support.
And thanks for the reminder, there happens to be one of these somewhere in my house catching dust...
And thanks for the reminder, there happens to be one of these somewhere in my house catching dust...
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
hmm, I would really like to see orxonox being played with game pads one day...beni wrote:I like the gamepads. In the Ogre forums they use OIS or SDL to make them work.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Who is online
Users browsing this forum: No registered users and 12 guests