
Mozilla and Epic Announce Unreal Engine for the Web - metajack
https://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlocking-the-power-of-the-web-as-a-platform-for-gaming/
======
jlongster
For everyone saying that the claim that asm.js runs everywhere is invalid,
because only in browsers that implement the optimization will it be feasible,
remember that most games are built to scale performance. On browsers that
don't implement the asm.js optimizations, the game could feasibly turn off
visual effects and scale down the game so that it runs, just not as pretty or
realistic.

There's a huge difference between "this game only runs in this one browser
that implements this full VM" and "this games runs everywhere, but only with
maximum graphics & physics in browsers that implement the asm.js
optimizations".

~~~
niggler
'There's a huge difference between "this game only runs in this one browser
that implements this full VM" and "this games runs everywhere, but only with
maximum graphics & physics in browsers that implement the asm.js
optimizations".'

That's quite a bit of marketing here.

If NaCl is capable of reaching 1.1x performance while asm.js is at 2x (and
it's not obvious to me within the confines of JS if you can actually do better
than 1.5x), people would switch to a browser that supports NaCl (first the
hardcore gamers, then the rest of us). Your argument only makes sense if
asm.js and NaCl are at performance parity.

Note that people still write native iOS games, even though they could run
everywhere if they did it in JS.

~~~
pcwalton
> If NaCl is capable of reaching 1.1x performance while asm.js is at 2x (and
> it's not obvious to me within the confines of JS if you can actually do
> better than 1.5x), people would switch to a browser that supports NaCl
> (first the hardcore gamers, then the rest of us).

NaCl is not portable. asm.js is. You should compare PNaCl and asm.js.

> and it's not obvious to me within the confines of JS if you can actually do
> better than 1.5x

Why not? Is there a technical reason?

~~~
pifflesnort
> _NaCl is not portable. asm.js is. You should compare PNaCl and asm.js._

NaCL covers the only architectures that are likely to matter for phones and
desktops for the next 5+ years: ARM and x86. In doing so, it can support NEON,
SSE, and other architecture-specific hardware features that make substantial
differences in performance.

So why shouldn't you compare NaCL to asm.js?

PNaCL is there to cover the case where we move past ARM and x86, in which case
it provides the ability to target new architectures from existing deployed
code. In an ideal universe, sites would serve fat x86/arm/pnacl binaries,
optimized for a given client.

~~~
dragonwriter
> NaCL covers the only architectures that are likely to matter for phones and
> desktops for the next 5+ years: ARM and x86.

This is misleading. NaCl exists for both these platforms, but it doesn't
support running the same code on each; NaCl lets you run native x86-compiled
code on x86 and native ARM-compiled code on ARM.

> PNaCL is there to cover the case where we move past ARM and x86

That, too, but more importantly, it exists to let you run the same code
(delivered as LLVM bitcode) on supported platforms, including x86 and ARM,
instead of having to deliver separately-compiled code for each supported
platform, as is the case for NaCl. That's what the "P" ("Portable") is about
-- the code delivered runs on any PNaCl engine, unlike the case with NaCl
where NaCl x86 code runs only on x86 and NaCl ARM code only on ARM.

You seem to have confused what PNaCl does now (experimental toolchain inside
the NaCl SDK), and what the point of PNaCl is (to move the .pexe -> .nexe
bitcode to native code piece of the toolchain from the SDK side into the
client side, so all you deliver to the client is the platform-agnosti .pexe
rather than the platform-specific .nexe.)

~~~
pifflesnort
> _This is misleading. NaCl exists for both these platforms, but it doesn't
> support running the same code on each; NaCl lets you run native x86-compiled
> code on x86 and native ARM-compiled code on ARM._

I didn't intend for this to be misleading -- the option to deploy code
specific to each architecture is a _benefit_.

It means you can take advantage of the architecture's specific features (such
as NEON and SSE).

~~~
dragonwriter
> I didn't intend for this to be misleading -- running code specific to each
> architecture is a benefit.

 _Permitting_ it may be a benefit in some cases,

 _Being limited to_ it, as NaCl is until client-side PNaCl is ready, is a
disadvantage.

