
Optimizing your JavaScript game for Firefox OS - rnyman
https://hacks.mozilla.org/2013/05/optimizing-your-javascript-game-for-firefox-os/
======
willvarfar
I'm working on a webGL game that runs a sim in a web worker.

On Chrome, my sim runs at about 40 ticks/sec on my fancy macbook. Safari and
Firefox only get 5-10 ticks/sec.

On an older core2duo HP laptop I see 15 ticks/sec for Chrome and 3-5 ticks/sec
for Firefox, on both Linux and Windows.

A new cheap Asus laptop gets numbers very similar to the core2duo, but the
rendering works a lot better due to better graphics card.

I want to move some priority queue code I have to handwritten asm.js when I
get time, but don't expect it to make a big impact.

Its just so hard to actually profile your code and understand your
bottlenecks. What happens in web workers is basically invisible.

Before I had web workers my putting sim ticks into the render callback was
making the game very unresponsive, particularly in Firefox.

I dream of the game working on tablets etc, but that seems a long way off.

Games like the original simcity and tycoon series and a-train all worked well
on really really low-end machines, at performance that seems out of reach for
javascript games that basically work the same :(

~~~
PommeDeTerre
What you describe is a reoccurring theme when it comes to JavaScript
applications in general, but it's much more visible when games are involved.

The unfortunate reality is that JavaScript, WebGL, and these other
technologies running on extremely powerful computers (even if we're talking
modern mobile devices) still can't compete with games written back in the
1980s, in C and assembly, which ran perfectly fine on what are now 25-year-old
386 PCs with a mere fraction of the processing capabilities of a modern
system.

As an industry, or even as hobbyists, we should not be in this position. At
best, we can call the current situation a complete stall in advancement. At
worst, but more realistically, it's been a significant step backward.

~~~
antimagic
It's not really a fair comparison - much of a game's work is pushing pixels,
and today's systems have an order of magnitude more pixels to push (1080p =
2MegaPixels, 640 x 480 = 300 000 pixels).

Today's game written in Javascript will also run on numerous different CPU
architectures, on different OSes. This generality means that you can't take
advantage of platform specific hacks that allow the eking out of every last
scrap of performance from the silicon.

So yes, when you make a game do a lot more work, and you want it to run on
multiple platforms, forcing optimisations to be platform-agnostic, you
shouldn't be surprised that it's hard to match the performance of 25 years
ago. On the other hand, if you use the same technologies as 25 years ago,
you'll smash the performance from back then. Likewise, if you try to run
SimCity in a browser ported onto a 386 PC, it would be an insult to dogs to
say that it runs like a dog...

~~~
PommeDeTerre
There are only about 7 times more pixels in the modern system in your example.

Yet in the same time, x86 processors have gone from 25 MHz to 3,000 MHz, if
not higher. That's a difference of 120+ times.

That's not even considering that basically all PCs (including laptops) and
many mobile devices, now have CPUs with at least 2 cores, although 4 or 8
cores is pretty typical, too. Back then, uniprocessor PCs were really the only
practical option.

The amount of memory available today is significantly larger, too. At the end
of the 1980s, it was impressive to have 2 MB of RAM in a desktop PC. These
days, we're generally looking at 4,000 MB of RAM, if not more. That's 2,000+
times more RAM today! When it comes to mobile devices, we're still looking at
hundreds of times more RAM. The speed of memory today is also much faster than
it was back in the 1980s.

And, of course, we've seen absolutely massive strides in video card technology
in that same period of time.

Given those kinds of increases in the power and amount of resources that are
available now, JavaScript and the other web technologies have absolutely no
excuse for performing as poorly as they do.

I don't even buy the argument that JavaScript is much more portable than C was
back then. SimCity was ported to many, many platforms. I remember playing it
on PCs running DOS, on an Amiga, and even on an SNES at one point.

------
harisaltaf
For canvas games I recommend locking viewport to device-width and disable
scaling. The scaling mechanism mentioned before is mostly for letting the game
canvas adapt to multiple screen sizes and works also good on desktop.

