On Thu, 2003-01-09 at 00:03, SirVer@... wrote:
> On Wed, Jan 08, 2003 at 11:40:44PM +0100, Willem Jan Palenstijn wrote:
> > Hi,
> > I'm getting very erratic mouse movement when my computer is under load,
> > so I've been looking at Widelands' mouse handling code a bit.
> > say you move the mouse 2 pixels to the left, and you get two mouse
> > motion events (each for one pixel). The first one will be at
> > (centerx-1,centery). So, widelands moves the mouse one pixel left, and
> > warps the mouse back to (centerx, centery). Now, two things can happen.
> > Either the second mouse motion event arrives first, or the mouse motion
> > caused by the warp arrives first. In the first case, it gets a
> > (centerx-2,centery) event, which means widelands moves the mouse two
> > more pixels to the left. This means the mouse has moved three pixels in
> > total, instead of two.
> i see the problem. but i can't see a solution. the problem is: when
> draging the map, the user can move the mouse in every direction as far
> as he wants to, but the in-game cursor should not move from the current
> position (relative to the screen). when we use the SDL-Functions
> (without warping), scrolling would stop as soon as the SDL Cursor would
> touch the screen edges (or the window edges). but from then on, they do
> not deliver even relative movements. i hope this is understandable, i'm
> not sure if i expressed it properly.
> The SDL functions simply have a drawback there.
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-a-likes.
As far as I can tell this means that even though the absolute mouse
coordinates might stay at the window edge, the relative motion
(SDL_MouseMotionEvent::xrel, SDL_MouseMotionEvent::yrel) would still
work. (patch attached as illustration, sdlrel.patch)
If this turns out not to work, something I can think of is storing the
last mouse position. When you get a mouse motion event, you take the
motion relative to this last position, and update it after moving the
When you then get the (centerx,centery) warp event, you reset the last
position to (centerx,centery).
The only slight problem with this is that when you coincidentally manage
to move the mouse back to (centerx,centery) yourself, you'll lose the
last bit of motion. The changes of this happening are pretty small,
though. (patch attached as illustration, mousemotion.patch)
Anyway, as I mentioned earlier I have no idea how both patches behave
with the capture/playback code, as I haven't looked at that. Both
patches do work with scrolling the viewscreen very far in any direction.
(I prefer the sdlrel one, though, since it's cleaner.)