Which is why Google is not enabling NaCl by default on the web (i.e., outside
of the Chrome Web Store) until client-side PNaCl is ready -- they don't want
needless proliferation of non-portable NaCl code on the web. And, I suspect,
they want to make the .pexe-to-.nexe process as efficient, in terms of code
generation, as possible, so as to minimize the scope of cases where specific-
platform-targetting is necessary.

------
daenz
I feel like an old fart for not buying into the push for the browser to be an
OS or game system.

In my mind, no matter how optimized the browser becomes, it will always be
slower than natively-compiled code. And in the 3d gaming world, where the
faster code always has the greatest potential for the best game engines, the
browser will always lose.

My instinct tells me that there will be a huge push for webgl games, some
initial adoption and frameworks, etc. The result will be that web developers
will realize how fucking complex graphics engines are (I'm writing one
now...nothing in webdev compares to it) and will give up. And I can't see
graphics developers in the game industry incentivized enough to fully make the
jump to the browser (why would they want to write game code that is
distributed to everyone in raw source form?)

~~~
TillE
I expect most serious developers will stick with engines like Unity, which let
you run games in a browser with a plugin, but also compile and distribute them
in standard ways on every popular desktop and mobile platform.

Unity Web Player is easy to install, and it's an increasingly common
requirement for a lot of games. It's a barrier, but only a small one.

~~~
macspoofing
>I expect most serious developers will stick with engines like Unity

They should stick with engines and frameworks like Unity. Coding raw JS and
WebGL is ugly. But there's no reason why Unity cannot compile down to
something like asm.js and webGL. In fact, I believe Unity already lets you
compile to a swf, which gives you great performance and doesn't require any
extra plugins (besides Flash).

>Unity Web Player is easy to install, and it's an increasingly common
requirement for a lot of games. It's a barrier, but only a small one.

It's an insurmountable barrier.

~~~
bilbo0s
"...It's an insurmountable barrier..."

Why do you say so? Why is it a small barrier or an insurmountable barrier?

Genuinely interested in the answers there.

Just seems to me that there are a lot of Flash games, Unity games and Java
games. I mean, if Minecraft or BSG Online is any indication... technology
doesn't really stop your average gamer. But maybe I'm wrong???

~~~
kayoone
I have developed a couple of unity based browsergames and i can Tell from
experience that you loose a sibstantial amount of users at the plugin
installation, especially for games that target a more casual market. Unity
compiling to asm.js would be huge!

------
cromwellian
(on Scaling) Games usually scaled based on GPU power, but not so much on the
core game logic, AI, etc. Any CPU processing that actually affects gameplay
outcome (e.g. collision detection) cannot really be disabled and scaled.
Otherwise, you end up playing a _different game_ based on your machine, not a
game that only looks uglier or plays choppy.

