Re: Mouse Lock

You actually can get mouse delta info in windows using raw WM_INPUT data
see: http://msdn.microsoft.com/en-us/library/ee418864(VS.85).aspx. This is
also the only way to take advantage of > 400dpi mice, which is useful for
FPS games.

As for mouse locking isn't that a completely distinct feature from getting
mouse delta information? For example in full-screen mode (and only using one
screen) there is no need for mouse lock when you always can get mouse delta
(because the mouse can't leave the screen).

The only problem that remains is when in multi-screen and/or
non-full-screen-mode, the mouse cursor can go outside the "game viewport".
This is something that could be solved by mouse lock. But wouldn't it be
better (as previously suggested in this thread) to implement "walling of the
mouse cursor" by limiting the mouse cursor to the bounds of a targeted
element. This is both useful for FPS-type games and RTS's. FPS's can hide
the mouse cursor using CSS and don't have to worry about mouse events being
fired outside the element or window. RTS-games just could use the available
mouse cursor without needing to hide it (they wouldn't even need the mouse
delta that way).

It appears to me that mouse lock is just a workaround/hack that originated
from the assumption that you can't get mouse delta info in Windows. Isn't it
always better to first make an ideal design before looking at platform
limitations that possibly could undermine that design?

So to summarize all the above, design to separate features: 1. an event for
getting mouse delta 2. an API for walling the mouse to an element.

Klaas Heidstra

> A few comments:
>
> Is there a need to provide mouse-locking on a per-element basis? It seems
to
> me it would be enough for mouse-locking to be per-DOM-window (or
> per-DOM-document) and deliver events to the focused element. This
simplifies
> the model a little bit by not having to define new state for the
> "mouse-locked element". Or is there a need for mouse-lock motion events to
> go to one element while keyboard input goes elsewhere?
>
> As was suggested earlier in this thread, I think given we're not
displaying
> the normal mouse cursor and in fact warping the system mouse cursor to the
> center of the screen in some implementations, we shouldn't deliver normal
> mouse-move events. Instead, while mouselock is active, we should deliver a
> new kind of mouse motion event, which carries the delta properties. If you
> do that, then hopefully you don't need a failure or success callback. Your
> app should just be able to handle both kinds of mouse motion events.
>
> I'm not really sure how touch events fit into this. Unlike mouse events,
> touch events always correspond to a position on the screen, so the delta
> information isn't as useful. (Or do some platforms detect touches outside
> the screen?) Maybe the only thing you need to do for touch events is to
> capture them to the focused element.
>
> In many of your use cases, it's OK to automatically release the mouse-lock
> on mouse-up. If you automatically release on mouse-up, the security issues
> are far less serious. So I think it would be a good idea to allow
> applications to accept that behavior via the API.
>
> A lot of this would be much simpler if we could somehow get mouse delta
> information from all platforms (Windows!) without having to warp the
cursor
> :-(. Has research definitively ruled out achieving that by any combination
> of hacks?
>
> Rob
> --
> "If we claim to be without sin, we deceive ourselves and the truth is not
in
> us. If we confess our sins, he is faithful and just and will forgive us
our
> sins and purify us from all unrighteousness. If we claim we have not
sinned,
> we make him out to be a liar and his word is not in us." [1 John 1:8-10]