Hardware cursor and buffered input

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
Post Reply
User avatar
psiegel
Kobold
Posts: 28
Joined: Sun Aug 29, 2004 5:51 pm
Location: Boston, MA
Contact:

Hardware cursor and buffered input

Post by psiegel » Thu Jan 06, 2005 7:35 pm

Does anyone know if ogre supports use of a hardware cursor with buffered input, and if so how to set it up? I find after creating and initializing the EvenProcessor object, the window takes control of the mouse and removes the cursor icon. Now, I could obviously create a software rendered cursor by getting the CursorGuiElement and setting its material which is ok in fullscreen mode, but in windowed mode the cursor is trapped by the window and cannot be used to perform any operations on the window (move, close, minimize, etc.)

Paul
0 x

User avatar
psiegel
Kobold
Posts: 28
Joined: Sun Aug 29, 2004 5:51 pm
Location: Boston, MA
Contact:

Post by psiegel » Mon Jan 17, 2005 9:28 pm

If you'll excuse my bumping myself, I find it very surprising that nobody uses Ogre in a window and wants to track mouse input. Somebody must be doing it. Please help me!

Paul
0 x

User avatar
pjcast
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2543
Joined: Fri Oct 24, 2003 2:53 am
Location: San Diego, Ca
Contact:

Post by pjcast » Mon Jan 17, 2005 9:35 pm

You have to modify the input system Ogre uses, and change the cooperation level of DirectX.

The input system is designed to do what is needed the majority of the time... And that is keep input. For any special needs, and most games qualify, you will need to modify it to suit your needs.

There is also a post floating around about using the windows message pump to do input. I suggest you search the forums for all the various discussions on input.
0 x
Have a question about Input? Video? WGE? Come on over... http://www.wreckedgames.com/forum/

qsilver
OGRE Community Helper
OGRE Community Helper
Posts: 198
Joined: Sat Oct 02, 2004 9:11 am
Location: San Francisco, California, USA

Post by qsilver » Tue Jan 18, 2005 12:15 am

Yes, you will need to write your own InputManager code and cursor support functions. Or skip InputManager entirely, use your own input framework (ATL / MFC / whatever) and provide a window handle that Ogre can use for rendering.

If you hack up the InputManager code, these may be useful:
http://msdn.microsoft.com/archive/defau ... Cursor.asp
http://msdn.microsoft.com/archive/defau ... erties.asp
0 x

nfz
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 1263
Joined: Wed Sep 24, 2003 4:00 pm
Location: Halifax, Nova Scotia, Canada

Post by nfz » Tue Jan 18, 2005 12:21 am

I'll be another one to recommend that you should build your own input manager. Have a look at this thread for some inspiration: http://www.ogre3d.org/phpBB2/viewtopic.php?t=7457.
0 x

User avatar
psiegel
Kobold
Posts: 28
Joined: Sun Aug 29, 2004 5:51 pm
Location: Boston, MA
Contact:

Post by psiegel » Tue Jan 18, 2005 2:01 pm

Well, thanks for the pointers everyone. I found it surprising that hardware cursors were not supported out of the box, but I suppose it's fairly common for game-oriented engines to skip out on real support for windowed mode. I took a look at the Win32Input and Win32Input8 classes, and it looks like it wouldn't be difficult to hack some changes in for hardware cursors for now. (Just a matter of using DISCL_NONEXCLUSIVE for the cooperative level on the mouse device and commenting out the ShowCursor(FALSE) call).

Maybe in the long run it's best to write my own input manager, but I do worry about stuff like picking, which I haven't quite looked into yet but assume I will need down the road.

Thanks for the response guys.

Paul
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19263
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Tue Jan 18, 2005 6:11 pm

If you're doing a windowed mode application you might want to just plug the Ogre rendering into an existing window instead anyway (see the setExternalWindowHandle method). We're not an input library, we just do graphics - the input code that is there is just for convenience, there were far too many platform-specific ways to do other forms of input for us to support out of the box.
0 x

Post Reply