Exactly. Having an “exit from fullscreen” bar or some OS auto-hide elements
like docks and task bars popping up at the edges when you play an intense
twitch game is simply horrendous. We have several playtests feedbacks arguing
in that direction.
Not to mention that a lot of our alpha players
@Florian:
That is very well put.
Trust me, we are well aware of time budgets and GC pauses. The thing is that
even when planning frame budgets and object allocations ahead, you still have
external parameters you cannot really control (ie. Another tab running flash or
some other intensive task,
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
wrote:
> I've written a test for this here:
>> http://codeflow.
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),
- Inabi
>
> 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. Mi
