Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unreal Engine in JavaScript/HTML5 – Citadel demo

unrealengine.com

Post reply on HN
Print view View original

151–159 of 159 posts

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#151

Post by azakai »

Arelius wrote: post #141
BrendanEich wrote: post #122

Earlier quoted context omitted.

No, not a subset. It's UE3 cross-compiled by Emscripten from ~1MLOC of primary C++ source. Some configury to use OpenAL (mapped to WebAudio), and of course OpenGL-ES (mapped to WebGL). /be

It's really not. It's the UE3 Mobile Engine. Which while it's compiled from the same C++ source, It has enough things stripped during compilation to not really be considered 'full UE3' custom shaders for instance are not supported. And atop of missing some things from UE3, Citadel is designed specifically for limited devices. While still a very impressive feat, let's not confuse this with running GoW or The Samaritan…

As mentioned in other comments, we also ran other UE3 games, like Sanctuary. We demoed that in a booth at GDC last month where people could play it. That's a full UE3 desktop game with bots, AI, normal FPS mouse control (not tablet-like), etc. etc. You can see it in action in the 2nd half of this video

http://www.youtube.com/watch?v=BV32Cs_CMqo&feature=youtu...

And it's using the exact same code as this demo. You literally use the same compiled JS, and just swap in a different set of game assets.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#152

Post by nailer »

BrendanEich wrote: post #122
matthew-wegner wrote: post #107

Earlier quoted context omitted.

It's probably a subset of the Unreal Engine. And it only works in Firefox, and even then only very well in Firefox Nightly. Those points aside, though, this is pretty amazing. I fully expect multiple engines to target HTML5 in the same way Unity/Unreal/etc were cross-compiling for the Flash runtime. It's just not quite there yet... (And it's good that demos like this exist to put pressure on browsers to fully support…

No, not a subset. It's UE3 cross-compiled by Emscripten from ~1MLOC of primary C++ source. Some configury to use OpenAL (mapped to WebAudio), and of course OpenGL-ES (mapped to WebGL). /be

Brendan what was the game you played at JQuery UK a couple of weeks back? It was Unreal Engine 4 right?

Thanks! (also thanks for JS, it is neat!)

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#155

Post by ricardobeat »

nailer wrote: post #152
BrendanEich wrote: post #122

Earlier quoted context omitted.

No, not a subset. It's UE3 cross-compiled by Emscripten from ~1MLOC of primary C++ source. Some configury to use OpenAL (mapped to WebAudio), and of course OpenGL-ES (mapped to WebGL). /be

Brendan what was the game you played at JQuery UK a couple of weeks back? It was Unreal Engine 4 right? Thanks! (also thanks for JS, it is neat!)

That was probably BananaBread (https://developer.mozilla.org/en-US/demos/detail/bananabread), which uses a different engine.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#156

Post by __--__ »

Strom wrote: post #146
mtgx wrote: post #137

Earlier quoted context omitted.

I hate how DRM is being thrown around as a "turn-key" solution against piracy, because it's simply wrong. What's stopping anyone from selling copies of heavily DRM'ed - but cracked - games right now? Nothing. Actually, WebGL games would be a lot more secure from piracy, because they would be online, and you could easily stop 99% of the piracy by requiring a login for the game. It's basically like the Diablo 3 model,…

Diablo 3 is definitely not easier to crack. You need to know x86 assembly, and on top of that beat Blizzard's reflection-ish protection that checks for modified code. JavaScript is much easier to deal with. In addition to that, just cracking the Diablo 3 client isn't enough, because a lot of the game logic runs exclusively on the server. For example, even with tens of thousands of test runs of a specific monster, you…

>Diablo 3 is definitely not easier to crack.

Moot point. Any client software can and will be cracked, regardless of how difficult it is to crack. Which is mtgx's point - online games are easier to secure because you can put logic and validation on a remote server. No DRM needed. Your example of Diablo 3 only proves his point. It's not the DRM that makes Diablo 3 hard to crack - it's the server side logic and validation.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#157

Post by just2n »

azakai wrote: post #150
Hnefi wrote: post #138

Earlier quoted context omitted.

That link is misleading in the context you present it. Those are microbenchmarks, which a JIT can optimize relatively well. But if you look at the very next slide at http://kripken.github.io/mloc_emscripten_talk/#/28 you will see that for a larger application, non-optimized asm.js performs abysmally, as does JS in general. A performance penalty of ~1000% of native is what you should expect for a nontrivial JS applica…

I was purposefully linking to that slide + the one after it. Yes, there is a factor of around 4x slowdown between asm.js optimizations and without them, on the next slide. But even 4x slower than asm.js is quite fast, it's enough to run the Epic Citadel demo for example (try it on a version of firefox without those optimizations, like stable release - as others reported in comments, it runs ok). A lot of the work in…

It's faster than "handwritten JS" because it's using a subset of JS that's already tuned to near the peak level of performance that you can achieve in JITting JS, which is tightly looped arithmetic with everything inlined working on SMIs. In V8, that's ~2.5x slower than the equivalent C code with optimizations. That's basically best case.

The problem is that it's still dynamic, and at any point a null can come along and force you to throw away a JITted function, so you have to have these checks everywhere just in case. Further, ECMA compliance does not require JIT compilation, which means to expect performance, especially on the web, is dubious at best. I can see merit to expecting performance metrics in something like Node.JS since it assumes V8, but the web does not have 1 JS engine, and the standard does not require such performance metrics.

The "benefits" of building a bytecode in that's represented in some subset of JS are essentially red herrings since they're effectively lies and the downsides are a lot more significant, IMO. Instead, we should be focusing on actually building a bytecode for the web such that all implementations are expected to have certain performance metrics.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#158

Post by Arelius »

azakai wrote: post #151
Arelius wrote: post #141

Earlier quoted context omitted.

It's really not. It's the UE3 Mobile Engine. Which while it's compiled from the same C++ source, It has enough things stripped during compilation to not really be considered 'full UE3' custom shaders for instance are not supported. And atop of missing some things from UE3, Citadel is designed specifically for limited devices. While still a very impressive feat, let's not confuse this with running GoW or The Samaritan…

As mentioned in other comments, we also ran other UE3 games, like Sanctuary. We demoed that in a booth at GDC last month where people could play it. That's a full UE3 desktop game with bots, AI, normal FPS mouse control (not tablet-like), etc. etc. You can see it in action in the 2nd half of this video http://www.youtube.com/watch?v=BV32Cs_CMqo&feature=youtu... And it's using the exact same code as this demo. You lit…

If so, something like that would be a much more impressive demo. Citadel just frankly isn't that impressive.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#159

Post by nailer »

ricardobeat wrote: post #155
nailer wrote: post #152

Earlier quoted context omitted.

Brendan what was the game you played at JQuery UK a couple of weeks back? It was Unreal Engine 4 right? Thanks! (also thanks for JS, it is neat!)

That was probably BananaBread ( https://developer.mozilla.org/en-US/demos/detail/bananabread ), which uses a different engine.

BE stated explicitly that it was an upcoming Unreal Engine 4 game (and I've seen / played Bananabread, this wasn't it).
Post reply on HN