The idea:
Multi-threaded html5 games. Sounds easy enough...
A little bit more detail.
So just about any game can benefit from being multi-threaded.
As an example:
1 thread for handling client side physics. (box2d.js)
1 thread for updating the server (nowjs / socket.io / node.js)
1 thread for managing the scene graph (scenejs, amino, cake, etc)
1 thread for rendering background (ground, buildings, etc)
1 thread for rendering foreground (player, baddies, items, etc)
A main thread for pushing from the backbuffer to the front. (canvas, webgl, etc)
The list can go on and on, not that it should. If a function is simple, quick, and not constantly running, chances are it shouldn't have it's own thread. The benefit of running multiple threads is the holy grail of games: consistent frames per second under variable load. That right there is a hallmark of great game designers. So many times I'll pop in a game that is professionally made for a closed source single system (ps3, xbox) with very known hardware specs and at points in the game they're will be a frame per second drop (offline). This could be debated and I'm sure it is other places.
And here is a little FPS loop (javascript):
var fps = 0, now, lastUpdate = (new Date)*1 - 1;
// The higher this value, the less the FPS will be affected by quick changes
// Setting this to 1 will show you the FPS of the last sampled frame only
var fpsFilter = 50;
function drawFrame(){
// ... draw the frame ...
var thisFrameFPS = 1000 / ((now=new Date) - lastUpdate);
fps += (thisFrameFPS - fps) / fpsFilter;
lastUpdate = now;
setTimeout( drawFrame, 1 );
}
var fpsOut = document.getElementById('fps');
setInterval(function(){
fpsOut.innerHTML = fps.toFixed(1) + "fps";
}, 1000);
I'm sure somewhere someone has come up with a hard fast rule about what a good fps is. I just like to think that anything above noticeably inconsistent and slow. My goal is almost always 30+ FPS for the composited flip, less than that and people will notice, less than 24 and people will really notice.
Here is a wonderful js file for FPS
https://github.com/mrdoob/stats.js as always mrdoob is saving our butts.
So on to webworkers: a nice little tutorial:
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html and here:
http://www.codediesel.com/javascript/introducing-html5-web-workers/
What are Web Workers
Web Workers are basically a API specification that lets you create background JavaScript threads to process CPU intensive tasks. Normally in browsers a single thread is created to handle all the JavaScript code. So whatever JavaScript code is run in the browser is executed in that single thread; whether you are doing some calculation or updating page elements. The downside of this is that some CPU intensive piece of JavaScript can render the page unresponsive or slow it to a crawl.
Web Workers alleviate this problem by letting you create multiple JavaScript threads that will run independent of each other, this will prevent one CPU intensive piece of JavaScript from interfering with the UI code.
And there you have it. This post is just an introduction. The eventual goal being an explanation of how to apply webworkers to just about everything. But first I have to figure that out. ha.
