Showing posts with label Canvas. Show all posts
Showing posts with label Canvas. Show all posts

Thursday, December 1, 2011

Great Webgl Canvas Scene Graph

Looks like we might have a winner here: http://labs.hyperandroid.com/animation

The project is called CAAT

From their site:

CAAT in essence is a multi-instance director-based Scene graph manager.
It is multi-instance in the sense that you can set an undefined number of directors up for each web page.
Each director is able to manage different Scenes with different timelines.
The scenes contain a graph of different Actor and Containers which conform the animation elements.
CAAT has some features out-of-the-box among which we can highlight:
  • Seamless zero-coding WebGL and CSS rendering engines.
  • Unlimited number of Scenes per Director.
  • Unlimited number of Actors and ActorContainers per Scene.
  • Hierarchycally applied affine transformations (rotations, scales and translations).
  • Hierarchycally applied alpha composition.
  • Unlimited number of timers per Scene.
  • Ability to define complex paths for translations applied to Actors and ActorContainers.
  • Easing and interpolation functions for affine transformations and alpha transparency application.
  • Homogeneous coordinate system. Each contained Actor will receive correct input coordinates on its coordinate system
    regardless of its parents applied transformations.
  • Abstracted input system, from mouse events to keyboard and accelerometer.
  • Resource management and preloading.
  • Many types of actors supported: Sprites, Shapes, Text, Path, Interpolator, etc.
  • Easily extendable framework.
  • Open Source and MIT Licensed.
  • Performs properly in all major canvas enabled browsers. Internet explorer must be version 9 or greater.
I'm going to add in the fact that the project looks very professional, and extremely useful.  The examples that are provided are very simple in context, and that is a good thing.

One of the many building blocks we need for online multiplayer games is a good solid and easy scene graph implementation.  It is one thing drawing 1000 sprites, it is a whole other thing for your game to know it only has to draw 100 of that 1000 to achieve the same results, but much better frame rates.  Or trying to propagate matrix multiplications down an unlinked chain of objects, it's like trying to hammer in a nail with your forehead without a scene graph.

CAAT looks like something we'll be exploring in the future on here.

Html5 Webworkers Introduction

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.



Canvas Cheat Sheet

Looks like someone had their thinking caps on: http://blog.nihilogic.dk/2009/02/html5-canvas-cheat-sheet.html
It's the html5 canvas cheat sheet.  Great for people just starting out.


This is just the tip of the iceberg though in terms of what you can do with canvas.