The best example I can think of is Doom 3. It seemed to me that if there was any kind if lag the game would pause and then resume without "fast forwarding" to catch up. I'm trying to figure out a good practice to use for lag detection in JavaScript.

  • 2
    \$\begingroup\$ Do you have a video showing this in action or can you be a bit more descriptive? It sounds to me like you're saying that when the framerate dropped, the framerate dropped. \$\endgroup\$ Dec 6, 2012 at 6:12
  • \$\begingroup\$ Well maybe we should forget that I mentioned Doom 3. I'll have to look into that later. What about just a plain and simple method for lag detection and compensation? \$\endgroup\$
    – Matt
    Dec 6, 2012 at 6:26
  • \$\begingroup\$ This article might get you started on determining latency in JavaScript. Unfortunately, JS isn't really compatible with 'plain and simple' for these measurements. \$\endgroup\$ Dec 6, 2012 at 13:37
  • \$\begingroup\$ @Marcks Thomas : Interesting article, yet the article is about network latency, and the question is about system lag. \$\endgroup\$ Feb 4, 2013 at 21:56
  • \$\begingroup\$ @VincentPiel: Well, 'system lag' is a rather vague term, but I took it Matt did not refer to for instance input latency on a USB mouse, which software can't really measure to begin with and its value has very little significance in game development anyway. \$\endgroup\$ Feb 4, 2013 at 22:38

1 Answer 1


First Rq : A key rule in Javascript : avoid system lag, with a very simple principle : do not feed the garbage collector.
So : Reuse your Arrays, do not create closures, use integers and not strings, pool your objects, ... a lot of simple rules too long to explain in a few words.

Now that you've done that, to avoid a slow-down/ fast forward behaviour, you have to to handle the time and timers by yourself. And drop a frame or more if you have to.

Rq : A secondary benefit of handling your game time/timers is that it will allow to nicely pause the game, and even to go faster or bullet-time if you want.

So how to handle your game time ?
Inside your run() loop you should measure the time between two calls (delta), and add up that 'real' time to your game time... Unless (and that's the trick) too much time elapsed (there was a pause or a system lag) : in that case you consider that just one frame elapsed.
Scale that time delta to allow bullet time / fast speed.

And for the game timers either :
a) you implement your own game timers (gameSetTimeout/gameSetInterval) (somehow complex)
b) you only check your entities against the game time for time-related actions.
expl, for a human that turns into a zombie after a given time :

if (this.isDead && (gameTime - this.DeathTime > ZombieToHumanTurnTime)) { 
                this.type          = 'zombie'; 
                this.isDead        = false   ; 
                this.isLivingDead  = true    ; 
                this.target        = 'brain' ;  // :)

(you can write this in a neater way with a : if (this.shouldTurn()) ... )

So now that you have your game time, you must have your entities update depending on game time :

So with delta = delta between current game time and previous frame game time :

this.update ( delta ) {  // position update for a simple entity having velocity.
    this.x = this.x + this.velocity.x*delta; // depends on dt (ms)
    this.y = this.y + this.velocity.y*delta; // depends on dt (ms)

Notice that window.performance.now is a much more accurate timer available (with a polyfill) on almost all current platforms.

  • \$\begingroup\$ Is there a way to reset the value returned by window.perormance.now? The docs indicte it goes up from the moment the document is loaded, so it'll start to lose precision before too long. \$\endgroup\$ Jan 5, 2013 at 22:43
  • \$\begingroup\$ yes, you are right, it will loose precision, but it will be like a few days before it happens (integers have 52 bits out of the 64 available for a javascript number), so nothing to worry about within a game. (PS : upvote if interested by my answer ... ) \$\endgroup\$ Jan 5, 2013 at 23:03
  • \$\begingroup\$ You lose precision right away, but a double still has sub millisecond precision after 10,000 years. randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float \$\endgroup\$
    – Adam
    Feb 4, 2013 at 21:08
  • \$\begingroup\$ "a double still has sub millisecond precision after 10,000 years" - true, but you may still run into trouble (yes, even with a double) if you start adding together a lot of deltas. \$\endgroup\$ Feb 5, 2013 at 10:49
  • \$\begingroup\$ i personnaly try to limit the time i spend on videogames, and i think others should also try to do so. 10.000 years spent on the same html5 game, without even closing the browser, seems exagerated to me, i wouldn't mind releasing a game that fails after that time. \$\endgroup\$ Feb 5, 2013 at 11:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .