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.
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.)
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.
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.
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.
This is very exciting. I've had the chance to meet Brendan Eich a couple of times at Moz conferences, and he never fails to strike me as a visionary and a super nice guy. Between the asm.js stuff and Rust (which I actually had the privilege of witnessing the much-anticipated unveilling several years ago. Honestly I thought it was an overly-ambitious fools errand but that's why I'm not cto of mozilla), he really seems to be driving Mozilla exactly in the right path of where the web is going.
From what I can see, Mozilla is generally going in a direction that's alienating existing users, without necessarily bringing in any new ones.
For example, it's widely understood today that Firefox has a much smaller share of the market now than it did a few years ago. Most measures I've seen show a drop from somewhere in the mid 30%'s down to under 20% today. Proportionally fewer Firefox users means less influence over the future direction of the web, of course.
SeaMonkey never really had that much penetration to begin with, and still remains basically irrelevant.
Firefox OS doesn't really seem to be taking off. While it may sound nice from an ideological standpoint in terms of openness and standards and all of that, in practice it doesn't sound very enjoyable or practical to use. I've seen enough people show displeasure over the low-end devices it's commonly used with, with the highly restrictive development environment (being forced to essentially use JavaScript/HTML5/CSS for apps), with a lack of features, and a lack of apps. Those are very serious and fundamental shortcomings.
Thunderbird and Persona have both been "turned over to the community". That appears to be a polite way of saying that Mozilla has given up on them.
Asm.js is pretty unremarkable. It's a human-unfriendly subset of JavaScript. NaCl is a much better approach that would ideally be adopted by the major browsers. Unfortunately, we've seen nothing but hostility toward it from Mozilla.
Rust sounds appealing, but it's not really usable today. We keep hearing that there will be a stable release sometime later this year, but we'll need to see that actually happen first before it'll have any chance at being widely adopted. Even then, it's doubtful Rust alone will have any major impact on the web any time soon. Servo may, but that's clearly very much also an unusable work in progress at this point.
So overall, I don't see Mozilla as heading in a very positive direction. They really haven't had any wildly successful new offerings in quite some time now, and what they have been working on lately doesn't seem to be getting all that much adoption. Without a large base of users, their influence over the development of the web will just get weaker and weaker.
> Asm.js is pretty unremarkable. It's a human-unfriendly subset of JavaScript. NaCl is a much better approach that would ideally be adopted by the major browsers. Unfortunately, we've seen nothing but hostility toward it from Mozilla.
Why is NaCl better? NaCl adds all of the complexity of LLVM to the Web platform, and is tied to Pepper, which is a Chrome-specific, nonstandard API. None of this is true for asm.js.
> Even then, it's doubtful Rust alone will have any major impact on the web any time soon.
Rust isn't designed to have an impact on the Web directly; it's designed to be a programming language.
> Why is NaCl better? NaCl adds all of the complexity of LLVM to the Web platform, and is tied to Pepper, which is a Chrome-specific, nonstandard API. None of this is true for asm.js.
i really really like mozilla. it's one of those few places, where i'd be comfortable working, but believe it or not, pacabel has raised a few very valid points.
nacl has much better performance and was a padded x86 abi, it's much easier to port some game to nacl, than it is to turn it into webgl. when i went to the google developer days in 2009 some of the google munich guys didn't like it either. i don't understand why. trying to force everything onto something as broken as javascript is odd.
but nacl is tied to pepper because npapi is utter shit. and has been for the past 10 years for that matter. i understand that you guys keep proposing npapi changes, because you want some sort of open thing, but it's broken. pacabel's point is valid, you had the power to push for an alternative, and you didn't. now that google has taken your spot, they took the opportunity to do that, and mozilla refuses to play along.
even though before nacl came out webkit already came out with webkit plugins, precisely because of the same problems ppapi is trying to address.
we know it's broken, apple knows it's broken, microsoft knows it's broken, and i'd be surprised if you didn't know it either. why beat around the bush?
i still love firefox and it's my main browser, and contrary to others i believe the memory usage is way below chrome. but on the other hand i'm forced to constantly run a chromium browser, because if i use flash in my favorite browser, the whole experience will eventually become so choppy that i have to close and open my browser.
then there's this shumway thing, which is a really cool piece of code, and i'd probably enjoy hacking and reversing(mainly because i like reversing), but let's face it realistically it's still completely irrelevant to the real world.
> but nacl is tied to pepper because npapi is utter shit. and has been for the past 10 years for that matter. i understand that you guys keep proposing npapi changes, because you want some sort of open thing, but it's broken. pacabel's point is valid, you had the power to push for an alternative, and you didn't. now that google has taken your spot, they took the opportunity to do that, and mozilla refuses to play along.
But asm.js is not tied to NPAPI!
In general it should be obvious that Mozilla isn't interested in plugins in general. Its solution to "NPAPI versus PPAPI" is "neither: use the Web APIs". This is what Robert O'Callahan was explicitly arguing on the plugin-futures mailing list several years ago.
Firefox OS has been launched in 16 countries. You may not be on an emerging market but people on most of these countries are enjoying what affordable smartphones can give them. In Venezuela alone Firefox OS already has a larger marketshare than Windows Phone. Firefox OS went from 0 to 16 countries, 4 hardware manufacturers and 4 global telecoms in 2 years. And it did that while being open, accepting contribution, encouraging sharing and open culture, placing privacy and values over profits. Yes, Android and iOS are larger, much much larger, but we need to think what kind of world do we want in ten years. A world where each mobile device is a silo with its platform under complete draconian control of a single company thats usually from the northern region of California or where each platform is embracing open standards, where apps are light and cross platform where people can go from consuming content to creating content fairly easy (HTML being way easier to learn than Obj-C).
There is a reason why we're using the World Wide Web right now. Its not an app. Its an ecosystem based on standards where everyone agrees more or less to play by the same rules. Its also easy to learn so anyone can put anything online, it doesn't matter if you're building a home page about crappy gingerbread people, you don't need permission from Apple or Google or a lot of knowledge to do it. The Web won as main medium to exchange stuff because its easy and open.
Initiatives such as NaCL and similar are not open. ASM.js based stuff work even on platforms that doesn't support it. Its about being compatible and playing well with others.
Mozilla is a strong player and it is not playing a game where the others need to lose for it to win. Its playing a game where cooperation is the main objective. Firefox OS doesn't need to win, it just need to show people that you can do whatever you need using web technologies that don't belong in a silo.
Sorry if this sounds like a rant but I get really frustrated when people seem to be content to throw all the advancements we did for the web during the last 20 years into something as shallow as user base numbers.
Four years ago no one could believe that a whole OS could be built on top of a web engine. That browser would be able to play AAA games without plugins. That we could do videoconferences using p2p with nothing but HTML/CSS/JS and yet we can. Now, put your imagination and dreams to work and imagine what the next four years will bring. Thing a bit longer and imagine what could happen if instead of trying to embrace proprietary tech we decided to move the web forward...
Launching in just 16 out of 190+ countries isn't very impressive. That's well under 10% of the entire world.
Likewise, having more market share than the 4th or 5th place competitor, but still being significantly far behind the leaders, isn't very impressive either. It's even less impressive when this is in a rather small and irrelevant market.
And the web argument isn't very good, either, given that Android, iOS, BlackBerry OS, and the other major players support the same technology.
All I see here is Mozilla spending a lot of time and effort on a product that's seeing very little adoption, while only being able to do a fraction of what its competitors are able to do.
That's just not a way to gain influence, and it's not a way to maintain whatever influence they still have thanks to their success with Firefox in the distant past.
I see with my parents and their peer group I've been supporting for years why the numbers for market share may also be misleading.
I installed Firefox on all of their computers, taking favorites from IE. They all use Chrome today. You know why? They don't know. It was just there. Suddenly. Already set as preferred browser application. Every time I come by, I uninstall it. Every time I come back, it's there again. Installed with some regular update. (If someone has an idea how I could prevent it being installed at all, I would be very thankful)
After testing it for some months I saw absolutely no reason to switch. After some more months now, I see is as an annoying piece of crapware I started to hate.
So even if it may lead in marked share, it doesn't mean that people likes or wants it..
I see the style and feature growth within FF as a problem. I liked the old school application I could modify with stuff I need. Less is more. Today I have the feeling using a tool that has features I'll never find or use at all with a look I don't like and need to style-down. But still: I can style it down. It has all the Add-Ons I need and it works more stable and less resource hungry then Chrome. If anything happens, there is ONE process. I kill it, restart, works again.
I really have no idea what point this post is trying to make. I see anti IE (installing FF over IE), anti Chrome ("crapware") and anti FF ("feature growth within FF) sentiments, but no tie-together logic. Do you have a conclusive point you're trying to get across?
I think aluhut's point is that at various points in time Chrome has come bundled with various other software on Windows, often enough as an opt-out install, not an opt-in. Needless to say, Google has spent a fair amount of money on those sorts of deals. This is an effective, if sleazy, way of gaining market share.
Let's just say that pushing Directory Tiles so fast* that the end-users do not even have a chance to react is not a good way for Mozilla to prove it's worthiness.
Also, it doesn't matter if groups within Mozilla keep making chemically pure awesomeness (like your Shrink team or the JS guys), if the leadership has to do only one thing to overshadow the good things with bad news.
* arrangement bugs are already worked on the way I saw it
This is neat and all, but I wonder if things are really better moving to "in the browser." The discussion is of "upwards of 60% as fast as native." Is this using the same amount of processing power as native, or is this "67% as fast as native, using 200% of the CPU as a native solution?"
I mean, I realize that processors and machines are only getting more capable. It seems silly to start requiring faster and faster processors to achieve what slower ones could have achieved. I would rather we just kept achieving more.
For a high level managed language, 67% would be pretty godlike. There are some C programs that are less than 67% the speed of their own -O2 compilations. If 67% native speed winds up being the average efficiency, that's plenty good enough for the vast majority of computing.
As recent history has been teaching us, doing more with less has mainly to do with getting more mobile, distributed, and ubiquitous. We're quickly reaching the point where that means something even "smaller" than a web browser.
You ignored my 200% mark, though. If I could run this demo in the browser and it pegs all of my cpus, compared to running the same demo "native" and having half my system capable of idling, I'm not sure I see the win. Even if it gets to 100% of "native." (I hate that it sounds like I am claiming that is the case here, as I really don't know.)
For a user that can install a native build, the native build will run better. No doubt. But, most users in the world do not know how to install apps, and even if they did they shouldn't because of security concerns.
For that reason, game devs know that asking people to install a plugin or a native build will kill off most of the potential users of their game.
Instead, if you just give people a link to click and it jumps right into the game, that will maximize the amount of users able to play it. This is the main reason for the anti-plugin and pro-web movement in games.
Oh, so native programs are the boogey man now, huh? I don't know where this whole push for Everything Must Be JS comes from, all it does is waste electricity maxing out Core i7's running some raster demo from the 80s.
> But, most users in the world do not know how to install apps
That's a ridiculous claim.
> if they did they shouldn't because of security concerns.
Equally ridiculous. All the new shiny HTML5 tech is also bringing its load of security issues and an ever-increasing attack surface as the Web Browser slowly transforms itself into an OS.
There's a valid reason for running small games into the browser, but there'll never be a good reason to do that for a performance demanding game.
A game like this is a singular and extreme case. I can see a really big win for lots of business software. With browser deployment, lots of logistical problems just disappear. Heck, the notion of traditional corporate structure starts to disappear: Corporations exist because they can provide lowered transaction costs in specific contexts of production.
I'm not sure I see the win. Even if it gets to 100% of "native."
Even if Unreal engine FPS don't get to 100% of native, that doesn't preclude the disruption of lots of other software distribution models, including entire subgenres of games. But it goes much farther than just games.
How does this accomplish anything that Steam isn't already accomplishing, though? I have only bought humble bundles, and I already have a couple of hundred games on Steam. Tempted to buy more.
How does this accomplish anything that Steam isn't already accomplishing, though?
Browser based distribution has the potential to have better security than Steam currently has. Of course, Steam could implement those things as well. It could well be that Steam or something like it will win over the browser.
I don't see how a browser based distribution has the potential to be better as far as security. I don't think it is foregone it would be worse, mind.
What does a browser by in terms of added security? Encrypted connections did not spring in to being with ssl. And, doing a secured stateful connection seems easier/better than the stateless messages method of traditional http applications.
Please re-read. Browsers don't have exemplary security, but, what they have can be slightly better than simple code signing. Also, I say it's entirely possible that the other platforms to leapfrog them. The problem with current sandboxes for native code, is that they disarm the participants while empowering malicious code.
I am rereading. I am also asking for specific examples of how a browser has potentially better security than a custom application. Because, I just don't see it.
Unless you are trying to say that something in a limited sandbox of a browser has limited capability outside of said sandbox. But... how is that not just as true of any other sandbox approach.
Right now, native code security is pretty much limited to code signing and sandboxing. Browsers go one better than code signing with restriction of communication. Additionally, entire classes of exploits are made much harder because Javascript is a managed language.
"67% of native speed" means that for a fixed CPU workload, it will take 1.5 times longer to run. Of course this depends a lot on the benchmark, some run better and some run worse.
Note also that this is on the CPU. On the GPU, WebGL is already extremely close to native GPU speed.
The fixed CPU workload makes sense. I mistakenly took it to mean they simply got within 67% of the framerate of native. Mayhap my misunderstanding is even deeper and those mean roughly the same thing.
I'm still not sure I see the compelling use case. The tooling to create games that target various platforms already exists. Does this really widen the ballpark?
Measuring performance by framerate is tricky actually - it usually maxes out, and it's an inverse value, etc. It's a good quick measurement perhaps ("game X gets 50fps in Y but 60fps in Z", then clearly Z is better) but it's not an accurate measurement in many senses (for example both could get 60fps but one might use less CPU cycles).
Measuring execution time for a fixed, deterministic non-stop workload is the best thing in my opinion.
The web has always had the best discovery mechanisms. The problem endemic to Steam and the App Stores has been poor discovery. Good discovery mechanisms mean better information flow in the market, which generally means more innovation and consumer benefit.
But if the walled gardens get really good discovery, they would win and deservedly so. As it is, they smell a bit too much like crony capitalism.
I just don't see it. The web does not have any better discoverability than any store front that proceeded it. What it has is a virtually free cost of entry.
Take the game 2048 that made headlines here. I didn't discover it because of some intrinsic discovery mechanism of the web any more than if I was to just keep watching the games page on amazon.
No, I found it because someone could pop it on github and share with all for free. And, it should be noted, in this case the game is based off of a riff of a popular iphone game. How did that game itself get discovered?
This is not to say that I hate HTML and all it entails. I make my living there. I do, however, find myself finally beginning to question the supposed benefits it is bringing to the table.
For my final point, consider that Steam is allowing me to play games that haven't seen release for years now. In some cases I miss out because I run linux, but their efforts are drastically increasing my ability to play current and past games in ways that I just do not see this approaching.
I'm not kidding. I am definitely old enough to remember the world pre google. I am also old enough that my kids can discover a crapton of stuff walking the isles of walmart.
Even now, I am more likely to discover a good game walking down the wall of gamespot than I am surfing the web. If I really want some discoverability, I go for magazines or similar digital fare nowdays.
Seriously, when was the last time you used google to find a game. Because, I don't think I have ever even heard of someone doing this. What I have done is browsed the lucasarts website hoping for news of upcoming releases. Or pulled up arstechnica's game section to see what is current.
Or, more recently, subscribed to humble bundle to see what they have to offer.
I am not (and can not) claim that the internet has not helped find some games I otherwise would not have found. I assert that this is because it hooked up some developers with a distribution mechanism they did not have before.
And yet, even as I type that I know how bloody stupid it is. I am also old enough to remember dialing in to a BBS in Texas, as they were the closest I could find to download Doom, Jill of the Jungle, Commander Keen... It is not like there were no methods to get games created and distributed pre google.
Seriously, when was the last time you used google to find a game.
Seriously, Google's the first place I turn to to find anything but a game.
It is not like there were no methods to get games created and distributed pre google.
But it did and does seriously help people find almost everything. As far as discoverability of games, I'm not sure what the problem is. I think the sad truth is that most games that aren't the big hits and aren't beloved long tail cult classics just suck. That said, it's kind of hard to make sure your long tail cult classic gets traction in an app store, unless you have the help of an outside community, which is usually helped tremendously by the web and by search engines like Google. (Just as BBS helped back in those days.)
The same can be said for all development over the past 15-20 years. The reality is development time and cost is drastically lowered when intermediate developers can produce working software with minimal consideration toward optimization, lowering resource usage or decreasing overall package size.
And better tooling helps here more than anything else. The giant elephant in the room nobody likes to speak towards is that Flash dominated not because it was a great language, but because they had awesome tooling around it. This is doing very little to address that.
Now, the Unreal Engine is a great tool in and of itself. Having it target the browser is the questionable part to me.
If you look at the browser makers who primarily target operating systems other than their own (Safari doesn't count, as Safari for Windows is mainly a developer tool, not a product; and Opera doesn't count, as it's now based on Chrome, rather than being its own), they're pushing heavily for the browser to be the userspace, both in terms of shipping an OS based around their browsers (ChromeOS/FirefoxOS) and shipping apps to current OSes using their browsers rather than native code.
This demo may focus on the high-end graphics, but I doubt that's the reason anyone is investing effort into this. Mozilla wants cross-platform mobile games on Firefox OS, and Epic (I'm guessing) wants to be able to run games on Firefox OS/Chrome OS/Sailfish/Tizen/Ubuntu Touch/flavor-of-the-month that supports HTML 5, as a long-term hedging of bets. Not all of those explicitly support asm.js, but Chrome is going to get better at supporting asm.js even if it never gets to feature parity with Firefox, and the non-iOS world is likely to be running a derivative of Chrome or Firefox.
So, if you look at the four main browser vendors... Well, two of the four browser vendors, you will find that browser vendors would like to extend the reach of the browser.
Not sure how that is surprising.
The argument for wanting to target all of the platforms seems nice. Except the major tooling companies that want to target multiple platforms have already learned how. Seeing games come out on PC, Xbox, and Playstation is proof enough of that.
So, again, what does this buy that the tooling does not already support? Especially if you simply design things such that they can be cross compiled with C.
Regarding tooling, I agree Flash's tools were a huge benefit for it. The same is true for engines like UE4 and its competitors, they all focus a lot on tooling. When those engines are ported to the web, the tools are part of that.
Some tools might not just work, of course, like profiling tools or anything else that runs while the game executes on the target device, as opposed to the dev environment. But:
1. I have seen even things like profilers being ported together with the engines. Takes some porting but the result is you have the engine's normal full set of tools.
2. You have the in-browser tools as well - all modern browsers have profilers, debuggers, etc. And also they support source maps, which means they can see the original source code and not the hard-to-read compiler-output JS.
Right, but it is safe to assume there will always be native targets for UE4. So, how will the web target really be a benefit? I can't imagine the DOM inspector will really be that useful in designing a 3d game. Am I wrong?
The web target is mainly of benefit in getting to users, not in designing the game. For design, you would use the engine's normal tools for all targets anyhow, web included.
As I said elsewhere, I only take this if you are saying "users" and meaning "developers."
I can see the point, but I see access to the tools as way more valuable than this. And with the tools, I'm curious just how many more "users" developers will truly be able to aim for. One off demos not withstanding.
How many games are there that run from links off the web that are actually making money? (Not being an ass. I seriously want to know if there are any numbers on this.)
I don't have business numbers, but there are huge amounts of successful games on the web, using Flash (for example FarmVille on Facebook, etc.).
The issue of course is that Flash has many technical issues, doesn't work in all browsers/all OSes, and so forth, hence the move to do the same games in HTML5.
azakia, a Flash App once requested my permission to turn on my Mac's built-in video camera and microphone.
Funny how I was just then commanded by G-d Almighty Himself to unstall my Flash plugin.
While Flash does require permission to enable video and sound input, I am dead certain that someone with a clue could find a way to do so without actually asking permission.
It's not like those who like to hang at Websites of Ill Repute are diligent about keeping their patches up-to-date.
Apologies for not responding. The post above talking about how this wasn't necessarily referring to frame rate basically hit my misunderstanding on the head.
Games performance is often GPU bound. If a driving language (C++, JavaScript of whatever else) is fast enough to compute application logic without delaying frames, it doesn't really matter if it is x% slower compared to some other language. GPUs in WebGL are programed using native shaders so there is no performance penalty for GPU computations.
The X% from the link is not about performance of the demo, but about performance of asm.js: "In less than 12 months, optimizations have increased the performance of Web applications using asm.js from 40% to within 67% of native, and we expect it to get even faster". To me such number doesn't mean much, it most likely refers to some micro benchmark that achieved 67% of native performance.
Especially considering that asm.js isn't really using a JS execution engine. You can smuggle a low-level machine code via any mechanism. As I understand, without asm.js specific optimizations, it doesn't really work.
I know, it's a cute way to get some movement without the political nightmare of having to decide on a proper VM for the web. Since it's "just JavaScript", other browsers will run but be really slow, leading users to blame the browser. At least, I guess that's the idea. It's still a shame they have to resort to such tricks.
Of course they do! asm.js is a collection of everything in Javascript that optimizes on the current hardware. It's not the least bit dynamic, i.e. it is not Javascript.
argh people here are so negative. You get a lot of the content you consume over the web. You can stream videos over the web and that is more convenient that using DVDs. you get "facts" from wikipedia and similar resources and thats easier than picking dead tree encyclopedia. This is about convenience. When games start being playable on browsers you won't need a local install or different ports for different platforms. You will need just a browser. It won't matter if you're on windows, mac or linux. It will just work. That means reduced cost for the studio. That means less support calls. That means easier setup.
That will also mean that people will be able to experience with less mainstream stuff. Sharing stuff on the web doesn't require Apple, Google, whatever company approval. It becomes easier to create content and users have less resistance to opening a web page when compared to installing a game. Also its safer since JS language is pretty safe regarding exploits and viruses and general malware when compared with something built with native code on your machine.
Clueless. Just clueless. None of these benefits are tied to the crap browser platform that's been foisted on us. The stewards of the browser did a terrible job of designing it, as proven by shoddy hacks like asm.js. Did you know that it took WebGL to get them to introduce typed arrays? They weren't smart enough to see the usefulness of this, they had to bumble into it. Same with async HTTP requests. So woopty-doo you've caught up to where the JVM was over a decade ago. Semantic HTML has been destroyed by this mindset also.
WTF? You simply go around calling people clueless without knowing their background? What is wrong with you?
The browser platform is not perfect, its not close to perfect, its evolving to do something that it was not originally designed to but it still the best shot at cross platform software. You can pick the JVM for all elegance it had, it never achieved what simple servers with bad markup languages did. There is a reason why you are typing on a browser right now and not using a java applet. The reason is that even with all the drawbacks of web technology, it works, it is easy to implement, it is easy to learn. Its not about über programmers in ivory towers, its about empowering everyone with a technology that is easy to grasp. It takes a very good professional to craft a good web app but it still easy enough that people from non-technical backgrounds can share knowledge. Its a platform for sharing stuff.
Yes they added typed arrays just now. The engines evolved a lot during the last two years. Lots of things are being ironed out. Instead of just seeing deficiencies, see how progress is being made with something that is open, free and common.
None of these benefits are tied to the crap browser platform that's been foisted on us.
No, but they are tied to the web, for which browsers and JavaScript are an incumbent technology. You are right, in the same way that Windows has nothing in particular to do with games, outside of a fortunate adoption of DirectX. It's just that it's the way the world turned out. Admittedly, there are downsides.
The popularity of DirectX doesn't vindicate Windows either. So what's your point? It's shit but, eh, that's the way the world turned out? People have every right to be annoyed because the people who were entrusted with the concept of the web implemented it very badly. At least on Windows there's a serious effort to give me as much of the machine's power as possible. I had a better programming experience with Java applets more than a decade ago. It is a joke.
Well, I agree. And asm.js etc are better than what we had before, so some praise should be allocated to them. But it is not innovative or elegant; it's a hack that takes us back to the state of the JVM more than a decade ago, and we're going to be paying the cost for it for some time. Hell, they can't even get the simplest possible thing - the syntax of HTML - right. So it will always anger me when I see web types touting their "innovation" etc. They are good at one thing: marketing to stupids.
WebGL is a deliberately limited but secure sandbox based on a spec for mobile devices that is two major releases out of date and makes an Xbox 360 look like science fiction.
Asm.js is an enormous hack where we limit the computational expressiveness of performance critical code by the semantics and standard library of a language notoriously shit at it.
> WebGL is a deliberately limited but secure sandbox based on a spec for mobile devices that is two major releases out of date and makes an Xbox 360 look like science fiction.
Unreal Engine 4 is a counterexample.
> Asm.js is an enormous hack where we limit the computational expressiveness of performance critical code by the semantics and standard library of a language notoriously shit at it.
To be honest, the video in TFA looks like something out of a 2009 game, it's not particularly impressive. And I guess it'll probably be a rolling demo, not having the requirements of a complete game that also has to handle a bunch of computationally expensive stuff like collisions, game logic etc.
"Unreal Engine 4" is marketing buzzspeak. WebGL is modelled after OpenGL ES 2. Its GLSL support is massively outdated. It lacks features like multiple render targets (used by any deferred renderer in the XB360 era, e.g. Unreal Engine 3), geometry shaders, multisampled reads (for HDR MSAA and hybrid spatial/temporal AA techniques), and tons of other common techniques.
Asm.js is limited by having no 32-bit float type, no 64-bit int type, no SIMD, no dynamic memory allocation and the fact that they had to extend the language from day 1 just to be able to multiply a 32-bit integer by another quickly.
> "Unreal Engine 4" is marketing buzzspeak. WebGL is modelled after OpenGL ES 2. Its GLSL support is massively outdated. It lacks features like multiple render targets (used by any deferred renderer in the XB360 era, e.g. Unreal Engine 3), geometry shaders, multisampled reads (for HDR MSAA and hybrid spatial/temporal AA techniques), and tons of other common techniques.
> Asm.js is limited by having no 32-bit float type, no 64-bit int type, no SIMD, no dynamic memory allocation and the fact that they had to extend the language from day 1 just to be able to multiply a 32-bit integer by another quickly.
64-bit ints and SIMD are being discussed on TC39 right now. Dynamic memory allocation (assuming you mean growing the typed array) isn't that important and we have ways to do it if we need to.
> You may want to actually inform yourself.
This kind of comment is emblematic of HN's evaporative cooling, especially when it's inaccurate. :(
A decade-late attempt to catch up with the JVM. Notice how there's no design here? It's because the web people had no idea this would be necessary and it got bolted on as a reaction to competitors. That is to say, the innovation belongs to plugin vendors, not the web people.
I would have been perfectly happy to be working with the JVM here, except that the JVM as a platform for web-type client stuff died because the user experience was implemented so shoddily.
There was no conspiracy against it. It had its chance. It used to have high install rates. It was placed about as perfectly for success as you could hope to be. If it hadn't failed so miserably at what it set out to do and be (and instead succeeded in a different area), we would be using it now, and living in the utopia you wish for.
As an aside, a lot of your complaints against web technologies make it sound as if there is a cohesive group of people designing something and doing it wrong. Actually it's a much more chaotic process involving a diverse group of people and companies and competing interests. It doesn't guarantee that we end up with the best designs, but such a process has benefits too, and since it's happening in the open, you could actually take part too (assuming you aren't already).
>It doesn't guarantee that we end up with the best designs, but such a process has benefits too, and since it's happening in the open, you could actually take part too (assuming you aren't already).
Unfortunately, what is needed is LESS people participating.
This is really cool, I've always had a soft spot for the Unreal Engine. But it reminds me once again, why the hell does Flash even exist any more? While I get the whole "HTML5 wars" thing, I've done standards and I know how those get mired in the muck, but if you can write a game engine with this level of performance, writing an open source 'flash' equivalent should be pretty doable right? And open source and open tools and don't bother with the quacking of the standards guys, just focus on something that works right?
Its quite contrary to the approach onLive and Gaikai have been taking with streaming games from the cloud to any device that is able to output a video stream. I tried some Gaikai demos before they were acquired and to my surprise it worked very well. Both have their ups and downs but as i see it the ultimate endgoal would be your desktop in the cloud accessible from any device by realtime low-latency streaming. In that scenario gaming in the browser would still be possible but make a lot less sense.
Firefox's new theme does look a lot like Chrome. The tabs are more rounded and the color scheme is a bit different, but without going into the menus it's hard to tell them apart at first glance sometimes.
Oh yuck, they're bringing back the big wasted void along the top of my page? The fact that Firefox replaces the title-bar with tabs is my favorite feature of the darned thing.
Chrome and current FF have the same "big wasted void" when not maximized. You need something you can grab to drag the whole window about, as opposed to a single tab. It goes away when maximized, and I'd hope Australis will stay the same.
Try Palemoon, it highlights FF's basic openness (and compile-ability on a _not_ 8gb+ rig) very well too and fast while it's at it.. Also I would advocate using a custom userChrome.css file for FF instead of extensions, much lighter and clearer setup in my opinion.
All the asm.js stuff... well, they still haven't ported UE3/UT3 to Linux, haven't they?
Sidenote: IIRC all UE code is cross-platform compatible - so shouldn't it be possible to fuse the UE3 JS engine port and the UT3 content to provide a "cross platform UT3"?
WebGL2 is a work in progress, but I believe this demo can use some WebGL extensions. And I think WebGL2 will include those extensions by default. So there is some connection.
It's a YouTube video? Will it run on Linux? I still have UT3 in the box new, the promise of it running on Linux evaporated even though UT2004 ran better on my machine on Linux than when I ran on Windows on the same machine.
Yes, it runs on linux. (I use linux and I've tested many of these demos, perhaps not this specific build though.)
The only issue with linux is if you have older GPU drivers, they might be blacklisted by the browser and WebGL support will be off. But if WebGL is enabled and your drivers are stable, will work fine.
On Android, only the users that install Chrome besides the native browser, have very up to date version of Android and a device that isn't blacklisted can see WebGL.
WP is still not there.
Most casual users don't install third party browsers like FF.
Why bother with WebGL on mobile, when native allows for using the handset resources properly, not drain battery and have a bigger deployment target?
Asm.js needs fewer demos and more finished production applications. Apparently Epic isn't excited enough about this technology to release one of their games on the web.
Being ready for games doesn't mean games will come, just as U3 games haven't come (except for the one that hasn't shipped yet). Would be nice if Epic shipped one of their games; why haven't they?
Doesn't matter who ships, as long as it can be done without reasonable tradeoffs. The nature of the Web as we know it gives so many benefits in form of e.g. ease of deployment that it'd be outright wonder that there wouldn't soon be a rush of games exploiting the platform.
They say "without plugins" but that's kind of misleading. Firefox includes asm.js functionality, but no other browser does. Just because it's included by default doesn't mean it's not a plugin. Chrome includes Flash by default, it's still a plugin.
I would not say "slowly" - that sounds like it is objectively sluggish for the user, which is not the case. Try the Epic Citadel demo in chrome - works great.
Depends on the benchmark, on many Chrome has already caught up, on others perhaps not. But there is constant improvement here.
Epic Games and Mozilla are demonstrating how the Web is continuing to evolve as a powerful platform [..]
And you're still using a youtube embed because a single, simple tag like <video> is too effin' problematic.
Yeah yeah, I get it. <video> isn't relevant to gaming. WebGL and gaming are cool new stuff, <video> is prehistoric crap nobody cares about anymore. The world has moved on.
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.