Hacker News Reader

Comment by cromwellian | Hacker News Reader

I just bought Titanfall yesterday. I run this on a watercooled PC, dual GPU setup. I wouldn't have bought such a PC setup just to run at 60% of system performance.

I think Mozilla is marketing this wrong. Triple-AAA titles go for squeezing every last ounce of system performance. I don't think there is anything to be gained to putting a game like Titanfall, which has 5 gigabytes of assets (some UE titles are much bigger and need blu-ray distribution) inside of a browser. Long downloads, long startup, half performance.

But there is enormous value of running casual games with asm.js. Something like Clash of Clans, or Flappy Bird will run just fine. Pitching that asm.js is going to scale games from mobile up through desktop performance I think is overselling things and bound to lead to disappointment.

Rather than believe we're going to get Call of Duty running acceptably on Firefox OS. Let's first settle for CSR Racing, or HayDay.

View on HN

As the video shows, this is not just about the highest-end AAA games, there is a 2D platformer there too.

But the important thing in working to port the highest-end games is to push the limits of the web platform, so it can be better optimized. Before UE3 was ported, people were - rightfully! - skeptical any such engine would work well on the web at all, and that port helped get to that point (and now to UE4).

Also, note that the 60% is of CPU performance. You also get close to 100% of GPU performance using WebGL. So overall it will be even closer to native speed (depending on how the specific game balances between CPU and GPU).

Most games these days (with a few exceptions) are GPU bound. Battlefield, Far Cry, Assassins Creed, etc are all GPU bound. You can't get away with a completely awful CPU but you don't need a great one for these. For other games, like Starcraft, or Kerbal Space Program, the GPU isn't your limiting factor, but your CPU's performance. Skyrim, for example, will perform vastly different with the same graphics card with different CPUs. For many games the anemic CPU performance won't matter, at least not very much.

> Most games these days (with a few exceptions) are GPU bound.

Most AAA games are GPU-bound, you mean. It's very rare to find titles from indie developers or smaller publishers that come anywhere near taxing a modern GPU -- due in part to the massive expense required to create engines and assets that are capable of doing so.