This demo looks great, but all I see are environments rendered. I didn't see
any firefights between lots of player models or vehicles, no
Havok/PhysX/Bullet, I didn't see any enemy AI running. I did see some frame
rate hitching. It's not the first time someone's had environments (sans game)
running, see for example Quake3 (<http://media.tojicode.com/q3bsp/>). Even the
Rage Engine got an environment renderer ported to the Web.

There's a danger in overselling stuff. When I helped port Quake2 to the Web
(GwtQuake), I didn't have any illusions about being able to run something like
Crysis or Call of Duty series in the the browser in JS, or consume the same
resource requirements. I mean, I thought it would be possible, but a hideous
waste of system resources.

There was a time when Sun was marketing Java and pushing heavily on this idea
that it would one day meet or beat C/C++ performance, but it never quite got
there after 2 decades (yes, in some circumstances it comes close, in others,
it fairs badly). I see the same parallels today, pushing the idea that a
dynamically typed language with some extra 'hints' is going to match a
language that gives full control over memory, SIMD, layout, threading, etc.

This is not to say that asm.js couldn't do most of the 'casual' games you see
today (e.g. Ridiculous Fishing on iOS, Angry Birds, etc), and most of the
Flash games, I'm totally onboard with using it for that, but I think it's a
mistake to push this as a real solution for bringing triple-A FPSes to the
web.

And what of Mobile? Can this even run Infinity Blade on a recent smartphone?
What would be the different in battery life between an iOS version and an
asm.js version?

~~~
pcwalton
> It's not the first time someone's had environments (sans game) running, see
> for example Quake3 (<http://media.tojicode.com/q3bsp/>).

Quake 3 was released in 1999. Unreal Engine 3 is a current and top-of-the-line
engine for AAA games.

> There was a time when Sun was marketing Java and pushing heavily on this
> idea that it would one day meet or beat C/C++ performance, but it never
> quite got there after 2 decades (yes, in some circumstances it comes close,
> in others, it fairs badly).

This is totally different. asm.js is just a backwards compatible encoding of a
different, much lower-level language. In fact, that lower-level language is in
direct correspondence with the intermediate representation of a production-
quality C++ compiler (clang)!

Sun never tried something like asm.js for Java; rather they claimed that the
_full language_ would be as fast as C and C++.

> memory, SIMD, layout, threading

asm.js gives full control over memory and full control over layout, with the
exception of stuff like mmap() and mprotect() and self-modifying code.

SIMD is something that RiverTrail/ParallelArray can do. It should be added to
asm.js.

As for threading, I'm personally in favor of an extension to allow a typed
array to be shared between workers, races and all, with some primitives to
allow synchronization. Not everybody is OK with this, but I personally believe
we aren't likely to get to native performance without it. (Again, this is just
my personal opinion; many disagree on whether a racy typed array is
necessary.)

~~~
cromwellian
You can polyfill SIMD, but you can't polyfill threads. Once you add shared
memory between workers, you've effectively violated the premise that asm.js
will run everywhere, even places that don't understand it.

In that case, you've got a portable intermediate representation of opcodes in
a bloated legacy format, that is now incompatible with legacy runtimes. Why
use JS format then?

~~~
pcwalton
Apps could feature detect threading and fall back to single-threaded mode for
compatibility with non-asm browsers if it's not supported.

Regarding the claim that asm.js is "bloated":
[http://mozakai.blogspot.com/2011/11/code-size-when-
compiling...](http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-
javascript.html)

------
teelo2
This is huge! I do PR in the gaming industry and have been waiting a long time
to see a platform that could bring serious game development to the browser. I
was expecting it to be Unity, but I'm convinced this is a bigger milestone.
Epic is an awesome company with awesome tech and partnering directly with
Mozilla is a stroke of genius.

Can't wait to see the games that will come out of this marriage.

~~~
anoncow
Native-like games in browsers with little or no use of plugins may be game-
changing for the game industry.

~~~
pekk
Given the size of game assets these days, that could be a big UX problem

(in places which don't have Google Fiber)

~~~
michael_miller
Presumably, game developers would serve up the game to the browser via
localStorage. This would make the experience very similar to Steam today,
where you download the game, then play it.

~~~
alttab
You could even design the game to be downloaded in chunks. Download the first
level, and while playing, download the second in the background. This reduces
downloads and load times.

------
starmole
Disclaimer: I worked on the original Flash version of this same demo two years
ago.

Big congratulations to Mozilla for pulling this off. Feels good to have such a
great demo, doesn't it? :) But a lot of the credit also needs to go to Epic
for having such an amazingly scalable and portable engine and providing the
AAA assets!

One issue is that the game experience does not translate as easily as the wow
factor. You will need quite a bit more to go to the first shipping and
profitable game built with this tech. Don't rest now :) With Flash + 3D we
actually ended up seeing the most successful games not being based on straight
native ports but built from scratch with the new environment in mind. Things
like caching, startup time, and wide reach are crucial to an in browser game
but are not needed for a demo like this.

Still really amazing! Keep up the good work and the fight for the open web!

------
AndrewDucker
I was wondering what the end goal of asm.js was - and the ability to run games
in your browser at near-desktop speeds is _very_ impressive.

Now, how long until Chrome supports it...

~~~
GotNothing
As soon as they find a way to put ads in it...

~~~
lucian1900
Chrome has supported NaCl for a long time, which is quite a bit saner than
asm.js

~~~
hosay123
You show up on every NaCl-related thread claiming it is awesome and asm.js is
crap, but that's as far as it goes - you never explain _why_. You're basically
wasting time because what you say is never actionable. Please defend your
opinions - inform us!

~~~
lucian1900
(P)NaCl exposes pretty much the same environment and tool chain devs get
writing native apps. Predictable performance, decent debugging, etc. One can
even decide to use platform-specific features if strictly necessary.

The problem it has is that it is largely opaque to the JITs in browser engines
(even PNaCl, since JS JITs have nothing to do with llvm). One way to fix that
would be to define a simple byte code as a compilation target and have people
compile to that, in addition to compilation to JS with emacripten. The end
result would be, in my opinion, much cleaner than the ugly hacks in asm.js

Furthermore, by design, asm.js will always need guards in the generated code,
thus some overhead that can never be fully removed (although JITs will help
with this). In particular, one can write "x = +x" in JS, but then change the
type of x, thus invalidating the invariant. A guard will be needed to
guarantee correctness, since asm.js is a subset of JS, but the outer set still
exists.

It seems to me that web technologies are getting more and more crazy. To me it
appeared obvious that asm.js is not a nice approach, but I can see many people
disagree.

~~~
BrendanEich
You are mistaken, there are no type guards within asm.js-
verified/compiled/linked code. Read more at <http://asmjs.org/>.

/be

------
Sprint
Unreal? Bah, real gamers play Quake! (As in 199Xs flame wars.)

<https://github.com/SiPlus/WebQuake> was released some weeks ago. It is a
whole different league in terms of technological features but it is a free
open-source engine. You can play it at <http://webquake.quaddicted.com/>

There is also a port of Sauerbraten, another free engine,
<https://developer.mozilla.org/en-US/demos/detail/bananabread>

------
ilaksh
The thing that I think people are getting confused about is, even though
asm.js is faster, you actually don't need asm.js to get native code running
the browser. The new engines in Chrome and Firefox already compile to native
code.

Asm.js is just a way to ensure that your code always get optimized as much as
possible.

I really don't think that asm.js is necessary to bring 3d gaming to the web.
WebGL performs very well as long as you take advantage of the graphics
hardware. I'm not a fan of asm.js actually, since if I wanted to write low-
level code I would just stick with C++. I'm on the web to take advantage of
things like JavaScript and CoffeeScript.

I think the way to get to the sweet spot for 3d gaming and applications in the
browser is to 1) make sure that WebGL is well supported on as many platforms
as possible and 2) take advantage of the built-in networking, instant-on
factor, openness, general webiness, and scripting capabilities of the web
platform. By 'instant-on factor' I mean that games can load up very quickly
after hitting a URL. By 'general webiness' I mean, for example, you can start
a game at the end of the work day, later the evening continue from your house
-- you aren't tied to a particular machine. Also the web has all of the HTML5
features which could really come in handy for innovative browser-based
operating systems or 3d applications.

Also, if you take advantage of things like procedurally generated textures and
geometry, people won't even have to wait for stuff like loading textures.

Asm.js is cool but its not really necessary and not my thing. We just need
good WebGL support.

Another feature that 3d browser-based games and applications could take
advantage of is WebRTC.

The point being that if you take advantage of easy-to-use web APIs and
libraries like WebWorkers, WebRTC, Three.js, CopperLicht, web-based languages
like CoffeeScript, etc. then the web platform can offer game developers
productivity advantages.

~~~
macspoofing
>I really don't think that asm.js is necessary to bring 3d gaming to the web.

It helps ... a lot. WebGL gives you GPU access which will largely drive your
graphics engine, but there's still tons of places where CPU performance
matters (e.g. physics and AI). Asm.js and WebGL are complementary.

>I'm on the web to take advantage of things like JavaScript and CoffeeScript.

And asm.js prevents this how? If you're coding in CoffeeScript, you already
have a necessary compile step to do. Are you telling me you wouldn't want the
CoffeeScript compiler to give you extra performance by including asm.js
heuristics?

~~~
ilaksh
Yeah there are tons of places that CPU performance matters, but my point is
that Mozilla and WebKit's engines are doing a good job of native compilation
already.

If you could make a CoffeeScript compiler that would output asm.js, then
great. But I'm not sure that's possible. I think that you either have to go
from C/C++ code through the emscripten or right directly using the asm.js
stuff in JavaScript.

~~~
BruceM
Or LLJS: [http://jlongster.com/Compiling-LLJS-to-asm.js,-Now-
Available...](http://jlongster.com/Compiling-LLJS-to-asm.js,-Now-Available-)

------
zenbowman
I worked at a company that developed 3D interactive language and culture
software with speech recognition, virtual humans, etc - one of our biggest
issues was that customers aren't interested in installing desktop software
anymore. We were able to make pretty decent web products using Unity, although
our desktop products were still far superior. Good to see 3D on the web edging
ever closer to becoming standard.

------
socialist_coder
Are you sure this is even correct? The github project for that 3d demo
(<https://github.com/kripken/BananaBread/>) says the 3d engine is "Cube
2/Sauerbraten 3D", not Unreal.

It seems like the Unreal Engine facebook just posted a link to that video and
people are thinking it is Unreal Engine.

~~~
tedmielczarek
BananaBread is a different 3d engine, it's what most of the development work
of emscripten has been focused on. The UnrealEngine demo is a separate demo
done by compiling the UnrealEngine codebase to asm.js using emscripten.

~~~
socialist_coder
Wow, I must be really dumb to have not noticed the Unreal Engine demo video. I
only saw the BananaBread one. Thanks.

------
whatshisface
We will need a really good caching/disk space management system before this
could really be used for much, is anyone working on that?

~~~
padenot
Conveniently, this email [1] has been sent today by Jonas Sicking from
Mozilla. It basically pinpoints all the problems developers using appcache
experience, and proposes a starting point to go towards a good caching system
for the web. Rest assured people are working on that actively.

[1]: [http://lists.w3.org/Archives/Public/public-
webapps/2013JanMa...](http://lists.w3.org/Archives/Public/public-
webapps/2013JanMar/0977.html)

------
ebbv
I'm curious what the performance is like in Chrome or Safari (which do not
have asm.js support.)

If performance is acceptable in Chrome/Safari then that helps sell the idea
that the web is ready for 3D games now.

If the performance isn't acceptable then that helps to make the case for
asm.js.

~~~
mtgx
Mozilla has already showed asm.js is 3-6x slower in Chrome, which doesn't
support it right now.

~~~
ebbv
Yeah they showed a benchmark was 3-6x slower. That's all well and good. I
wanna see what the real world implications are. Here's this cool Unreal demo
running with asm.js support, it looks great.

Now let me run it in Chrome or Safari and see if it's even remotely passable
or not.

------
pxlpshr
We pitched this to Epic in 2007 when our platform helped bring id Software's
Quake online... on any browser.

Included an "app garden" for the mod community around Unreal engine, clans,
ladders, and real-time tournaments with automatic server propagation.

We shutdown due to high infrastructure costs and notorious "2 week" => 2 year
game delays.

------
pekk
What was the actual reason why Mozilla could not implement NaCL?

Why cannot multiple technologies compete among users on their merits?

~~~
bzbarsky
Mozilla doesn't want to implement NaCL because most of the people involved in
the project feel that the hardware-architecture-dependence this would
introduce to the web is a really bad idea.

Mozilla could not implement PNaCL (which would not have that drawback) because
it doesn't exist yet.

~~~
dragonwriter
> Mozilla could not implement PNaCL (which would not have that drawback)
> because it doesn't exist yet.

PNaCl doesn't exist yet? That's funny, because its both in the current Native
Client SDK _and_ has been in Chrome stable (disabled by default) since, well,
I'm not sure, but at least since the last major version, which is the first
time I noticed the setting.

~~~
bzbarsky
Except it still requires you to serve up architecture-specific things for now,
as far as I can tell.

~~~
dragonwriter
> Except it still requires you to serve up architecture-specific things for
> now, as far as I can tell.

PNaCl doesn't require that. The fact that PNaCl is not enabled by default on
the client makes that a practical requirement when using NaCl, but "is not
enabled by default in Chrome" isn't the same thing as "does not exist".
Particularly, the fact that PNaCl isn't enabled by default in Chrome, unlike
the claimed fact that it doesn't exist, is no barrier to Mozilla incorporating
it.

~~~
bzbarsky
Uh... if it's not "existing" enough to enable in Chrome, what makes you think
it's "existing" enough to enable in Mozilla?

But also, see the Pepper discussions through these various threads. "Existing"
for PNaCl also includes being specified enough to actually be implementable,
which runs straight into Pepper.

~~~
dragonwriter
> if it's not "existing" enough to enable in Chrome?

It exists, is included in Chrome, and users can enable it. Its not enabled by
default, but it definitely exists and is deployed in the stable version of
Chrome (and not just the most recent stable version.)

> what makes you think it's "existing" enough to enable in Mozilla?

There's a difference between "Mozilla can't use PNaCl because it doesn't
exist" and "Mozilla doesn't want to use PNaCl because it hasn't reached the
maturity point where Google is ready to enable it by default in Chrome".

The first relies on a false premise. The second doesn't (though its still a
false _statement_ ; Mozilla doesn't want to use PNaCl because they are
committed to JavaScript-as-the-engine-of-behavior for the browser; their
primary objection to every other alternative is that it isn't JavaScript. This
is a perfectly legitimate preference, and there is no need to confuse the
issue with false explanations.)

> "Existing" for PNaCl also includes being specified enough to actually be
> implementable, which runs straight into Pepper.

No, that's not what "existing" means.

That's not to say that issues with the degree to which the Pepper API is well-
specified aren't potentially the basis for legitimate opposition to using
Pepper+PNaCl in browsers, its just completely nonsense to say that PNaCl
_doesn't exist_ (when it manifestly does and is widely distributed). If you
want to argue that Pepper is underspecified, then argue that Pepper is
underspecified, not that PNaCl doesn't exist. Because the first may or may not
be a legitimate argument, but the second is just nonsense.

------
tobylane
I don't fully understand, is this equal to NaCl or webgl/canvas?

~~~
mbrubeck
This Unreal Engine3 port uses WebGL and asm.js.

~~~
drawkbox
asm.js paying dividends already, performance is always useful. But the larger
problem is cross platform gaming, so hopefully webkit and others get something
like this. The problem is Chrome has NaCl, Microsoft has their designs I am
sure, we still need WebGL support which I am sure isn't coming.

For now Unity, Flash and general html5/canvas is still a better cross platform
solution. If this leads to browser mobile games though that are native speeds,
then we have something.

~~~
gcp
asm.js is just a subset of JavaScript, so it works in all browsers already,
unlike those "alternatives" you mentioned.

~~~
pekk
Does it work at full speed without OdinMonkey?

