Getting OgreNewt to work with OIS

Horizon

13-08-2006 08:51:47

I just got the latest Ogre and OgreNewt from CVS. OgreNewt won't compile, however, because the OgreInput system has been removed. I'll give fixing it a try myself, but in the meanwhile I was wondering if anybody happens to have done this already? If so, could you maybe post a patch here? Thanks.

Horizon

13-08-2006 10:20:40

I've already changed the BasicFrameListener and am now working on the first demo. When that's done I'll go back to my own project for a while but may finish the other demo's later.

kjs335

13-08-2006 11:04:59

I just got the latest Ogre and OgreNewt from CVS. OgreNewt won't compile, however, because the OgreInput system has been removed. I'll give fixing it a try myself, but in the meanwhile I was wondering if anybody happens to have done this already? If so, could you maybe post a patch here? Thanks.
Did you update it?
I've had similar problem where OgreNewt won't compile because it can't find Input class so I completely deleted and reinstalled Ogre and OgreNewt. Then it compiled with no error.

It is worthy of trying I think.

walaber

13-08-2006 16:30:49

when I get a chance, I will upgrade my copy of Ogre, and then fix any problems with OgreNewt. I might get come time today, we'll see.

Horizon

14-08-2006 13:21:48

This is slightly trickier than I thought:

OIS only allows for the existance of a single InputManager. In order to use input in the BasicFrameListener (only for wireframes) while using an OgreNewtonFramelistener together with a BasicFrameListener (as in the demos) you need to find a solution which allows developers to handle input in some other FrameListener which doesn't inherit from BasicFrameListener.

I see two options:
- Remove debug mode from BasicFrameListener
This has the downside that you can't tell people to check wireframes as a first debug method by just pressing F3;
- Pass BasicFrameListener an InputManager
Doesn't seem to nice either, even if you'd make it optional (check if im != 0);

NB The demos use ExampleFrameListener which also creates an InputManager, so no possibility of creating an InputManager in OgreNewtonFrameListener (in the demos) either, here, however, we can access the already existing InputManager because we are inheriting from ExampleFrameListener.

Horizon

14-08-2006 13:51:38

I've got Demo1 working by removing the debug mode key from BasicFrameListener. If you want I can send you my changes (as a patch?) so you can evaluate them and apply them if you like.

praetor

14-08-2006 14:23:52

The next version of OIS will decentralize the input system. The InputManager will no longer be a singleton, so that multiple input system can be created for multiple windows.

walaber

14-08-2006 21:42:10

i forgot that we are talking about the HEAD branch of Oger here, which is still a bit away from release. for now I will leave OgreNewt as is, which is compatible with the 1.2 branch of Ogre.

pjcast

14-08-2006 21:45:58

The current OIS cvs head (to be 1.0) has already removed the singleton nature. However, this only affects creating OIS for multiple windows. Not having multiple listeners per device.

very simple to overcome if you need multicasting. Just, have an input layer that listens to OIS events, and broadcasts them via a listener system (check Ogre wiki for OIS input manager there).

OvermindDL1

17-08-2006 03:28:46

This is how I do input in mine, maybe a bit more all-inclusive then what you need, but could give you an idea.

There is an event/action system, an event is just a string, something like "Walk" or "W_Press" or "W_Release" or whatnot. The action is a string that is just a script to do actions, here is an example:

Got alias's and all such working too, finalized the keypress names too...
// Some default commands, mostly for testing...
// NOTE: Something fancy for testing, should just expose a toggleConsole() function...
Console::getSingleton().bindToAction("consoleOn", "showConsole();bind(\"Tilde_Press\",\"callAlias('consoleOff')\")");
Console::getSingleton().bindToAction("consoleOff", "hideConsole();bind(\"Tilde_Press\",\"callAlias('consoleOn')\")");
Console::getSingleton().bindToAction("Tilde_Press", "callAlias('consoleOn')");


Also got a console, togglable using the key it is set io (tilde by default as you see). The console is operational so you could open it and type:
bind("consoleOn", "showConsole();bind('Tilde_Press','callAlias(\'consoleOff\')'))
bind("consoleOff", "showConsole();bind('Tilde_Press','callAlias(\'consoleOn\')'))
bind("Tilde_Press", "callAlias('consoleOn')")

to do the same thing...


And when the ~ key is hit, the "Tilde_Press" event is sent, when it is released then the event "Tilde_Release" is sent. When 'w' is hit, then the "W_Press" event is sent, and so on and so forth. It is designed so a key should call another event like 'W' should call an event named "WalkForward" or what-not. It is actually a bit more advanced now then what is show above as param's can be passed and so on.