I’d suggest having a simple bit flag (int, bool, whatever)
RepositionedCursor = 1
if (RepositionedCursor != 1)
/* Handle Movement*\
when you are done processing events, you can set RepositionedCursor to 0 or false. That way you don’t get the glitch, and it’s just one extra variable to track.
David Bruce wrote:> Hi,
On Thu, Dec 30, 2010 at 5:00 PM, Justin Coleman wrote:
You’ll need to set the mouse position to the center of the screen
every time you go through your main loop, that way you’ll continue to
receive motion events (as it will never hit the edge of the screen).
Well, looking through the docs, I found the following.
“If the cursor is hidden (SDL_ShowCursor(0)) and the input is grabbed
(SDL_WM_GrabInput(SDL_GRAB_ON)), then the mouse will give relative
motion events even when the cursor reaches the edge of the screen.
This is currently only implemented on Windows and Linux/Unix-alikes.”
So I guess I’m OK except for OS-X, in which case I can reposition the
mouse as you recommend. I take it that means using SDL_WarpMouse()?
The only problem seems to be that the repositioning itself generates a
mouse motion event every frame, which is making the control behave a
little erratically. Is there a clean, reliable way to ignore the
events generated by SDL_WarpMouse() without risking losing other
events? Alternatively, I could only do the reset-to-center when the
cursor hits the edge of the screen, rather than every frame, which at
most should cause an infrequent “hiccup”.
SDL mailing list
SDL at lists.libsdl.org