What Will It Take to Make HTML5 Better for Games?

The rush to kill off Adobe Flash is premature. Even Facebook’s Mark Zuckerberg has admitted that his company’s “biggest mistake … was betting too much on HTML5 rather than native. ” While Flash isn’t native, it’s generally faster than JavaScript. Although he was of course referring to mobile apps as native code, the principle still applies.

Technically the problem is one of horsepower plus the browser getting in the way. The absolutely fastest way to move pixels around on your screen is with an application written in assembler, or better still C/C++, in conjunction with a graphics processor doing the heavy lifting.

From my experience of using C to write snakes and asteroids games on Windows, I know that frame rates of 400-700 frames per second can be achieved. These are very high as it’s not syncing to the monitor refresh. That’s on a one-year-old PC with a GTX 480 graphics card, so it’s exactly state of the art. But similar technologies and exploiting the power of the graphics processor are what make AAA game titles run so fast.

In JavaScript, it’s possible to get frame rates of 50-60 fps with a number of moving onscreen objects. But the approach is still seriously underpowered compared to native code. This is a limitation of the technology, how fast the HTML5 <Canvas> works, how fast the JavaScript is executed, and the overall efficiency of the browser.

Browser technology is gradually improving but it still chokes most of the processor power. When Google brought out its V8 JavaScript engine a few years back, it set a new standard for performance. Others followed, like Spidermonkey and later Jaegermonkey for Firefox.

The recent big news in this regard is the enabling of IonMonkey in Firefox 18. This adds an extra step to translate JavaScript to an intermediate representation, optimizes the representation and then translates it to machine code. Previous engines just optimized the JavaScript. The performance impact can be as much as 26 percent. This is still its early days, though, so more performance will likely be wrung out.

Another issue: The performance of generated code is highly variable. On Mozilla.com, Alon Zakai points out that Octane uses a new Google benchmark, the closed source C++ to JavaScript compiler, Mandreel, which runs its converted code well under some benchmarks but not under others.

Other routes are Google’s native client with games, like the impressive conversion of Bastion showing what that technology can do. But so far only Google Chrome supports that.

To get the type of game we want, I believe that we really need some kind of hybrid browser that can safely download and run native client applications or generate highly optimized machine code from JavaScript.

WebGL is nice as this physics engine demo running at 30 -60 fps shows. But it takes more than WebGL to make a game.