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

Pointer lock does indeed provide a workaround for this, but it's worth
noting that with the current architecture of Chrome a software cursor will
experience visible lag, which these types of games are highly sensitive to.
I'm not sure about the latency of Firefox or others, but in general a
hardware cursor is preferable any time you have a visible cursor. As a
result this is still a use case worth considering.

--Brandon

On Saturday, February 22, 2014, Florian Bösch <pyalot@gmail.com> wrote:

> 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<javascript:_e(%7B%7D,'cvml','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/
>>
>>
>