Thank you all. This is wonderfully helpful.
On Mon, Feb 24, 2014 at 10:07 AM, Vincent Scheib sch...@google.com wrote:
One way to move forward on those topics is to prototype functional
solutions on Windows, Mac, and Linux and illuminate a practical solution
that browsers may adopt. I did an
On Mon, Feb 24, 2014 at 1:16 AM, Thibaut Despoulain
thib...@artillery.comwrote:
I've written a test for this here:
http://codeflow.org/issues/software-cursor.html
My observation from testing on linux is that I can't distinguish latency
for the software cursor from the OS cursor (or not by
The issue with pointerlock is that it requires the app to draw its own
cursor instead of the OS cursor, which has at least two significant
drawbacks:
- Significant pointer lag between movement input and actual movement on
screen compared to an OS-drawn cursor (yes, even at 60fps),
-
I've written a test for this here:
http://codeflow.org/issues/software-cursor.html
My observation from testing on linux is that I can't distinguish latency
for the software cursor from the OS cursor (or not by much anyway) in
google chrome. In firefox however there's noticable lag. Mileage
Also: At the moment we're using CSS cursors to give visual feedback on
in-game hover/action states which works pretty well and is a breeze to
implement.
On Sun, Feb 23, 2014 at 4:16 PM, Thibaut Despoulain
thib...@artillery.comwrote:
I've written a test for this here:
On Mon, Feb 24, 2014 at 4:17 AM, Florian Bösch pya...@gmail.com wrote:
On Mon, Feb 24, 2014 at 1:16 AM, Thibaut Despoulain thib...@artillery.com
wrote:
I've written a test for this here:
http://codeflow.org/issues/software-cursor.html
My observation from testing on linux is that I can't
On Mon, Feb 24, 2014 at 5:18 PM, Glenn Maynard gl...@zewt.org wrote:
It's not the application's job to keep the mouse cursor responsive, it's
the system's. Hiding the system mouse cursor and drawing one manually is
always a bad idea.
That's a wonderful argument. And now we look at an FPS
(More reasons: it's very likely that you'll end up implementing a cursor
with different motion and acceleration, a different feel, than the real
mouse cursor. It also breaks accessibility features, like mouse trails.)
On Mon, Feb 24, 2014 at 10:30 AM, Florian Bösch pya...@gmail.com wrote:
On
On Mon, Feb 24, 2014 at 5:40 PM, Glenn Maynard gl...@zewt.org wrote:
(More reasons: it's very likely that you'll end up implementing a cursor
with different motion and acceleration, a different feel, than the real
mouse cursor. It also breaks accessibility features, like mouse trails.)
Oh I
Glenn Maynard wrote:
It's not the application's job to keep the mouse cursor responsive,
it's the system's. Hiding the system mouse cursor and drawing one
manually is always a bad idea.
Agreed!
In the same vein, programmers cannot avoid GC pauses without relying on
pause-free or at least
Thank you Ian for the clear use case write up (and to Artillery for
progress on a great product), Florian Brandon and Glenn for discussion
contributions.
As Florian mentioned, we did discuss this use case in 2011 and at that time
I attempted to summarize the situation in the pointer lock spec
...@artillery.com
Tweet: @BKcore
From: Brendan Eich Brendan Eich
Reply: Brendan Eich bren...@secure.meer.net
Date: February 24, 2014 at 9:47:24 AM
To: Glenn Maynard gl...@zewt.org
Subject: Re: [fullscreen] Problems with mouse-edge scrolling and games
Glenn Maynard wrote:
It's
On Mon, Feb 24, 2014 at 6:47 PM, Brendan Eich bren...@secure.meer.netwrote:
Glenn Maynard wrote:
It's not the application's job to keep the mouse cursor responsive, it's
the system's. Hiding the system mouse cursor and drawing one manually is
always a bad idea.
Agreed!
Like I say, some
On Mon, Feb 24, 2014 at 7:07 PM, Vincent Scheib sch...@google.com wrote:
Windows has ClipCursor() and Linux has XGrabPointer(). Once we know we can
implement the functionality, we can discuss how to express this in an API.
Would using Quarz CGWarpMouseCursorPosition work where you'd clamp the
On Mon, Feb 24, 2014 at 10:37 AM, Florian Bösch pya...@gmail.com wrote:
On Mon, Feb 24, 2014 at 7:07 PM, Vincent Scheib sch...@google.com wrote:
Windows has ClipCursor() and Linux has XGrabPointer(). Once we know we
can implement the functionality, we can discuss how to express this in an
Right, so you'd CGAssociateMouseAndCursorPosition(false) and then use
CGWarpMouseCursorPosition or CGDisplayMouseCursorToPoint to move it where
you want it to be, but clamped inside the rect. As long as you keep pumping
the event loop separately that does this (as fast as possible) it shouldn't
be
On Mon, Feb 24, 2014 at 12:19 PM, Florian Bösch pya...@gmail.com wrote:
Like I say, some usecases are fine with OS cursors. But that doesn't mean
that somehow, vendors are absolved from improving input - output latency
issues even if pointerlock is updated to allow OS cursor showing, which I'm
On Mon, Feb 24, 2014 at 8:21 PM, Glenn Maynard gl...@zewt.org wrote:
I think that going fullscreen is the right approach, since locking the
mouse into the window while not fullscreen is really weird and rare, at
least in Windows.
It's quite common for games to have a cursor, grab the pointer
: February 24, 2014 at 11:32:13 AM
To: Glenn Maynard gl...@zewt.org
Subject: Re: [fullscreen] Problems with mouse-edge scrolling and games
On Mon, Feb 24, 2014 at 8:21 PM, Glenn Maynard gl...@zewt.org wrote:
I think that going fullscreen is the right approach, since locking the mouse
On Sun, Feb 23, 2014 at 1:57 AM, Thibaut Despoulain thib...@artillery.com
wrote:
The issue with pointerlock is that it requires the app to draw its own
cursor instead of the OS cursor
I fully agree with motivation, it is usually preferrable to give the user
an OS-themed cursor (not always,
On Sun, Feb 23, 2014 at 9:55 AM, Florian Bösch pya...@gmail.com wrote:
- Inability to use DOM elements with mouse events for a game
overlay/HUD.
The test I've written here
http://codeflow.org/issues/software-cursor.html also tests mouse event
synthesis (as hinted at by an example in
Several points to add:
- it's possible to theme the OS cursor using custom images with CSS.
https://developer.mozilla.org/en-US/docs/Web/CSS/cursor/url
- The reason the cursor is hidden when the pointer is locked is that some
OSes don't have the ability to report relative mouse movement correctly
On Sun, Feb 23, 2014 at 4:18 PM, Brandon Jones bajo...@google.com wrote:
- it's possible to theme the OS cursor using custom images with CSS.
https://developer.mozilla.org/en-US/docs/Web/CSS/cursor/url
Although that doesn't absolve vendors from fixing the latency issue even if
native pointers
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
On Sat, Feb 22, 2014 at 11:22 PM, Florian Bösch pya...@gmail.com 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
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
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
27 matches
Mail list logo
