wxOgre Input Events Handling

bigjhnny

29-07-2006 22:54:52

Sorry for the newbie question.

I currently have pyOgre integrated with wxPython like it is shown in the forum by Istari.

http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=1474

I am still using the windows binary build of pyOgre 1.06.for python2.4.

My question is:

What is the best way to handle buffered and unbufferred inputs for my ogre window within wxPython?

Currently, I'm still using the Ogre built-in input reader, and I find that my mouse is basically overtaken by the ogre window. I.E.: I won't be able to navigate out of the ogre window to other wxPython widgets.

I suspect that disabling the input reader of Ogre would give control back to wxPython. However, is there anyway to do unbufferred inputs in wxPython? I haven't found a way using wxpython to say something like:


if inputReader.isKeyDown(KC_W):
bla bla ....


I suppose I can keep track of the bufferred events to derive the isKeyDown.... But I just thought to ask here before I go that route.

Thanks for any help.

Istari

30-07-2006 00:08:16

You could try using PyOIS and bind it to the same window handle that you use for the Ogre window.

bigjhnny

30-07-2006 03:07:10

Hi! Thanks for the response. I am going to give pyOIS a shot.

In attempting to do this, I discovered that I needed to switch to pyOgre1.2 in order to get the window handle of a render window, namely the "getIntCustomAttribute" method provided only in ogre 1.2.

Now, in trying to use the latest binary build of pyogre 1.2 for python2.4, I get


File "C:\Python24\lib\site-packages\pyogre\cegui.py", line 4, in ?
import _cegui
ImportError: DLL load failed: The specified module could not be found.


Looking for OPENGLGUIRENDERER.DLL

I saw your recent post about changing build system, does this mean I need to compile from source? I hope not as I'm really not set up at all on compiling from source yet.

Thanks again.

Istari

30-07-2006 03:52:48

You don't absolutely need PyOgre 1.2.
You can just pass the result of the GetHandle() method of the wx window that PyOgre is rendering into.

You shouldn't need to build from source. PyCegui is giving me some trouble, it doesn't seem to link correctly.
It's just in the binaries .zip file because I'm using a script to build and package the binaries automatically.

bigjhnny

30-07-2006 04:06:33

I had actually already tried that. This is the result.


self.keyboard = self.inputReader.createInputObject(ois.OISKeyboar
File "ois.py", line 1064, in createInputObject
ois.ois.Exception: Win32Keyboard::Win32Keyboard >> coop error!


Checking from the OIS forum, pjcast mentioned that this is mostly likely a result of passing an invalid window handle.... Therefore, I started to try pyogre1.2...

Sorry to be a pain here, maybe I should wait till you fix the pyogre1.2 binary zip. BTW, great work with the binding here, it's very useful.

Thanks,

John

Istari

30-07-2006 05:57:12

That's strange. It works fine in the wxPython demo I wrote for PyOIS...

This works fine for me in a console:import wx, ois

app = wx.App(False)
mainFrame = wx.Frame(None, -1)
mainFrame.Show(True)

oisParams = {
WINDOW = str(mainFrame.GetHandle())
}

inputManager = ois.InputManager.createInputSystem(oisParams)
keyboard = inputManager.createInputObject(ois.OISKeyboard, True)
keyboard.enableEvents()

def printKeyEvent(arg):
print '\nkey pressed {%d, %s} || character (%c)' % (arg.key, arg.device.getAsString(arg.key), arg.text)
return True

listener = ois.getEventListener()
listener.addListener('keyPressed', printKeyEvent)

def captureKeyboard():
keyboard.capture()
wx.FutureCall(10, captureKeyboard).Start()

wx.FutureCall(10, captureKeyboard).Start()
app.MainLoop()

bigjhnny

30-07-2006 16:40:36

The above code works for me as well.

It must be the fact that I'm using a wx.Panel for ogre then. Doing the following:


...
app = wx.App(False)
mainFrame = wx.Frame(None, -1)
mainFrame.Show(True)
panel = wx.Panel(mainFrame, -1)

oisParams = {
'WINDOW': str(panel.GetHandle())
}
...


or


...
app = wx.App(False)
mainFrame = wx.Frame(None, -1)
mainFrame.Show(True)
window = wx.Window(mainFrame, -1)

oisParams = {
'WINDOW': str(window.GetHandle())
}
...



yields the error:


keyboard = inputManager.createInputObject(ois.OISKeyboard, True)
File "ois.py", line 1064, in createInputObject
ois.ois.Exception: Win32Keyboard::Win32Keyboard >> coop error!


I thought I could use any wx.Window subclass. Am I missing something obvious?

Istari

30-07-2006 17:45:58

This is from the DirectX documentation for IDirectInputDevice8::SetCooperativeLevelhwnd
Window handle to be associated with the device. This parameter must be a valid top-level window handle that belongs to the process.

I thought that it would work for any window handle, but it seems that I was mistaken.

bigjhnny

30-07-2006 20:17:39

Ok that clears it up a little.
To solve my original problem then, does this mean I have two options:

1. use OIS in conjunction with wxPython input system (have access to the global unbufferred inputs to the root window using OIS). I will have to manage when to give control to OIS to access the unbufferred inputs (i.e.: when the ogre window has focus) and when to give control back to wxPython for wx GUI stuff (when the ogre window loses focus).

2. use wxPython inputs only (and forget unbufferred inputs). What do I really lose then by not having unbufferred inputs? Bufferred inputs are just events fired into the event queue of wxPython, so there won't performance issue since wxPython is already doing this anyways?

Is this valid?

Thanks,

Istari

30-07-2006 21:31:13

Those seem to be your options, yes.

I don't think that using buffered wx events is a problem, since wx and ogre are only updated as a result of the wx message pump anyway.
So I don't think you will notice a difference in input response time, because the whole thing is only as fast as the slowest part.

bigjhnny

31-07-2006 16:13:45

Just thought to let everyone know I'm going the #2 route, which is just to use wxPython's inputs. There seems to be some unbufferred support in wxpython:


wx.GetKeyState(SomeKeyCode)


Although in the documentation for this method, it claims to not always work for all keys in some platforms. It has worked for me so far in win32. :lol:

I hope working with the mouse events would be as smooth once I need it.

Thanks again, and keep up the good work!

dermont

01-08-2006 21:28:45

Sorry for hijacking your thread but since cegui linking problem was mentioned here, just a note on cegui you can swig/compile/link for ogre renderer by updating the command line Pre-Build Event to

C:\swig\swigwin-1.3.29\swig -DOGRE_RENDERER_ONLY -O .....

Regarding the OPENGLGUIRENDERER.DLL problem I believe that the DLL is not included in Istari's package. One thing that caused me problems when trying to run cegui on mingw linked to both ogre and opengl was that GLUT32.dll needed to be in the site-packages dir.
The default should be -DOGRE_RENDERER_ONLY. I've been using it on XP/98 - VC8 and Mingw, 3 different linux distros for CEGUI0.41 and the libs supplied with Ogre.