Print

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

[Grey]

Hey pjcast, I thought this might be a good place to ask, you might have seen the InputManager I posted on the forum's, and will Wiki sometime soon, (See http://www.ogre3d.org/phpBB2/viewtopic.php?t=18398 for now), I was writing a wrapper for OIS with this system, so that it behaves the same but does not require the Ogre Input system (Got some negative replies in another post with mafm regarding the x repeat behavoir) since it seems the ogre dev's really don't want to mess with or support the native Ogre input system, (And I can understand and respect that, they've made their position pretty clear), I do however want the choice of which input system to use, and wanted to make it pretty easy to choose between the two, Check out

http://tiphares.grevian.org/~grey/files/input/OISFrameListener.h
and http://tiphares.grevian.org/~grey/files/input/OISFrameListener.cpp

as well as http://tiphares.grevian.org/~grey/files/input/InputReceiver.h

and you'll see what I'm doing to try and keep it all consistent, It should work except that the keyPressed methods for OIS use the OIS::KeyEvent argument and not the Ogre::Keyevent, I was wondering if there was any easy way to convert between the two? I checked out there definitions, but I'm not sure if something like static_cast'ing it would work, the definitions looks slightly different? also can you put a #define into the next version of OIS so I can tell if it's being used or not? you'll see I use #ifdef USE_OIS, and currently I just compile with -DUSE_OIS for testing, but something I can check for without having to specify it directly at compile time would be nice.

Thanks for the info, and good work on OIS btw, it seems really useful, most of my own code is just wrapping and feature fluff

[pjcast]

Yeah, I have notcied your thread on Ogre's forums I do not think Ogre's Devs are interested in any input patches, as the last disscussed plan was to integrate OIS as a dependency for the Ogre demos in the next major version of Ogre... This is for simliar reasons as using CEGUI instead of the inbuilt Ogre GUI. Ogre is a rendering engine, and hence does not support internally (or should not) input. It was there for convienence.

OIS has the added benifit, since Ogre is trying to move forward in the console platform world, of having a less strict license then SDL for instance, so can be ported anywhere. So, perhaps you should not really be looking to support both OIS and Ogre's input? If anything, you could be looking at supporting the various other input systems in addition to OIS (ie. SDL, libGII, etc) - just a thought.

As for your issues. The only way I see of converting to an OgreKeyevent ( a much more complex object then a OIS::KeyEvent ) is to just use the constructor Ogre::Keyevent( , , , , ) passing in the equivalent OIS::KeyEvent properties to it. Or, you could wrap it up instead and not use either Ogre::Keyevent nor OIS::KeyEvent but your own KeyEvent structure and fill that in with the info you recieved from ogre or ois.

As for the USE_OIS define. I think that should be trivial to add. But, I kinda don't see how you plan on including it? If you are using the USE_OIS to conditionally compile in OIS headers, then how will you include the needed file that defines the define? Also, I don't really know if the define USE_OIS is really useful in many cases, could a OIS_VERSION macro work better? as that could be useful in other situations to.

[pjcast]

Another thing i just thought of, is that Ogre's keyevent structure has much more information than OIS's KeyEvent.. not sure what values in OIS actually would correspond to Ogre's Keyevent class data either. Mostly, i think PositionTarget* source and int id do not have 1:1 mapping. And, you may need to fiddle with the Modifiers.

[Grey]

Cool, Ok I'll see what I can do, I don't really want to add another layer of complexity by creating my own KeyEvent, but I may just pass those KeyEvent's through constructing Ogre::KeyEvent's that may not have everything in them, I'm not TOO concerned about it right now, and maybe I'll just switch over to 100% OIS in the future if they remove or replace the native Ogre input system. As for the #define, durrr of course your right, a version macro would be nice, and maybe something so we know if joystick/FF support is in or available.

Thanks for the fast reply

[pjcast]

You can poll the joystick for detecting if FF support is present. but of course, if no joystick support is present, then you cannot.. so, hmm. The only places where joystick is not supported as of now are MacOSX and BSD... I plan on installing BSD (along with Fedora Core 5) in the next week, where I will work on getting BSD support fully. I may switch entirely to XInput for X Events, as that should allow OIS to work everywhere where X is the primary window system (ie Linux, BSDs) - but, that requires much refactoring of the Linux OIS system.. and, for now, it will be easier to just write joystick support into a BSD port.

[OvermindDL1]

If you have not yet installed BSD to test, DesktopBSD came out in final recently, desktopbsd.org is the website, it is FreeBSD5 with a large host of graphical tools and utilities to make doing just about everything easier.

[pjcast]

Well, I did download FreeBSD, and manage to install that. But, while attempting to dual boot, I managed to screw up my primary OS (Win2000 - which I had to reinstall), so, I decided to instead install FC5 over the failed BSD attempt. Which of course, also does not dual boot well for some reason.. perhaps it is because Win2000 is on hda1, and that is a ntfs partition... I never had a ny problems before when Win98SE was installed on hda1 with a FAT32 partition, Win2000 somehwere on hdb along with linux, and a linux /boot on hda2..

But, I do not have time to play with partition locations. So, anyway, I have a boot CD for FC5, and the default Win2000 Bootloader for Windows. If I happen to run into some serious cash anytime soon, I will be looking into upgrading (time for a new system With PCI-express, and dual cores - as oppsed to dual CPU rig I have now).

And, I would probably use the current system as a test box for installing various Linux/BSD's, but not now. Though, if I ran into some serious cash, I would also consider purchasing a Mac, IMHO, more worth supporting then BSD anyway

[OvermindDL1]

If I had the money I'd get a Mac OSX 10.4.  Can run everything BSD can (including bsd apps and linux apps with the linux layer for bsd. ).