- From: Glenn Maynard <glenn@zewt.org>
- Date: Mon, 4 Jun 2012 09:34:16 -0500
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Pablo Garaizar Sagarminaga <garaizar@deusto.es>, www-dom@w3.org
Received on Monday, 4 June 2012 14:44:18 UTC
On Mon, Jun 4, 2012 at 2:23 AM, Jonas Sicking <jonas@sicking.cc> wrote: > #4 Accurate responses in games. For example in a rock-band style game, > the user attempts to hit the key exactly at a specific time. > I've worked on rhythm games, and we did indeed run input in a thread with high-resolution timestamps on the input; in ideal cases this gave us (empirically measured) input timing accuracy of under 1ms, which mattered a lot. > #5 Fluid behavior for animations. If an animation is started in > response to a user event, but the main thread happens to be busy when > the event should fire, the page can account for this and place > animated items where they would be as if the animation had started > exactly when the user event occurred. > Actually, for this one you don't want to do that. If you process the animation at 1.0s, and the user input happened at 0.0s (exaggerated), then the animation will visibly skip forward by one second. Usually it's much better to let the animation be a little delayed than to have it jump forward to catch up. (I hit this problem a lot when working on game animations: we always had to be sure to flush timers to make sure animations don't jump ahead in cases like this.) -- Glenn Maynard
Received on Monday, 4 June 2012 14:44:18 UTC