libgii quirks and questions

Problems building or running the engine, queries about how to use features etc.
User avatar
discipline
OGRE Community Helper
OGRE Community Helper
Posts: 766
Joined: Mon May 16, 2005 12:09 am

libgii quirks and questions

Post by discipline »

Ok finally got libgii compiled and working. The wiki mentions upgrading to 0.9.x to fix some nasty GLX bug. I'd emphasize that more. Pre 0.9.x wouldn't work at all on my system.

So now it is working, but I have some minor issues and the libgii documentation, mailing lists and forums suck. :x

1) When in full screen mode my mouse input works but my keyboard does nothing. Windowed mode works fine as long as my ogre window has focus. What could cause this?

2) Windowed mode does not capture my mouse, but allows it to go in or out of the window. How can I capture it?

3) I have a move sideways button, 'a' and a right mouse drag will change my camera angle. If while pressing 'a', I right click and quickly move my mouse all the way to the side then down or up to the corner my key released event gets lost and effectively my key gets stuck. If I press the same key, I get a new event and can release, but my camera moves twice as fast in that direction because it is missing a release. Sounds like a bug in libgii, what do you think?

4) With libgii I get my xwindows cursor, whether in full screen mode or windowed mode. I'm also using CEGUI and injecting the coordinates from libgii. This works, but the cegui mouse curosr is so much slower and jumpier than the Xwindows cursor. It looks like I have cursor trails turned on (in windows). Why is cegui so slow in displaying a mouse pointer? Does it really suck that bad? I may just keep the Xwindows pointer, but how do I turn it off if I want to?

5) My mouse pointer has an absolute boundary of my screen size, whether in windowed mode or full screen mode. If I want to rotate all the way around with my camera, I can only go a full screen width before movement stops, even though I have more mouse pad to traverse. I have to release, move my mouse to the left and drag more. How can I reset libgii's mouse position? I have this in my init: giiarg.ptralwaysrel = false

Thanks!
User avatar
:wumpus:
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3067
Joined: Tue Feb 10, 2004 12:53 pm
Location: The Netherlands
x 1

Post by :wumpus: »

I don't know; I never looked for those things in libGII as I preferred it like this for the particular app (no mouse capture, no fullscreen mode). I think you're better off asking this to the libGII people.

I never experienced the CEGUI slowness; when I had the mouse cursor enabled, it exactly tracked the system one. Probably you just have a low framerate?
User avatar
discipline
OGRE Community Helper
OGRE Community Helper
Posts: 766
Joined: Mon May 16, 2005 12:09 am

Re: libgii quirks and questions

Post by discipline »

Here are some of the conclusions that I got back:
discipline wrote:1) When in full screen mode my mouse input works but my keyboard does nothing. Windowed mode works fine as long as my ogre window has focus. What could cause this?
- They thought it had been fixed in input-x and input-xwin. It was asked if I could reproduce it with any libggi demo. They also said a lot of work had been done in CVS on this. Unfortunately no libggi demo would work in full screen as advertised in the man page, except in dga mode. In that case the keyboard did work, however it was libggi input, not libgii. I was not successful in binding libgii to libggi. Go figure, since they wrote both of them[1]. I spent many hours trying to get any full screen app bound to libgii, but ultimately failed each time because I couldn't get a Display* or a Window describing my current window from the graphics library I was using (GLX, glut, libggi).
2) Windowed mode does not capture my mouse, but allows it to go in or out of the window. How can I capture it?
input-xwin has CTRL+ALT+M bound into it. That will switch your mouse into relative mode and capture it. However no way to do it programmatically was given. Presumably one could view the source and try to find a function call. However they have wrapped their internal pointers pretty well.
3) I have a move sideways button, 'a' ... my key released event gets lost and effectively my key gets stuck...
Due to the above problems in #1 I was not able to produce a code sample to do this outside of using ogre's subsystems.
4) I may just keep the Xwindows pointer, but how do I turn it off if I want to?
The answer was that libgii does not change the mouse pointer at all. However with the ctrl+alt+m key sequence given, the mouse pointer does in fact turn off. Again presumably one could view the source to try and get a hidden api call. A direct call to the windowing system is more likely.
5) My mouse pointer has an absolute boundary of my screen size, whether in windowed mode or full screen mode. If I want to rotate all the way around with my camera, I can only go a full screen width before movement stops, even though I have more mouse pad to traverse. I have to release, move my mouse to the left and drag more. How can I reset libgii's mouse position? I have this in my init: giiarg.ptralwaysrel = false
Ctrl+Alt+M, switches to relative mode, although it is only for input-x and input-xwin which are both under linux. When I set giiarg.ptralwaysrel=true; this did not make the switch, in fact it disabled all of my movement events and I only received button press events. Their response was, "This is strange. Shouldn't happen at all."


[1] I vented some of my frustration on a few poor souls who happened to be on the mailing list. Frustration over the hours I had spent, lack of complete documentation in the man pages, lack of tutorials or example code that works and frustration over the code not working as it should. I had setup my gii code through the Ogre wiki which suggested using the input-xwin driver. The man page says it is not a standalone driver and should not be used directly. Someone pointed this out to me, suggesting input-x which is meant to be used directly. They also suggested , "If you do stuff explicitly not supported by the man-page, what do you expect? A smooth ride?"

Intrepret this as you will. This was my experience working with version 0.9.1.
User avatar
discipline
OGRE Community Helper
OGRE Community Helper
Posts: 766
Joined: Mon May 16, 2005 12:09 am

Post by discipline »

:wumpus: wrote:I never experienced the CEGUI slowness; when I had the mouse cursor enabled, it exactly tracked the system one. Probably you just have a low framerate?
With libgii, if I run at 1280x1024 there is a noticable trail between my XWindows cursor and my cegui cursor. This occurs at 25, 40 or 60 frames per second. I see it when moving from corner to corner, or moving around in circles without much effort. At 800x600 there is no problem, but then I run at 70-100 frames per second.

With ogre's input I can't see the X cursor, however I can see that the cegui cursor jumps from one place to another when I move it. It is far from smooth during the transition.

Do I really need to run at 100 frames per second just for cegui's pointer to feel smooth? Time to upgrade my video card, my mouse is too slow!
User avatar
discipline
OGRE Community Helper
OGRE Community Helper
Posts: 766
Joined: Mon May 16, 2005 12:09 am

Post by discipline »

Finally just to complete my report, I did try the input-x driver instead of input-xwin.

With ogre's input my mouse pointer will jump. The mouse callback will get a relative movement of a couple hundred pixels. Often it would be every X pixels when moving to the side, where X is my window width. With libgii in relative mode, I also got this, but it was worse. Sometimes the mouse callback would stop receiving events from horizontal or vertical movement. It would feel like the cursor hit an invisible wall for a split second before moving.

When I tried input-x, relative motion worked perfectly. Very smooth, no input problems. However input-x opens up a new window which is always_on_top above the ogre window. It is placed from the top left of the screen to the middle point. This is hard coded in the input-x driver with no option to turn this off or shrink it down, at least in this version. :evil: