Mozilla and Epic Preview Unreal Engine 4 Running in Firefox
blog.mozilla.org
blog.mozilla.org
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.
These tech demos are about pushing the envelope, which is needed to make the web a better platform for high-end games.
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.
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.
asm.js executes according to the ECMA-262 semantics, which are the full dynamic semantics of JavaScript.
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.
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.
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 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.)
Not big issues, I think. The big issue is having a robust ecosystem for all the things like networking, input handling, sound and video.
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.
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.
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.
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 stay where I am.
Thanks for the great job!
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...
I think most people do remember WebOS.
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.
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.
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 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.
* arrangement bugs are already worked on the way I saw it
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.
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.
EDIT: Could WhatsApp be the 2nd coming of WAP?
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.
And I don't own a windows machine.
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.
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.
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.
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.
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.
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.
Now, the Unreal Engine is a great tool in and of itself. Having it target the browser is the questionable part to me.
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.
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.
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.
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.
I agree tools are important too, but the main benefit of the web is it is runs everywhere, and no one controls it.
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.
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.
Note also that this is on the CPU. On the GPU, WebGL is already extremely close to native GPU speed.
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 execution time for a fixed, deterministic non-stop workload is the best thing in my opinion.
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.
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.
You're kidding, right? (Maybe not old enough to remember the world pre-Google?)
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, 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.)
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.
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.
What is asm.js (and WebGL, for that matter) if not that?
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).
Unfortunately, what is needed is LESS people participating.
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.
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.
How is it limited?
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.
You may want to actually inform yourself.
WebGL 2.0 has many of the extensions and is in Editor's Draft status: http://www.khronos.org/registry/webgl/specs/latest/2.0/ It has a prototype implementation already: https://wiki.mozilla.org/Platform/GFX/WebGL2
> 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.
asm.js has 32-bit floats already: https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-nat...
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. :(
We are in agreement.
People have every right to be annoyed because the people who were entrusted with the concept of the web implemented it very badly.
Again, no disagreement. But in the meantime, implementing things is still my preferred activity to complaining.
Windows. The market has spoken. Let's just all be smart enough to not be defeated by the marketing to stupids.
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.
you're welcome :)
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"?
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.
WebGL works on mobile devices, not all browsers have caught up yet, but there is progress.
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?
But, beta versions of browsers on the same devices show good performance. I think it's just a matter of time.
But again, right now, of course native on mobile is the way to go.
Until WebGL is properly supported on mobiles it is just a toy and native is the way to go.
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.
http://en.wikipedia.org/wiki/List_of_Unreal_Engine_games#Unr...
That's the purpose of this demo: to show that the Web stack is ready even for upcoming AAA games, not just ones from a few years ago.
Depends on the benchmark, on many Chrome has already caught up, on others perhaps not. But there is constant improvement here.
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.
P.S.: YouTube uses their HTML5 player wherever possible.