We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 432 - warpmouse enhancement.
Summary: warpmouse enhancement.
Status: RESOLVED INVALID
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: HG 1.2
Hardware: All All
: P2 API change
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-04 17:07 UTC by Tristen Ennemuist
Modified: 2007-06-25 12:01 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tristen Ennemuist 2007-06-04 17:07:06 UTC 
I think it would be great if another mouse warp function could be written:

#include "SDL.h"

void SDL_WarpMouse(Uint16 x, Uint16 y, Uint16 generate_event);

or similar. The extra parameter would determine whether an mouse-motion event would be generated as a result of the warp.

Essentially, 3d games featuring "mouselook" (relative mouse-motion) should be able to move the mouse back to the origin without generating a mouse-motion event.
Comment 1 Ryan C. Gordon 2007-06-04 21:20:25 UTC 
Generally, you probably want to hide the mouse and just receive relative moviement deltas instead of warping the mouse. That way it doesn't matter where the real mouse cursor is.

--ryan.
Comment 2 Tristen Ennemuist 2007-06-07 23:18:53 UTC 
(In reply to comment #1)
> Generally, you probably want to hide the mouse and just receive relative
> moviement deltas instead of warping the mouse. That way it doesn't matter where
> the real mouse cursor is.
> 
> --ryan.
> 

G'day Ryan, 

Yeah, that's what I thought too, but in full-screen it stops returning relative movement when it hits the edge of the screen...

Like, say for example "mouselook" in Quake, if you can keep moving the mouse to the left, you keep spinning to the left - like forever if you had a desk big enough and an arm long enough ;) 

Currently, without moving the mouse back to the centre of the screen, the relative movement stops, like I say, when the mouse hits the edge of the screen.

So what I really want to do is (after hiding the mouse like you suggest):

- Capture the relative x & y for a mouse-motion event.
- Process the relative movement event.
- Reset the cursor back to the middle of the screen.
- Ignore the relative movement event.

It seems to me the most efficient way to not process the relative movement for the "Reset" movement is to skip generating the mouse motion event altogether...why generate an event that'll simply be completely ignored?

I can (and will in the interim) work around this by setting a flag prior to the "reset" that would indicate that the next mouse motion event should be ignored.

Cheers
Tristen
Comment 3 Ryan C. Gordon 2007-06-08 14:02:48 UTC 
To be clear, if the mouse cursor is hidden and you're fullscreen, it shouldn't ever hit the edge of the window (it should continue to give relative motion events in a given direction forever). Is this not the case?

--ryan.
Comment 4 Tristen Ennemuist 2007-06-24 21:03:41 UTC 
Yes, you're absolutely correct: if the mouse cursor is __hidden__, then it doesn't stop reporting mouse-relative-motion events.

Sorry for the confusion, I did all my programming/testing with the mouse-cursor visible so I could visualise what was going on...

Many thanks for your help on this one!

(In reply to comment #3)
> To be clear, if the mouse cursor is hidden and you're fullscreen, it shouldn't
> ever hit the edge of the window (it should continue to give relative motion
> events in a given direction forever). Is this not the case?
> --ryan.
Comment 5 Ryan C. Gordon 2007-06-25 12:01:18 UTC 
Cool, glad it's working for you!

--ryan.