(Which is also why the AAA game business model seems more and more to be teetering; AAA titles have differentiated themselves via graphics for decades, but the cost of being cutting edge is so high now that if the title sells at anything less than blockbuster rates it's a financial failure.)

Actually it depends on the engine and how physics are implemented. A game like Battlefield 4 actually taxes the CPU pretty heavily.

5 GB is about one or two hours at not-unusually-high speeds. You can probably start and run the game with much less assets. Having the assets available at multiple quality levels -- chances are that's the case already -- would shave off more time. And by the sound of it, 60% of your computer is still about as fast as the just-launched console generation.

Not big issues, I think. The big issue is having a robust ecosystem for all the things like networking, input handling, sound and video.

Except that was a typo, Titanfall actually has 50 GB of assets.

You can progressively download them while the user is playing. So you start for the menu/1st level content, then the user begins to play.

Meanwhile, all unused IO/network time loads the most likely next to be encountered content (so in most cases the next level). As this happens in the background, the user most likely will never notice the content has to be downloaded first.

Naturally, this leads to another problem: piracy. After all you don't want to create individually encrypted releases per player (doesn't scale for storage), and encryption on-the-fly is also not possible (doesn't scale neither on server nor on client side). So basically you just dump a shitload of data onto a CDN and hope nobody warez's it.

Titanfall, to pick up your example, is running fine in 1080p on a mid-range card so i don't see why it couldn't run in the browser especially if you still had the option to go native so its up to Epic to make that painless for developers.

You can cache the assets locally, just like on any other game.

These tech demos are about pushing the envelope, which is needed to make the web a better platform for high-end games.

How is this "pushing the envelope"?

Running existing software in some convoluted browser-based environment, and giving a worse experience in most ways, doesn't really seem like innovation to me.

I think we could say it was pushing the envelope if the browser experience was superior to the native experience in every or almost every way. But that just isn't what we're seeing with these demos.

It is far superior in one major way - everyone has a web browser, and you can give them a link to run your game if it runs on the web. This avoids losing most of your users which is what happens if you ask them to install a plugin or a native app.

Of course, on the other hand it is inferior in many ways. It's just another option for game creators (and other apps too). For some it will be useful, for others it will not, just like consoles are useful for some but not for all, tablets are useful for some but not for all, etc. etc.

Those are all hardware setups, whereas the browser is a very poorly designed portability layer (viewed in this way). It makes me physically angry how badly the browser vendors have dropped the ball here. It was obvious years ago that things were going this way, but instead of developing a proper application-development standard they just shoved everything into HTML. Every time I hear Mozilla talking about "innovation" I get upset because it is such a blatant lie. You have reinvented to past badly here. The best that can be said is you have been good at marketing the whole thing by constantly pretending that it's "just Javascript" etc, when the end result is completely static (i.e. not Javascript).

> The best that can be said is you have been good at marketing the whole thing by constantly pretending that it's "just Javascript" etc, when the end result is completely static (i.e. not Javascript).

asm.js executes according to the ECMA-262 semantics, which are the full dynamic semantics of JavaScript.

What GALL you have to be so willfully dishonest. asm.js is statically typed and has only the most coincidental relationship to Javascript. Just as if I take pointers out of C it is no longer C. What's funny is that you are exhibiting EXACTLY the "nothing to see here" behavior I just described by invoking some completely nominal relationship between Javascript and asm.js. And it is exactly this "nothing to see here" behavior that emphasizes how deep down the web people know they are simply reacting to competitors to retain market share.

If you wrote a C compiler that had special optimizations for a subset of C without pointers, then it would still be a C compiler, and the subset that it optimized for would still be C. (In fact, this is exactly the approach taken with languages like GLSL 1.0, although they added some extensions to make it not C anymore.)

I didn't say the Javascript implementations weren't Javascript implementations. Further, you are incorrect. A subset of C cannot be C. Are you dumb? If I make an expression language is this C because C has a little expression language inside it? It is a subset - and also a SUBSET OF AN INFINITE SET OF OTHER LANGUAGES. Hopefully you can understand my anger that baboons are apparently allowed to implement programming languages. They got it wrong with Javascript and did a complete about-turn with emscripten etc in REACTION to competitors. I look forward to laughing at your continued attempts to hide this embarrassing little abortion.

> the subset that it optimized for would still be C

This doesn't mean to imply the subset is the entirety of C; it means the subset is part of the definition of C — just like you can say "'int x = 4;' is C", even though it's a (demonstration of a) subset of C.

The JavaScript which happens to be optimised under the name "asm.js" is still JavaScript that executes in any non-optimising runtime, and the semantics with those optimisations and without are the same.

Javascript was the wrong design choice, and the asm.js people are very sensitive about this. Which is why they pretend it's "just Javascript". Nobody denies that it's backward compatible. But it is a new language, the rest is word games.

For distribution and always updating content is where the benefit is (much like an appstore). Flash gaming was huge before mobile for the same reason, simple to play.

For the consumer it should be no different except they have an easy url to get to it, maybe saves are a url and there is a bit more security in theory if it is through a plugin that is widely used or tool that is widely used (asm.js).

Really this has tried to get going multiple times and really should have. Flash games were huge, Unity web games are coming up. Shockwave games back in 2000ish started it. Being open this is even better because maybe we can see WebGL gaming take off on mobile. 3d games in the browser have changed over time. Quakelive is going desktop client because browsers changing or removing NPAPI for PPAPI (http://www.quakelive.com/forum/showthread.php?34313) so maybe this is a good time to go the asm.js/emscripten route as plugin support is getting disrupted.

You 60% of native has no relevant baseline. Native is not a benchmark. For example, the authors could have optimized, or messed up their code.

What is important is that developers target platforms with certain features and certain frame rates. The devs targeted Firefox and removed a few bushes.

It is very hard to judge game quality based on compute throughput. Its a game not a benchmark.

tldr; Performance hit to native isn't a relevant statistic.

Reply on news.ycombinator.com