Re: [fullscreen] Problems with mouse-edge scrolling and games

Pointerlock should solve these problems in the following fashion:

   - When the user clicks into the app, request pointerlock
   - Use it to give him a cursor drawn by you
   - That way you can keep the interaction inside your game and accurately
   detect borders etc.

I run http://webglstats.com/ and It also records the availability of
pointerlock. This is relative to everybody who has webgl and it currently
stands at 94.1%.

Caveat, I think Firefoxes implementaiton of the Pointerlock API might not
follow the specification yet to make it possible to have pointerlock
without fullscreen. I know that it's possible to get pointerlock in google
chrome without fullscreen.

Links:

   - http://www.html5rocks.com/en/tutorials/pointerlock/intro/
   - http://www.w3.org/TR/pointerlock/




On Sat, Feb 22, 2014 at 2:00 AM, Ian Langworth <ian@artillery.com> wrote:

> Hi everyone,
>
> We're building a console- and native-quality game in the browser using
> JavaScript and WebGL. You can see a very early version of the game in this
> video: https://youtu.be/NiCy5igO9-I . It's a realtime strategy (RTS)
> game, like StarCraft[1] or Command & Conquer[2], and moving the cursor to
> the edge of the screen is the primary way that users move around the map.
>
> We have a single requirement: Moving the cursor to, and possibly past, the
> edge of the window or screen should pan the camera in that direction.
>
> In windowed mode there are a couple of problems: Players might click
> outside the window accidentally, pixels outside the window are wasted
> screen real estate, mousemove events aren't fired when the cursor is
> outside the window, and sometimes the cursor moves so quickly that it
> misses the area of the window where we do edge detection.
>
> The better option is to go fullscreen with the Fullscreen API, but this
> has problems as well. There are certain behaviors that occur when moving
> the cursor to the top and bottom of the screen, which I've illustrated in
> the following videos using a quick edge-scrolling demo[3].. (Please ignore
> the problems with cursor detection in the Windows videos. It only occurred
> while the screen recording software was active.):
>
>    Chrome, Windows 7
>    https://www.dropbox.com/s/t9kyo8s5am76ezg/chrome%20win7%20edges.avi
>    The fullscreen notice appears every time the cursor is moved to the top.
>
>    Chrome, Mac OS X
>    https://www.dropbox.com/s/ke1mr5te2dwgvor/chrome%20osx%20edges.mov
>    A poor experience with the menu and address bars appearing at the top
> and Dock appearing at the bottom.
>
>    Firefox, Windows 7
>    https://www.dropbox.com/s/iku8croaphsgcwd/firefox%20win7%20edges.avi<https://www.dropbox.com/s/iku8croaphsgcwd/firefox%20win7%20edges..avi>
>    No problems with the fullscreen experience!
>
>    Firefox, Mac OS X
>    https://www.dropbox.com/s/0bkdx71ir0yhw88/firefox%20osx%20edges.mov
>    Menu bar appears at top, along with some mysterious window chrome, and
> the Dock appears at the bottom as well.
>
> These behaviors are to remind the user about fullscreen and lessen the
> chance of phishing. But, as you might imagine, they are troublesome when
> you're in the heat of battle and are trying to crush your opponent. I would
> like to solicit the list for opinions on how we can improve the fullscreen
> UI for games and give players the best experience possible. Some options
> that come to mind:
>
>   (A) Provide an alternate fullscreen API or option which provides a more
> complete experience, but with more dire warnings to the user. For example,
> pass in a flag to requestFullscreen() which gives the page full control
> over the screen (no fullscreen reminder notifications, menu bars, or Docks)
> and even the keyboard (so games can use the Escape key), but entering this
> mode presents a much more intense warning to the user like the invalid
> certificate warnings.
>
>   (B) Maintain the current API, but put an option in the preferences or
> flags which makes the browser's fullscreen mode more complete and without
> interruption. Hardcore gamers will likely accept this extra step if it
> means getting an optimal experience.
>
>   (C) Propose a new Mouse-Edge Detection API, which might solve these
> problems and provide games with better cursor detection overall.
>
> I appreciate any and all feedback.
>
> [1] http://youtu.be/Qb0VzbxdP4U?t=10m14s
>
> [2] http://youtu.be/l41hG-fVDN4?t=3m34s
>
> [3] http://jsfiddle.net/statico/F8sjw/show/
>
>