I’m considering removing SDL_WarpMouse() from the API, as it was mainly
there for applications that needed continuous relative mouse motion, and
there are much improved semantics for this now.
Is anybody using it?
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
I’m considering removing SDL_WarpMouse() from the API, as it was mainly
there for applications that needed continuous relative mouse motion, and
there are much improved semantics for this now.
Is anybody using it?
I am using it to align the mouse with a small psuedo-cursor I create. (I
use SDL_ShowCursor() to turn the system cursor off.) I use the mouse
coordinates to figure out where to move the psuedo-cursor. Is there
another way I should be doing this without SDL_WarpMouse()? (Like
actually changing the cursor itself?)
Paul Braman @Paul_BramanOn Sat, 22 Jan 2000, Sam Lantinga wrote:
I’m considering removing SDL_WarpMouse() from the API, as it was mainly
there for applications that needed continuous relative mouse motion, and
there are much improved semantics for this now.
Is anybody using it?
I am using it to align the mouse with a small psuedo-cursor I create. (I
use SDL_ShowCursor() to turn the system cursor off.) I use the mouse
coordinates to figure out where to move the psuedo-cursor. Is there
another way I should be doing this without SDL_WarpMouse()? (Like
actually changing the cursor itself?)
I’m confused. Why would you warp the mouse instead of just responding
to mouse motion events (which you still receive if the cursor is hidden)?
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software> On Sat, 22 Jan 2000, Sam Lantinga wrote:
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
I’m confused. Why would you warp the mouse instead of just responding
to mouse motion events (which you still receive if the cursor is hidden)?
I am using absolute coordinates for the mouse in the window instead of
using relative motion. Just seemed easier to figure out where the mouse
was pointed by looking at where the mouse was pointed instead of figuring
out how far it had moved from where it was last. [shrug]
In a windowed application, if I need to align a picture with the mouse on
startup I just place the picture in the middle of the window and move the
mouse to that position. From then on, all movement inside the window
produces the coordinates where my picture should be.
Now, I could use relative motion (mouse moved 6 pixels to the left, for
instance) but I face a problem of aligning the picture in the first place
(especially when the mouse moves in and out of the window). (I suppose I
can just look at the absolute coordinates of the first mouse event and
relative coordinates from then on.)
If SDL_WarpMouse() isn’t going to be there, I’ll just have to change my
application. Simple as that.
Paul Braman @Paul_BramanOn Sat, 22 Jan 2000, Sam Lantinga wrote:
I am using absolute coordinates for the mouse in the window instead of
using relative motion. Just seemed easier to figure out where the mouse
was pointed by looking at where the mouse was pointed instead of figuring
out how far it had moved from where it was last. [shrug]
In a windowed application, if I need to align a picture with the mouse on
startup I just place the picture in the middle of the window and move the
mouse to that position. From then on, all movement inside the window
produces the coordinates where my picture should be.
Now, I could use relative motion (mouse moved 6 pixels to the left, for
instance) but I face a problem of aligning the picture in the first place
(especially when the mouse moves in and out of the window). (I suppose I
can just look at the absolute coordinates of the first mouse event and
relative coordinates from then on.)
If SDL_WarpMouse() isn’t going to be there, I’ll just have to change my
application. Simple as that.
Ahh, I understand.
As of SDL 1.0.2, the mouse coordinates should be valid immediately after
calling SDL_SetVideoMode(), so you should just be able to use
SDL_GetMouseState() and track the motion using absolute coordinates afterwards.
As of SDL 1.0.2, the mouse coordinates should be valid immediately
after calling SDL_SetVideoMode(), so you should just be able to use
SDL_GetMouseState() and track the motion using absolute coordinates
afterwards.
Please let me know if that doesn’t work.
Well, I suppose it works the way it is intended, but it doesn’t tell me if
the mouse is outside the window or not. Since the coordinates for the
mouse are always 0 <= x <= (width - 1) and 0 <= y <= (height - 1), and
since SDL_GetMouseState() returns 0,0 when the mouse is outside the
window (when the program starts), you can see my dilemma. Maybe it’s just
not possible to tell when the mouse is inside the window. [shrug]
Paul Braman @Paul_BramanOn Sat, 22 Jan 2000, Sam Lantinga wrote:
As of SDL 1.0.2, the mouse coordinates should be valid immediately
after calling SDL_SetVideoMode(), so you should just be able to use
SDL_GetMouseState() and track the motion using absolute coordinates
afterwards.
Please let me know if that doesn’t work.
Well, I suppose it works the way it is intended, but it doesn’t tell me if
the mouse is outside the window or not. Since the coordinates for the
mouse are always 0 <= x <= (width - 1) and 0 <= y <= (height - 1), and
since SDL_GetMouseState() returns 0,0 when the mouse is outside the
window (when the program starts), you can see my dilemma. Maybe it’s just
not possible to tell when the mouse is inside the window. [shrug]
Ahh, what you want is SDL_GetAppState(), and check the returned value
for the SDL_APPMOUSEFOCUS flag.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software> On Sat, 22 Jan 2000, Sam Lantinga wrote:
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
I’m considering removing SDL_WarpMouse() from the API, as it was mainly
there for applications that needed continuous relative mouse motion, and
there are much improved semantics for this now.
Is anybody using it?
I’m using it on Voodoo Hardware running fullscreen OpenGL to avoid that
the window loses focus and the user gets stuck with a fullscreen window
he can’t access anymore.
I’m considering removing SDL_WarpMouse() from the API, as it was mainly
there for applications that needed continuous relative mouse motion, and
there are much improved semantics for this now.
Is anybody using it?
I just subscribe to this mailing list EXACTLY for this feature !
SDL_WarpMouse() is the only way I found to keep the mouse focus. But I
have the feeling that is not a good solution because each time you use
it you have to ignore the event it create. See the sample code I use
(from the d2x project) :
void mouse_motion_handler(SDL_MouseMotionEvent *mme)
{
// Ignore the event create by SDL_WarpMouse()
if ((mme->x == 320) && (mme->y == 200)) {
return;
}
I’m considering removing SDL_WarpMouse() from the API, as it was mainly
there for applications that needed continuous relative mouse motion, and
there are much improved semantics for this now.
Is anybody using it?
I just subscribe to this mailing list EXACTLY for this feature !
SDL_WarpMouse() is the only way I found to keep the mouse focus.
Try the new API call: SDL_WM_GrabInput()
It does exactly what you want to do. If, in addition, you also specify
SDL_ShowCursor(0), then in the new SDL 1.0.3 code, the warping will be
done internally, so you always get relative mouse motion.
I’m considering removing SDL_WarpMouse() from the API,
as it was mainly there for applications that needed continuous
relative mouse motion, and there are much improved
semantics for this now.
Is anybody using it?
I am using it when dragging my dialog windows around. I don’t allow any
portion of a dialog to go off screen, so I fix a point on the dialog when
the mouse is pressed, move the dialog around, and warp the mouse if part of
the dialog goes off screen. The result is that the dialog appears to "clunk"
into the side of the window and the mouse stays at the original fixed point
relative to the dialog.