In Windows, using lwjgl in windowed mode, with the mouse grabbed property set, if you click a windows title bar, the window goes flying downward off the screen. This is presumably because lwjgl is trying to grab the mouse back down inside the window, but ends up pulling the window downward.
Is there a way to prevent this behavior? If not, a possible solution would just be to check that no mouse buttons are pressed before it pulls the mouse back to prevent the slingshot effect.
The mouse is not supposed to be visible when it's grabbed though???
Cas :)
Indeed, you have to alt-tab out of the application for it to become visible. Then when you click the title bar to refocus on the app, is when this problem occurs.
This is a very serious problem. I have found an easy way for people to reproduce it so that you can see why.
Open the lwjgl input MouseTest demo.
Next, press the Windows key, or Alt-Tab. You will regain control of your mouse and see your cursor once the application has lost focus.
Now, click the title bar of the application. If you click it fast enough, you may be able to save it before it goes all the way off the screen, but you won't be able to move it back. If you try, and prepare to see it fly away to where you will not be able to get it back ever.
Note: I doubt this will work on any operating system except for Windows. I personally believe after messing with the source code that this is a problem inside the DirectInput implementation, but I am really stumbling around because I am so unfamiliar with the lwjgl internals. A little bit of help from any lwjgl developer, or even a user with better knowledge of the lwjgl internals, would be greatly appreciated.
I'll keep investigating, but right now this is the single most serious bug in my game because the users run into it all the time, and it's very aggravating because they have to exit to recenter the window.
********* UPDATE **********
I have figured out why such a critical bug has been able to remain in lwjgl for so long. On a Windows XP box (or lower I presume), the window only drops itself down about 10 pixels. However, you will find that even on XP you cannot move the window back up, and if you click it enough times it will eventually go off the screen. Still, this behavior is much less serious than on the newer Vista, where you will lose the application permanently by clicking the title bar even once.
This bug should now be fixed in HEAD.
- elias
I can confirm that the new HEAD works perfectly correct now, even on Vista. Great job guys!
New release out soon with keyboard & mouse glitches fixed...?
Cas :)
soon, still issues to fix before new release
Sort of related... :)
I've locally updated jME to use lwjgl 1.1.1 and I'm now seeing a few issues with the mouse. When the mouse is grabbed and I am in windowed mode, if I alt tab out, the mouse still provides input to the window, even though it is not in focus. By this, I mean that if I move my mouse across the screen and happen to pass over the lwjgl window, mouse events are generated. It also hides my mouse cursor as I pass across the window.
Even odder, let's say I am running eclipse full screen and I launch a windowed lwjgl app. It appears centered over the top of eclipse. I then alt-tab back to eclipse and my mouse appears as expected in the middle of the window, but now it will only move within the boundaries of the GL window that is under the eclipse window. FWIW, through some experimentation I have discovered I can "unstick" it if the edge of the gl window is showing on screen and I exit over that side.
Any ideas?
I can also confirm I've seen this exact same thing happen before many times in 1.1.1.
When this starts happening, I just keep hitting the windows key and alt tab and eventually it seems to release the focus, but definitely something worth checking into in the code.
Another possibly related problem is that sometimes when coming back into the window (after alt tabbing), the position of the cursor internally in the window will be off. I've had users report (and it happens to me occasionally) that their crosshairs are off. The solution is dragging the mouse into a corner of the application seems to realign it.
The cursor should now unstick when alt-tabbing out from an LWJGL window.
The cursor position problem is puzzling. Are you using Mouse.get(Event)X/Y() to fetch cursor positions?
- elias
This is using Mouse.getX/Y to draw the cursors position, and then using the X/Y provided by the generated event for the actual clicking events. I'm not sure which one is the inaccurate one, but they seem to not be in agreement on occasion
If you're getting the cursor position while having the cursor grabbed, should should stick to either getX/Y() or getEventX/Y(), but not both. It is generally difficult to guarantee that they always return the same value. If you're not grabbing the cursor, this is probably a bug and I'll need a series of steps to reproduce the bug (you could modify one of the input tests in LWJGL to provide a simple example).
- elias
Understood, I am now getting all of my values from GetX/Y, even for handling mouse clicks.
Thanks elias... jME 1.0rc is due out shortly and I'd like to use an official release of lwjgl... Any idea when 1.1.2 could be out (so I could include this fix?)
This isn't totally related, but I have Linux users reporting that clicking the left and right buttons at the same time causes a middle click event.
In the game this takes place in, primary weapon is fired with left click, and special weapon is fired with right click. Thus you can perform a combo shot by clicking both at the same time, which ends up triggering this problem (but only on Linux).
Not sure what to do about it, except disabling the Emulate3Buttons option in xorg.conf.
- elias
Ahh thank you sir, the users said that did the trick perfectly.