On Mon, Jun 4, 2012 at 2:23 AM, Jonas Sicking
<jonas@...> 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
