As I started working on our next game, I noticed a very strange and unpleasant behaviour:
when scrolling the viewport, the animation was stuttering. Here's how I fixed it.

The first impression that this behaviour gave me was that my computer wasn't powerful enough to run the game,
but having a constant 50fps (The refresh rate of some laptop monitors is 50Hz),
and a maximum 30% CPU usage demonstrated that my computer can handle the game just fine, so there must be
an elegant solution to this.

Now, anyone willing to implement a game engine should read the excellent article Fix Your Timestep! by Glenn Fiedler.
In fact, if you follow (and understand) that article until the end, you'll see that this problem has been addressed there.

Another thing to mention is that I'm also the author of the friGame library, that is used by our next game.

The problem is: I did not fully understand Glenn Fiedler's article, so, until recently,
the update/draw loop in friGame looked something like this:

Which is based on the second to last code block from Glenn Fiedler's article.

For years I thought that this code was good enough, it had a fixed time step of 16.67ms, and on 60Hz monitors
it looked good.

Moreover I was confused by the last part of Glenn Fiedler's article when he talks about interpolating between
the previous and current physics state.

What does it mean that I have to store the previous physics state? Does it mean that I have to keep track of
accelerations, speeds, and so on for every object in my game?

Moreover, if I have to keep track of the physics of the game, I can no longer use the same API in friGame, or be
free to choose a different physics engine on a game by game basis.

It turns out that none of this is true, I was simply confused by the choice of words.

You see, in the last part of Glenn Fiedler's article, the interpolation is done in order to render an intermediate state,
so, in theory, the only states to keep track of are the ones that affect rendering, and these are:

Position

Size

Rotating angle

Scaling factor

Opacity

In pratice, there is a computational cost for keeping track and interpolating all these values, so smooth scrolling can be achieved
simply by keeping track and interpolating only the position of all the sprites.

So, in the latest development version of friGame the update/draw loop looks something like this:

friGame.draw=function(timestamp){varnewTime=timestamp,frameTime=newTime-currentTime;requestAnimationFrame(friGame.draw);currentTime=newTime;accumulator+=frameTime;if(accumulator>=dt){while(accumulator>=dt){// Keep track of all the sprite positionsfor(spriteinfriGame.sprites){sprite.prevLeft=sprite.left;sprite.prevTop=sprite.top;}playground.update();accumulator-=dt;}}playground.draw(accumulator/dt);};sprite.draw=function(interp){varleft=(this.left*interp)+(this.prevLeft*(1-interp)),top=(this.top*interp)+(this.prevTop*(1-interp));ctx.drawImage(this.img,left,top);};

After implementing the interpolation of only the sprite positions, I was impressed by how smooth the animations have become.

I'm planning to release an update to friGame in the next few weeks, so stay tuned.

Concluding our series about local multiplayer via WiFi, we are going to address the Android bug
that prevents local hostname resolution, and we will see the aspects to consider when using directly IP
addresses instead of host names.

Last time we have seen that a great solution for implementing local multiplayer on
WiFi networks is to use Zeroconf and WebSockets.
In this article we will see how to use these technologies, and some implications that are not obvious at first.

Our next game will feature local multiplayer, and in this blog post series I will talk about the
technologies that can be used to implement such feature, their platform support, and their implementation
in Cordova.