Hi guys,
I have a problem to implement a picking system in my project based on Java and OpenGL (LWJGL). If I move the mouse slowly, it's perfect. If I move the mouse fastly the x and y coordinates are disaligned: at the same point (in the screen) I have different x and y values. Can anyone help me?
Thanks at all.
The absolute coordinates in Mouse are not necessarily the same as the position the hardware cursor is displayed at as Windows can apply acceleration and other magic to its location. LWJGL just deals with raw mouse input.
Cas :)
Why is that? When the cursor is visible, we use coordinates returned from GetCursorPos, which should be pretty accurate.
- elias
hm, not any more.... I was fiddlin' with all that in CVS. Maybe it was broken? The 0.9 released definitely didn't work properly.
Cas :)
It runs great here. Make sure you don't poll getD*() twice though, as the delta values are reset. If it really doesn't work, it's a bug. A visible cursor is useless if you can't trust the positions.
- elias
Thought I might chime in here as I've seen some strange behavior in 0.9 regarding mouse positions. I have a test pattern app that both sets the native cursor and renders a software cursor at the position returned by Mouse.getX() and Mouse.getY(). For the most part, it works very well, and the hardware cursor is rendered directly on top of the software cursor.
However, I have many times experienced the following:
On start up the mouse is initialized to the center of the window. Both cursors look fine at this point. Then, when moving the mouse for the very first time, the software rendered cursor suddenly jumps to the lower right corner of the screen. It then remains off by half a screen width by half a screen width until I move the mouse into the lower right corner of the screen. When doing this, the software rendered cursor remains in the corner while I move the hardware cursor to it. Once they overlap, they remain in synch with each other for the rest of the duration of execution.
This may only add a bit more mud to the waters, but I figured I'd share as long as we were discussing it. Oh, and PS - I've only noticed this happen when running in windowed mode, though it happens in both Windows and Linux.
Paul
Could you post this test program?
- elias
Or try org.lwjgl.test.input.HWCursorTest. It works fine here at least.
- elias
I've recently added Mouse support to my project and noticed similar incorrect behavior from the getX() and getY() functions. I'm using the .9 code.
Mouse.poll();
while(Mouse.next()) {
int btn = Mouse.getEventButton();
if(btn == 1) {
if(Mouse.getEventButtonState()){
mousePos.x = (float)Mouse.getX();
mousePos.y = (float)Mouse.getY();
System.out.println("Mouse: " + mousePos.x + ", " + mousePos.y);
// set the target location for moving to
}
}
}
The printed mousePos is definately off. At first I thought it was reporting full screen coordinates (I'm running in a window)... but that wasn't it. Moving the mouse slowly does seem to improve performance but I can still get some discrepancy. When moving quickly, the delta appears to be less than the actual movement.
What Mouse reports is nothing to do with where the hardware cursor actually is. Mouse reports cumulative device data. It doesn't report where the hardware cursor is at all.
I think we should add a getX()/getY() to Cursor which would remove the ambiguity.
Cas :)
I guess I'll ask elias's question again - what's the point of getX,getY if it doesn't reflect the visible cursor's position? And is the "fix" to grab the cursor and implement my own using the delta's?
getX()/getY() should reflect the actual position, whether they're moved to Cursor or not.
- elias
The trouble is then if the user implements their own tracking with getDX() and getDY() that won't reflect the position. Which is why I think we should separate the concept of the mouse's supposed absolute coordinates based directly on input data and where the system has put the hardware cursor.
Cas :)
I still don't understand. If the mouse is not grabbed, getDX()/getDY() do reflect the hardware cursor postion with respect to the center of the display.
- elias
I've fixed a few things that could affect this problem. Could you please retest? The attached zip contains the dll, so and jar files (new Display API):
http://odense.kollegienet.dk/~naur/lwjgl-20040715.zip
thanks,
- elias
After some quick and dirty refactoring to the new merged Display/Window (is nice BTW) ... at a glance the cursor appears to be working. I'll clean up the Display stuff and check it more thoroughly tomorrow. Thanks for the assist. :P