Hello! I am using OpenGL picking to pick an object and move it around on the screen. This works fine, but there is a slight delay between my mouse cursor and the object position; that is, the object is always lagging behind the cursor.
I am doing this on Windows XP, with straight forward handling of WM_MOUSEMOVE, which sets new object position.
Can any of you game developers out there provide some tips/pointers on how to have absolutely responsive mouse handling?
Thanks in advance.
Is the picking itself fast enough? When you pick something, just render it differently the next frame to see you get “immediate” result. Perhaps just use audio feedback for even less delay.
Assuming picking is instant, is there any other source of delay than rendering?
Add timing measurements in your code - if the delay is so large to display lag between mouse and what’s rendered, the delays should stand out quite clearly. (note: if emitting the results using OutputDebugString, that call can intermittently introduce very noticable overhead/delay itself!)
Use audio feedback (Beep() is enough). Use short beeps of different frequency for different events.
the main problem with the mouselag when you are drawig the pointer yourself is, that you get the mouseposition before you start your rendering.
so when framerate is lower than the screenfreqency (means, you need more than one frame for rendering) you are using a mouseposition which isn’t valid anymore.
my solution to this problem in my games, is to read the current mouse position just before drawing the mousepointer, and to draw this pointer as late as possible before calling glSwapBuffers (ideally the very last call)
this way you have the most recent mouseposition, when you start rendering. (it is also recomended, to store this position for picking/intersection tests, to be sure you test really at the position where your pointer currently is.)
how to get the current mouseposition:
don’t use WM_MOUSEMOVE (it has some other issues anyway, ie.: you don’t get noticed when the mouse is outside the current clientarea of the window)
use GetCursorPos instead:
the only thing you have to take care of, is that you get this position in screencoordinates. when you want window relative coordinates, you need to convert the position using ScreenToClient
 (the same link twice)
Thanks for both replies!
GetCursorPos “was” the answer I was looking for. Funny how MSDN document doesn’t list this under the “mouse” section but under “Resources” section.
Anyways, my specific problem turns out to be that my rendering process is taking too long. So, tamlin’s answer was a good one too!
So, to summarize for other readers, if you see a lag between your mouse and your UI element:
- Use GetCursorPos in your algorithm.
- If you are using WM_MOUSEMOVE, check how long it takes between your WM_MOUSEMOVE and your swap buffer. (This should be short)
Particularly, I noticed that my code actually works fine on hyper-threading machine, which leads me to believe that there are unnecessary synchronization code in my rendering routine that I need to take out. (I still just left these in there although I know really shoudn’t. :rolleyes: )