Emscripten and New Javascript Engine Bring Unreal Engine To Firefox 124
MojoKid writes "There's no doubt that gaming on the Web has improved dramatically in recent years, but Mozilla believes it has developed new technology that will deliver a big leap in what browser-based gaming can become. The company developed a highly-optimized version of Javascript that's designed to 'supercharge' a game's code to deliver near-native performance. And now that innovation has enabled Mozilla to bring Epic's Unreal Engine 3 to the browser. As a sort of proof of concept, Mozilla debuted this BananaBread game demo that was built using WebGL, Emscripten, and the new JavaScript version called 'asm.js.' Mozilla says that it's working with the likes of EA, Disney, and ZeptoLab to optimize games for the mobile Web, as well."
Emscripten was previously used to port Doom to the browser.
Javascript engine evolution (Score:2)
What's the average lifetime of a Javascript engine in Firefox?
Are they all forks of each others?
I like it.
Re: (Score:3)
What's the average lifetime of a Javascript engine in Firefox? Are they all forks of each others? I like it.
I think it's obvious what the Mozilla folks are trying to do: They're attempting to recreate the collected works of William Shakespeare using genetic algorithms. Four monkeys done, an infinite number of monkeys to go...
Comment removed (Score:4, Insightful)
Re:Javascript engine evolution (Score:5, Interesting)
I suspect the security concerns about WebGL are overblown. The code that runs on the GPU are vertex and fragment shaders. The shader language is very limited and exposes only a small surface between the host and the GPU. You can load/compile shader code, assign uniforms/attributes, share frame buffers and textures and that's about it. It's not as though the coder gets unfettered access to the entire DirectX stack.
Both firefox and chrome sanitize shader code so shaders can't play with whatever unsafe features some GPU might implement. One strength of WebGL (and OpenGL ES that's it's based on) is that the fixed function OpenGL API is gone; everything is done with shaders. That means the huge user-land fixed function API is gone and you're left with a simple API that just loads shader code and data (vectors, textures etc.) So the user-land attack surface is relatively small.
Vulnerabilities have been found in individual drivers but they've been few and fixed quickly. WebGL exploits are highly unlikely to be portable; they'll attack certain versions of GPU+drivers on certain OSs... broadly successful exploits won't be feasible.
Re: (Score:2, Insightful)
Re: (Score:1)
we still haven't solved the problem of how to run net code on CPUs without getting malware
And yet we continue to run "net code" despite this. The value of that code is apparently greater than the the risk of using systems that permit it to run.
When a killer 3D web application appears it will be the same; we'll run it, risking exploitation, and the vendors will harden their products.
We're integrating GPUs onto CPUs such that it's getting difficult to buy a CPU without one and we're writing GP-GPU frameworks to exploit these powerful devices. There is exactly zero possibility these capabilities
Re: (Score:1)
Re: (Score:2, Interesting)
I suspect the security concerns about WebGL are overblown. The code that runs on the GPU are vertex and fragment shaders.
And that's enough. I went to an opengl class where we would write vertex/fragment shaders. You know what? Most of the times I locked my machine was because I carelessly wrote an infinite loop. The code runs at the GPU so everything comes to a standstill, it seems macosx at least is unable to interrupt badly behaved GPU code.
So at least you can trigger a DOS attack. And I'm sure you can d
Re:Javascript engine evolution (Score:5, Informative)
Ah, my mistake. "use asm" is a proposed Javascript feature:
http://asmjs.org/spec/latest/ [asmjs.org]
Also interesting:
http://www.i-programmer.info/news/167-javascript/5694-firefox-runs-javascript-games-at-native-speed.html [i-programmer.info]
Chrome (Score:5, Informative)
Re: (Score:2)
Their idea was Javascript without strong typing will never be as fast or close to C.
When WebGL was added to the browser, they added some strong types for storing all the graphics data.
So the developers at Mozilla figured out they can leverage those strong types when doing CPU-intense operations and optimize the Javascript engine to take advantage of that. Then they figured out you can use a compiler to target those strong types and recompile existing C-code that way.
So that is what is going on.
Interesting. (Score:3)
The unreal Engine is quite the powerhouse, running games like Bioshock and Tribes. This could be a web based game changer... (Pun intended).
-DW
Re: (Score:3)
Mix this up with the decentralised P2P browsers thing and I present to you, ladies and gentlemen, the future!
I can't see anywhere to stick the meter though.
Re: (Score:1)
Finally, a real Metaverse!
Re: (Score:3)
Perhaps, but what's the application for something like this? The biggest one I can think of is cross-platform compatibility, since if you built something to run in the browser, it'd instantly work in Windows, Mac, and Linux. Assuming such a thing was possible, I doubt it'd be long before someone essentially used WebKit, Gecko, or whatever else to create a wrapper that could be applied to games using UE3, effectively creating a universal executable that would be little more than a chrome-less browser, somewh
Re: (Score:2)
Perhaps, but what's the application for something like this?
Turning WildTangent into a smoking hole in the ground, and about time, too.
Re: (Score:2)
Since they are claiming the javascript is running like it is native code they should show something more impressive
Re: (Score:1)
Actually the CPU-performance of Javscript is about twice as slow as a C-program. So "only" 18 months behind according to moore's law.
The GPU-performance might be even better then twice because they use WebGL to tell the GPU what to do.
Not at all, Features hit users faster (Score:3)
To the average Slashdot user, it is apparent that Firefox fans who are turned off by frequent browser updates
I'm sorry, as a [I like to think better ;)] than average Slashdot User...or at least not an AC. I have to say Users love the silent background updating of Mozilla, [Business Users less so], as it allows large features to hit users sooner [I'm loving the new PDF reader]. In fact most users here prefer *release often* strategy its part of their culture [it is mine]. Hell my whole OS gets updated every six months, perhaps you live on a stagnant platform, with occasional releases [read years apart].
Re: (Score:2)
I believe the comment you refered to from a Firefox developer was from one of the developers that helped solve the problems.
AKA it has already been solved.
"new JavaScript version called 'asm.js.'" (Score:5, Insightful)
Re: (Score:2)
What what is to what, now?
It could be me, but I'm not sure your analogies are helping!
Remember the good old days? (Score:2, Insightful)
When "browsers" were used for "browsing" the web, instead of being crappy application platforms with endless non-browsing-related features shoehorned into them? What happened to just browsing well instead of doing everything else poorly?
Re:Remember the good old days? (Score:5, Informative)
What happened to seeing a grid of 80x25 characters on a black background? Progress.
Re: (Score:3, Interesting)
Yeah, now instead of just floppies as a virus transmission medium, they're really write-once run everywhere.
No more customizing ASM for elf/win32. Better yet, because it's delivered over HTTP in a browser that's already authenticated to a proxy server if there is one, we have an instant authenticated outbound tunnel which can utilize json-p to establish a backchannel as long as the browser is open to any other HTTP service!
But best of all, the new and improved technology ships in with built-in advertising
Re: (Score:2)
You realize that all the complaints you have were also true in the good old days of IE3 and NS3? Since then, lots have changed, but all that has changed is irrelevant to all of your points.
Re: (Score:1)
Barely. I don't think I actually recall IE3, although I do recall IE4, and I have a copy of NS2 on a cd somewhere...
Webpages weren't using DHTML & Ajax, and nobody would have tried to deliver a damned game in the browser.
Even a crappy app would've at least been done in VB.
All this is is the same old damned problems returning unsolved, and with less performance than native apps.
The same AC stands by his original opinion, and agrees:
"All that has changed is irrelevant to your [my] points"
The web and brow
Re: (Score:2)
You must have forgotten VRML and ActiveX.
Re: (Score:2)
If it lets me do more than I could do ten years ago, that's progress by any meaningful definition of the word.
Re: (Score:2)
I think his point was that the improved UX and hardware let you do more, which is called progress.
But having it run wholly inside a web browser, instead of a native GUI that has optional (clearly interfaced) internet storage support but can be controlled by my own firewall... this does not really enable you to do more (but it enables "them" to do more, e.g. built-in app obsolescence via DRM, profiling via tracking, etc.) and therefore is not progress.
Re:Remember the good old days? (Score:5, Insightful)
"them" could be anyone, including you. Spinning up Apache is something any beginner developer can work through. Or even better, just pay 3$ a month for a place to host your stuff. Now you are one of "them". I understand your argument but it's like saying we shouldn't use wikipedia because they could nuke the website tomorrow to spite us. I don't want to go back to Encarta on a CD.
Re: (Score:2)
Hmm, you're placing me inside "them" because I stated it's progress for "them". If we're talking about service providers in general (i.e. my local apache server), there are two points I'd like to highlight:
1. This enables "all of them", not just "the part of them that is me". When it comes to my security, I prefer the exclusive approach.
2. The typical situation is that you're not really a part of "them". "Them" is for example G+/Facebook, and you can try to play along and run a Diaspora node, but... well, w
Re: (Score:2)
This sounds like Grace Hoppers rant about hanging 1K feet of optical cable (speed of light @ 1 microsecond) around the necks of programmers that wasted microseconds of compute time.
Computing requires exponential gains so that we can compute additional layers of abstraction. It makes it possible to program what we do. The reason usability has gotten better is because we don't need to write hand-tuned machine code just to get UI widgets working.
And do not tell me that the IT department are that much better
Re: (Score:2)
Oh, and please think back to security in the old days of paper checks and manual accounting. It's much hard to forge an SSL cert than it is to fake a doctors prescription.
Re: (Score:2)
They couldn't shove in enough unwanted advertisements with 80x25 on black background.
Re: (Score:2)
The terminal is still incredibly useful. In fact, things that might take ten minutes to do via a GUI takes maybe half a minute, if that much. This doesn't sound like much, until you start repeating the things you do (like constantly toggling an option). This is why keyboard shortcuts on a GUI are't going anywhere. Besides which, don't forget that every text editor is pretty much a neutered terminal window with color.
Progress does not mean the next new thing, it means the next better thing.
Now, I'm not sure
Re: (Score:1)
Microsoft killed it by not following the Posix standard, making cross platform application development a royal pain in the ass.
HTML/CSS/Javascript is the only platform agnostic platform.
Alas, its all we got.
Re:Remember the good old days? (Score:4, Insightful)
This. The web is popular because it's a simple way to deploy something that works across different OSes and different devices. On the users' part, no installation isrequired, and web apps are safely sandboxed. The web is thriving because of the shortcomings of native platforms.
Re: (Score:2)
HTTP/2.0 will be mostly based on SPDY. That is what the 'wait' is all about. There will be no SPDY RFC, there are just drafts.
Basically SPDY is the testing ground for HTTP/2.0.
HTTP/2.0 will most likely only use TLS.
Re: (Score:2)
Yeah, how does that gibe with the fact that the source code was apparently released to the public under the GPL in 1999?
http://en.wikipedia.org/wiki/Doom_source_ports [wikipedia.org]
If its GPLed can someone still claim IP rights to the code? or does it mean the code itself but not the content is released to the public?
Re: (Score:2)
all the code is open source, the textures and levels and other game content were not.
Re: (Score:2)
If its GPLed can someone still claim IP rights to the code?
Yes. Putting something under the GPL does not relinquish your rights to that code.
Not me (Score:2, Insightful)
I for one won't ever buy any games that run in the cloud and/or you have to play through a browser.
Re:Not me (Score:5, Insightful)
That's fine. Plenty of people are doing it already. So nobody that matters really cares what you think.
Re: (Score:2)
wow you being a dick was totally uncalled for.
Re: (Score:2)
Re: (Score:2)
The main reason why is that I dont want to have a dependency on the internet.
Partly its about just not wanting to have to be connected to play. What if I want to play where there is no internet, such as on an airplane or while camping etc. Also now you are subject to issues like available bandwidth, latency etc.
Also if the game is running in the cloud, it means I relinquish all control about what they do with the game, i.e. direction they take it in with patches etc,
Also with a local copy I am insulated if
Re: (Score:2)
Also.. as for running in a brower, its another layer of abstraction that can be avoided by running a local app.
Compared to running a native binary, running through a browser can't help but to cost something extra in terms of computer resources, so ultimately cant help but to impact gaming performance at some level.
The inconvenience of having to go through a browser (a window in a window, browser toolbar etc ) is also enough to put me off.
Re: (Score:2)
Hot Dog! (Score:2)
Re:Hot Dog! (Score:4, Funny)
Javascript is to Java as a smart person is to you.
Re: (Score:3)
Re: (Score:2)
They do. It's called "trollbait" and all of the "smart" people who are so quick to correct it fall for it every time.
PNaCl (Score:2)
PNaCl compiles LLVM bitcode to native code
asm.js uses code generated with Emscripten from
Devs can easily target both platforms. If somebody ports the Pepper API to asm.js, converting a PNaCl application to asm.js can be an automated task.
Re: (Score:2)
asm.js JavaScript subset runs on the same VM, only one VM to secure, it can access DOM APIs directly. NaCl is just another VM like technology, more the p variant that uses an intermediary bytecode, with new APIs made for it, it is a new kind of Java or Flash plugin, probably a lot more secure but a plugin like technology nonetheless
Re: (Score:2)
Porting Pepper is a huge undertaking, comparable to reimplementing large parts of a web browser from scratch. Oh, and without real specs, so you have to do a bunch of reverse-engineering.
Re: (Score:1)
asm.js is just normal javascript with some backwards-compatible notations. Therefore it will run (more slowly) on any browser, including IE.
for example: "var i = 10 | 0;" informs the runtime you want an integer instead of a normal javascript floating-point number.
As of right now, Nacl is a google-proprietary thing and isn't even enabled in Chrome yet.
Doom Mozilla and DMCA Notice (Score:2)
The link below offers an unauthorized derivation or version of Id Software's DOOM game". link [mozilla.org]
Re: (Score:2)
"near-native performance"? (Score:3, Insightful)
It says that it's twice as slow as native c code. This must be a new definition of the word "near".
Re: (Score:2, Insightful)
In the computing world that's close enough that noone really cares. With a traditional interpreted language (like javascript interpreters used to be) you're looking at something more in the range of 100-10000x slowdown.
Re: (Score:2)
That's simple not true. There are parts of a graphic engine that are quite slow, even in c (like fustrum culling). If you implement those algorithms in a language that is twice as slow you will have problems
RMS is right, we must demand free javascript (Score:3)
The distinction between installed-software and software that's being run from your browser cache is becoming subtle.
RMS's views on the problem: The JavaScript Trap
https://www.gnu.org/philosophy/javascript-trap.en.html [gnu.org]
A solution: The LibreJS plugin for IceCat, Firefox etc. disables javascript if it is non-trivial and doesn't have a notice about using a free software licence:
https://www.gnu.org/software/librejs/ [gnu.org]
("trivial" is defined as "defines functions")
Re: (Score:2)
It's code, code is programs people use. And the goal of RMS is for people to be able to have control over the programs they use.
Re:WHY?!? (Score:4, Informative)
Why? Because you're in a browser right now and it's the most popular software platform ever.
https://wiki.mozilla.org/GamepadAPI [mozilla.org]
No it isn't.
WebGL sends shader programs to the GPU which executes them. There isn't a layer underneath it.
People had no interest in such world browsers, several companies including Microsoft offered them in the 90s and they all died. Microsoft's 1997 technology was called Chrome (yes, really), and they promised "Chromeffects [wikipedia.org] would turn a web browser into a rippling, 3D space with audio and video playback".
Meanwhile people do like 3D games, they do love running things in their browser, and the fullscreen API [davidwalsh.name] lets the game canvas go fullscreen. Enjoy your lawn.
Google is interested in asm.js (Score:2, Informative)
"At least some at Google [cnet.com] want to embrace a Mozilla-backed project to speed up Web apps written with JavaScript -- even though it competes directly with Google's own Native Client and Dart programming technology. "
Re: (Score:2)
Mod AC parent up! Here it is again
Asm.js being used to tune Firefox's JS engine (Score:2)
Perhaps equally exciting to me is that asm is going to be used to speed up Firefox's Ionmonkey JIT.
Devs will compile asm code and compare it to native to find inefficiencies, thereby learning where to optimize the compiler.
So even if you don't use asm.js, we all get faster Javascript.
WTF? Link now goes to takedown notice? (Score:2)
https://wiki.mozilla.org/Legal/Infringement_Notices/3_June_2011 [mozilla.org]
So, that's it then...
Soccer Team Uniforms (Score:1)
Re: (Score:3, Insightful)
A lot of plugins are only built for 32-bit browsers. It is a lot more work to get 32-bit plugins working in a 64-bit browser than in a 32-bit browser. Plus, there is no real advantage to using a 64-bit browser unless you want it to use more than 2gb of memory, and I thought one of the common complaints was that Firefox uses too much memory?
I'm not sure what you think the big deal is.
Re:I don't care (Score:4, Informative)
Re:I don't care (Score:5, Informative)
64-bit browsers are inherently more secure, and can access more memory. Native 64-bit apps also run faster. You're trying to call someone an idiot without realizing that you don't know what you're talking about in claiming there are no advantages.
http://arstechnica.com/information-technology/2012/11/64-bit-firefox-for-windows-should-be-prioritized-not-suspended/ [arstechnica.com]
Re: (Score:2)
I'm calling OP an idiot because not for his position, but for his delivery.
Re:I don't care (Score:4, Informative)
Firefox these days uses less memory than Chrome.
http://www.ghacks.net/2012/06/21/chrome-uses-way-more-memory-than-firefox-opera-or-internet-explorer/ [ghacks.net]
Mind you, Chrome is still my everyday browser, but Firefox has gotten really good at being efficient with memory.
Re: (Score:3)
No, x86 is clearly bigger and better than x64!
Re: (Score:2)
64-bit gives better security (Score:5, Informative)
Plus, there is no real advantage to using a 64-bit browser unless you want it to use more than 2gb of memory
ASLR (Address Space Layout Randomization) is far more effective in a 64-bit address space than in a 32-bit address space. Browsers need all the layers of protection they can get from exploits.
On the other hand, WebGL gives any website in the world nearly direct access to exploit bugs in GPU drivers, significantly increasing the attack surface of the browser. I say nearly, because the browser does check all parameters for possible buffer overflow conditions before passing them onto OpenGL calls, but any other type of exploit is still possible.
I would definitely prefer that Firefox prioritize features that increase security over those that decrease it.
Re: (Score:2)
> WebGL gives any website in the world nearly direct access to exploit bugs in GPU drivers, significantly increasing the attack surface of the browser.
You are stating overblown past issues with zero evidence about future possible ones.
Exactly _how_ many bugs and exploits in WebGL has there been? Aside from _THREE_ issues about:
1. CORS / Cross-domain textures (fixed),
2. GPU VRAM reading using as WebGL texture (OSX only!), and
3. DoS
I am not aware of any other code "exploiting bugs in the GPU drivers". Fr
Re: (Score:3)
Adobe had a 64-bit version of Flash.
There is a 64-bit version of Java.
There is a 64-bit version of Silverlight.
What plugin is exactly stopping Firefox from making a 64-bit browser build? They started the 64-bit build project in 2003. Ten years later they apparently struggle to figure it out, even though community members roll their own 64-bit builds all the time.
Re: (Score:2)
I'm sure they can supply you a list of some examples if you ask them nicely.
Re: (Score:2)
Except that if you're running a 64-bit OS, odds are most or all of the 64-bit library code is already loaded into RAM, but when you launch the first 32-bit app, the opera
Re:I don't care (Score:5, Insightful)
I've ued 64bit builds of nightly for some time now.
The issue is getting plugins to play nice.
You can't really blame Mozilla for not wanting to jump the shark, when they will catch all the flames for plugin makers who refuse to make their plugins 64bit friendly.
Right now, it's "whaaaaaa! I want 64bit builds!"
They offer a 64bit build, and then its "whaaaa! Flash plugin doesn't work! Noscript doesn't work! Adblock Plus doesn't work! Its horrible, and it crashes to boot!"
The market has to build up enough pressure to push out the colonic obstructions in the way of 64bit adoption as the new standard. It will take awhile.
Re: (Score:2)
Flash, Noscript and Adblock have been available in 64bit browsers for "ages".
I've been using Firefox exclusively compiled to 64bit for 3-4 years now (the default in the Debian sid repo) and never had came across incompatible plugin after they released Flash for 64bit. Though... I need only around 15 plugins, so heavier user may have a legitimate reason to use a 32bit browser.
Could you point out some of the plugins that actually don't support a 64bit binary? Windows is 64bit per default now too, isn't it...
WTF? (Score:1)
Flash works. No Script works. Adblock Plus works.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:22.0) Gecko/20130329 Firefox/22.0 ID:20130329030904 CSet: 8693d1d4c86d
Now, if you want to crash 64-bit Nightly, this is the way to do it.
http://deshommesetdeschatons.tumblr.com/ [tumblr.com]
Keep scrolling. And it's nice that the crash reports are null and invalid.
Re: (Score:2)