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
hardwar
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
On Sat, Feb 22, 2014 at 11:22 PM, Florian Bösch wrote:
> Caveat, I think Firefoxes implementaiton of the Pointerlock API might not
> follow the specification yet to make it possible to have pointerlock
> without fullscreen.
>
Just checked this against a test I wrote a while ago
http://codeflow.o
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
Overall this seems like a great direction. The most important use case
for me is using custom elements to implement new form controls.
Having custom elements included in form#elements seems pretty
essential. Most existing form serializers basically use form#elements,
input#name and input#.value. S
[ Bcc public-html ]
Bruno - please use public-webapps@w3.org for discussions about the
Screen Orientation API.
Original Message
Subject:Screen Orientation API Spec phrasing confusion
Resent-Date:Sat, 22 Feb 2014 03:33:28 +
Resent-From:
Date: Fri, 21 Feb
