Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MostAwesomeDude]

Hi. I'm using Irrlicht for a game, and want to use OIS for joystick support. (SDL is out of the question, since it interferes with OpenAL if OpenAL is using SDL for sound. Long story.) Anyway, I am using Irrlicht for keyboard input (no mouse,) and want to keep using that, having OIS generate joystick events which are translated to Irrlicht events and forwarded to the Irrlicht event handler.

Anyway, I'm stuck at the very beginning. OIS::InputManager::createInputSystem() wants an OIS::ParamList or window handle of some sort. However, it crashes on an empty ParamList, and I have no handle to feed it, since I am on Linux. Everything else aside, is it possible to createInputSystem() without a window handle, and just have joystick support?

Thanks.
~ C.

[pjcast]

Hello, you are right in that currently it needs a window handle. Though, it shouldn't crash, but throw an exception. It is currently looking for an X11 Window ID. However, you are correct in that for Joystick support only, it would not really need that Window ID. You could simply modify the x11 input manager to just disable keyboard / mouse support (and anything it does to X11) when no window handle is passed in. Something like adding a check for mWindow (or whatever it's called) == 0, then return no mice/keyboards, and do nothing with X. Should be a simple fix, but I am not currently setup with a working Linux environment, so have no ETA when I could accomplish it.

[MostAwesomeDude]

Yo. I think I will just patch it myself to disable keyboard and mouse if no window handle is passed, and to return null pointers for the keyboard and mouse managers. I was expecting this, anyway. Thanks!

~ C.

[OvermindDL1]

That would be nice to have.  Should disable the hard requirement of a window ID, and disable everything that relies on it, such as the normal keyboard and mouse.  There are still ways to get keyboard and mouse input without needing a window handle (at least for windows) and I could make a module for that sometime easilly.

[vectrex]

Hi, I'm having a similar issue. I'm seperating my renderer completely from the gameplay. Here are the issues

- The renderer is a seperate process which is started by the gameplay process. So the ogre window might not be ready when OIS wants it.
- Also the renderer may not even be running on the same computer. It's a networked thing so any number of computers can be renderering views. So no guaranteed window handle.

It was mentioned that for win32 it could run without a window handle? Any other ideas? I started doing this without it ever occuring to me that input relied on graphics. Seems like a weird design of the OS to me 

[pjcast]

It is not that input relies on graphics. It is that input relies on a window handle being used by the user. This is a concept of operating systems. The fact is that graphics relies on a 'window' to render to, while input relies on a 'window' to get focus from. You can't think of a HWND/Window handle/etc as a graphical thing, it is not. You can have a window of size 0x0 and as long as it has focus, you can get input events from it - though, mouse would be about useless with such a size window - but never the less.

Anyway, there is no way in windows (on linux there are some methods) for a nicely behaved application to get input without a window (maybe keyloggers don't have that restrictions).

Also, OIS is an OS level thing, so it should really reside in the same thread as the UI/GUI/Window. If it doesn't, you will get issues. You can separate this out a bit if you don't use Ogre to push OS events around. The easiest method, when dealing with Ogre, is to at least have Ogre and OIS in the same thread. You may not expereince many issues on Windows and Linux, but on OSX at least, the Ogre handlers push events to OIS from whatever thread it operates on - and OIS is not thread safe that way, which will cause issues.

[vectrex]

Also, OIS is an OS level thing, so it should really reside in the same thread as the UI/GUI/Window. If it doesn't, you will get issues.

What issues?

The easiest method, when dealing with Ogre, is to at least have Ogre and OIS in the same thread.

Yes that's true, but I might not even be running ogre on the same computer. If it IS on the same computer it will still be a seperate process not thread and the gameplay and renderer processes can start and stop independant of each other.

You may not expereince many issues on Windows and Linux, but on OSX at least, the Ogre handlers push events to OIS from whatever thread it operates on - and OIS is not thread safe that way, which will cause issues.

Hmm, I'm not quite sure what that means. Is it to do with OS messages being pumped by the initial process? Because I'll have 2 processes.

[pjcast]

It doesn't really make sense to have two different processes (did you mean threads?) for one app - one for Ogre and one for OIS? OIS needs to be on the UI thread, in the process the window was created in, which ever that is. Issues you will see are simply threading issues (probably most relevant only on OSX - under Linux and Windows at least, OIS should be able to be decoupled from UI thread) - OIS is not thread safe.

[vectrex]

It doesn't really make sense to have two different processes (did you mean threads?) for one app - one for Ogre and one for OIS?

I meant processes Yes normally it'd be threads. I'm putting my renderer in it's own process because for a simulator engine it's important to be able to run multiple renderer windows on seperate computers. Think super DUPER widescreen surround with 8 displays So the renderers will just connect to the gameplay process via networking style communication, whether they're running on the same physical computer or not. I was thinking that OIS could run inside the App process, not the renderer process since the renderer is the 'view' part and the app is the only thing that will actually use any input data.

OIS needs to be on the UI thread, in the process the window was created in, which ever that is. Issues you will see are simply threading issues (probably most relevant only on OSX - under Linux and Windows at least, OIS should be able to be decoupled from UI thread) - OIS is not thread safe.

Can I pump OIS from my app and just give it the window handle from a renderer process? My flatmate said I could just create an invisible 'window' so the app process can get input even if there's no actual ogre window running.

[pjcast]

Unfortunately, one cannot simply use another processes Window (at least not under Windows) without gong through some other means (such as Window's hooks). And certainly not with DirectInput (what OIS is using on Windows). You can certainly create a hidden window (making it the same size as your viewport), just make sure it always has focus. Or, it is also possible to setup OIS/DirectInput to handle Background/NonExclusive Mouse/Keyboard/Joystick so that no matter what state the Hidden window is in, it should get input events.

[vectrex]

ok thanks. That sounds like a workable solution. Although I imagine there's going to be some weird problems using what sounds like a hack I'll have to keep an eye on changing res or window/fullscreen toggles I'd imagine.