~~~
gcp
No (well more accurately, "it depends on how good TI works without the
restrictions"). Won't matter for most games, see also points made elsewhere
here.

------
tfb
Nice!! I've been planning on implementing the UT99 equivalent of QuakeLive at
<http://www.globalunreal.com> for quite some time now. I've already made a new
ping compensation mod, so all that's left is automating pretty much everything
via the web. Although, I highly doubt I'll go 100% in the browser using WebGL.
It'll most likely just be a wrapper that makes UT appear to be controlled by
the browser when it's actually just running natively. This is all very cool
stuff though. I could see it being quite powerful/useful in the future.

~~~
Aco-
I might be able to help aid you in your efforts if you're interested. I have
been involved with the modding & hacking communities of the unreal engine for
the past 13 years now. I was one of the lead developers for the full
conversion mod Unreal Tournament Revolution which ported UT99 gameplay to the
unreal 2.5 engine. I've worked on various anticheat teams and released the
first unreal engine hook PoC back in 2000. So if you're interested reply to
this with an email, I would love to help you in any way that I can.

~~~
tfb
Ha! It's Aco. Small world! I actually wasn't around UT99 back when you were,
but things are chugging along better now than they have in a looong time since
I made newnet. If I recall, you were actually the guy who told everyone newnet
wasn't possible for UT99!

At any rate, hit me up on irc.globalgamers.net #iPug and #uPug (#tdmpickups
and #mlut are dead).

------
EugeneOZ
Soon all this tricks with CSS and HTML will obsolete, all will be replaced by
canvas, with frameworks, engines, SDK, etc.

~~~
otibom
I'm waiting for someone to implement a web browser in canvas. Wait, now that I
think about it, it has probably been done already.

~~~
MatthewPhillips
This was an april fool's joke from last year:
[http://badassjs.com/post/20294238453/webkit-js-yes-it-has-
fi...](http://badassjs.com/post/20294238453/webkit-js-yes-it-has-finally-
happened-browser)

In the non-joke category, Mozilla created a JavaScript interpreter written in
JavaScript (to test new language features):
<https://github.com/mozilla/narcissus/>

------
dade_
One of the interesting projects that Nortel was developing before they went
into bankruptcy protection was web.alive. It is a 3D collaboration platform
built on the Unreal engine. The biggest problem was that it only supported
windows and required a pretty big plugin that needed to be updated regularily.
Avaya still sells it, and I think this could really make a big difference for
customer adoption. <http://avayalive.com/Engage/>

------
z3phyr
I am tempted to say that 'this is not indicating the death of native platform
games'

By the time we would see UE4 on the web, developers will be trying to achieve
VR graphics in UE5....

Look at your surroundings people. We are far from achieving that kind of
graphics and environment on our native systems. We are far from emulating the
environment, we live in. For that we will always need a great native system +
very fast native programming languages (like C\C++)

~~~
daeken
> For that we will always need a great native system + very fast native
> programming languages (like C\C++)

When you're talking about graphics, this really isn't true at all. 99% of what
matters there happens on the GPU, not CPU, and that's not going down, it's
only going up as GPGPU stuff gets bigger. The days of CPU-bound games are, by
and large, behind us.

~~~
z3phyr
'optimise the GPU for max performance'

I bet you will hear this kind of statement in the future, when more general
purpose work will be done by the GPU. We already have C++AMP, and I bet, in
the future, CPU's will be GPU like.

~~~
NinjaWarrior
I often imagine offloading everything to GPU is the realistic solution to
workaround the mess of standards...

------
niggler
Top youtube comment: "There's nothing about the Unreal Engine 3 on both
emscripten and hacks.mozilla﻿" (<https://www.youtube.com/watch?v=XsyogXtyU9o>)

Even though the major legwork is in emscripten, somehow the focus is on
asm.js. Feels like really heavy marketing.

~~~
nnethercote
It's natural that newer things get more attention.

Emscripten's been well known for months.

asm.js has been well known for weeks.

A working implementation of asm.js (OdinMonkey) has been well known for days.

A demo showing Unreal running on OdinMonkey has been well known for hours.

------
cpprototypes
I have a question about asm.js. My understanding is that it's only useful for
(static typed language) -> asm.js, is that correct? It doesn't make sense for
(dynamic languag) -> asm.js because there's no type information to optimize
with.

------
tuzemec
Am I the only one who finds Unreal powered games for kinda slow, sluggish and
with "weird" movement? Latest two titles that I've tried - Dishonored and
especially Borderlands 2 compared to Rage are hm... crappy... on 660TI

------
alexlarsson
The one thing i don't like about the lowlevel compiled js stuff is the
complete absence of threads. There is no way to get real game-like performance
on a modern multi-core CPU in a single threaded language.

------
melling
Is the idea with asm.js to write in C/C++ and convert it to Javascript? It
sounds like I should relearn C++ because it's the one thing that will run
everywhere. Android, iOS, and now the web.

~~~
ben0x539
The idea is to have an llvm backend targeting a weird subset of javascript
that happens to get optimized really well. As far as I have heard, there are
already other languages that target emscripten via llvm, and I'm sure there
will be more when asm.js gets big. I don't think you'll be stuck with C++.

------
mtgx
Is this using WebGL. If so then I guess games will be limited to OpenGL ES 2.0
API, until WebGL gets updated to a more advanced graphics API level.

~~~
wladimir
OpenGL ES 2.0 is still the safest bet, as it is what most mobile devices
support. Though devices with GLES 3.0 are appearing, driver support is still
subpar. I agree it may be time to look at bumping the API level.

------
lt
Does this mean that the source will be available for anyone playing the game,
even if obfuscated?

It should open interesting possibilities.

~~~
duaneb
I mean the assembly has always been available. I'm not sure asm.js would be
any more readable.

------
Solocloud1
This might go even beyond gaming. First and third person interfaces for the
web.

------
caycep
"but can it run Crysis?"

~~~
Ygg2
It should be theoretically possible. Crysis is written in C/C++ IIRC (well you
program engine in those two languages).

