Some of the code in HullBreach has been refactored to pull some additional speed, but the big change is how graphics are displayed.  Previously, everything in the pixel range (0,0)-(500,300) was drawn to a page-flipped canvas.  It ran fine on a standard desktop computer but proved to be slow on a Wii.  Now, the starfield background has been moved from within the canvas to a displaced CSS background, greatly increasing the speed.  The overlay map used to be a section of the main canvas and was drawn as several translucent shapes.  This has been changed to a separate canvas with a CSS opacity of 0.5 and solid shapes, allowing a little extra burst of speed in the game.  Overall, I’d estimate HullBreach Online may be running as much as 50% faster. Don’t think it will stop there, though.  I may move the planets and locations from the canvas to be IMG elements inside a clipping DIV (that’s the same size as the canvas), depending no how much speed I can get.  This would leave just the ships inside the canvas, where they will permanently reside, to allow the freedom of rotation.

There was a bug in mesh generator due to it using an older version of the Wii Opera SDK v2.x. It has now been upgraded to use v3.x, so mesh submissions can continue once again. Also, the code has been cleaned up, so animations are slightly faster.

Did you know that games with advanced graphics and controls are possible on the Wii’s Internet Channel (Opera 9.x) using nothing but HTML and efficiently-coded Javascript? I’m not talking about Pong, either. I’m referring to games with graphics that rival those of Starfox for the SuperNES or the original Wolfenstein 3D for the PC. This article focuses on thinking in the mindset of optimizing your Javascript code as much as possible for both speed and memory in areas specific to the Wii. Articles already exist on the Wii Remote and the canvas object, so I will not spent a great deal of time on the specifics of those but will dive right into the meat of the topic.

Integer Math

Whenever time-critical calculations must be made, it is a good idea to work in integer-only math. (Plus, pixels are integer coordinates, anyways.) Since javascript variables are all of one type, there is no specific integer variable, so tricks must be employed to pull the extra speed boost from integer calculations over floating-point ones. There are a few ways to do this:

 scale = Math.floor((x2-x1)/img.width);
scale = ((x2-x1)/img.width)>>0;
scale = ((x2-x1)/img.width)|0;

For calculations of our needs, always avoid the first example. Javascript’s built-in Math class is very slow compared to bit shifts or bit comparisons. If all values are integers already, then conversions are only needed on divides. For rounding numbers, add half of the denominator to the numerator before dividing. The second example leads us into bit shifting over division and multiplications. Divides (and to a lesser extant: multiplies) can be processor-intensive when used repeatedly, so always use bit-shifts when an integer is going to be multiplied or divided by a power of two, like so:

 centerx = (x1+x2)/2; centerx = (x1+x2)>>1;   Continue reading...

The following Opera 9.2x time tests are all performed by running 1,000,000 iterations and reporting results in milliseconds, averaged after 5 times. Some results are obvious, while others are surprising. These tests can be used as guidelines for optimizing code.

Absolute Value (Integer)

1. y = Math.abs(x);
2. y = (x^(x>>31))-(x>>31);
3. y = x<0?-x:x;

Results:

1. 1443
2. 1456
3. 1106

Continue reading…