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

141–150 of 159 posts

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#141

Post by Arelius »

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

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 demo in the browser.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#142

Post by pjmlp »

TazeTSchnitzel wrote: post #136
pjmlp wrote: post #133

Earlier quoted context omitted.

Except they have a binary client, not a builtin debugger.

Asm.js is pretty damn binary-like. Good luck debugging that.

On my early programming days we used to write hex dumps into so called monitors, I guess it should be no problem.

On the other hand, the VM cool kids of today might have an issue.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#144

Post by kalleboo »

What continues to impress me about these demos is that JavaScript has gone from "not useful for much more than form validation" to "can compile and execute a 52 MB block of what's basically assembly code".

52 MB of JavaScript is... a lot (even if half of it looks like data tables of some kind)

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#145

Post by atesti »

laumars wrote: post #74
jlgreco wrote: post #69

Earlier quoted context omitted.

Just took out that tab for me in windows. Seems like something else is probably going on for you.

Chromium has been a little dodgy for me lately too. Lots of memory leaks and what not. I've had to kill it's parent process id on a number of occasions (but even then, there's no reason why a browser should take out the whole OS).

They are also not really visibly working on issues like these: http://code.google.com/p/chromium/issues/detail?id=222558 http://code.google.com/p/chromium/issues/detail?id=134837

Basically, each font in each size uses some handles in a renderer. At 10000 handles, the tab renderer dies. They have a font cache but never clear it. When enough render processes together use too many GDI handles, the whole Windows desktop breaks down.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#146

Post by Strom »

mtgx wrote: post #137
Rinum wrote: post #127

Earlier quoted context omitted.

The biggest issue I see is with distribution. For example: I'm not a fan of DRM, but there's nothing preventing anyone from downloading the game and selling/giving away copies with ease.

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 still won't know the correct item drop probability table, because that table is never sent to the client. Only the result of the server-side dice roll checked against the server-side loot table.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#147

Post by [deleted] »

ndesaulniers wrote: post #92
an_honest_idea wrote: post #63

What's the point of having these massive javascript virtual machines & webgl systems in our browsers? How does having a separate implementation of a specification help us build a safer, more open web? My theory is that Mozilla and Google are in a race to develop the most advanced html5 engines because they know that if a killer html game or app gets developed in their browser, everyone who wants to use the app will s…

> What's the point of having these massive javascript virtual machines & webgl systems in our browsers? Because the safety model of JavaScript has been sound for the past few years. > How does having a separate implementation of a specification help us build a safer, more open web? What seperate implementation of what specification? If you're referring to asm.js, asm.js is just JavaScript, any browser can run it. The…

[deleted]

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#148

Post by Stranger2013 »

ricardobeat wrote: post #103
matthew-wegner wrote: post #100

Earlier quoted context omitted.

Heh, sure. But it was a demo for the original iPad, which is easily a quarter of the performance of current iOS devices.

Dude. (sorry) This is Unreal Engine, with physics, cloth simulation, particles, light & glare effects. It's not C++ on Native Client or a plugin, it's running in javascript . Just yesterday you couldn't draw a circle on a 2d canvas at 30fps.

[some negative rant below to offset the hype - sorry]

> "This is Unreal Engine" - a subset of it

> "with physics" - did not notice any falling kickable boxes and such

> "cloth simulation, particles, light & glare effects" - impressive, but there will be twice less of that then via native code

> "It's not C++ on Native Client or a plugin, it's running in javascript" - what's the difference between downloading one/two specific browsers or making a build of each with a flash player bootstrapped?

> "Just yesterday you couldn't draw a circle on a 2d canvas at 30fps" - so instead of pushing to make a universal VM, they decided to use a dynamic prototype-OOP language just because it happened to be most common - not very impressive.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#149

Post by pornel »

Stranger2013 wrote: post #148
ricardobeat wrote: post #103

Earlier quoted context omitted.

Dude. (sorry) This is Unreal Engine, with physics, cloth simulation, particles, light & glare effects. It's not C++ on Native Client or a plugin, it's running in javascript . Just yesterday you couldn't draw a circle on a 2d canvas at 30fps.

[some negative rant below to offset the hype - sorry] > "This is Unreal Engine" - a subset of it > "with physics" - did not notice any falling kickable boxes and such > "cloth simulation, particles, light & glare effects" - impressive, but there will be twice less of that then via native code > "It's not C++ on Native Client or a plugin, it's running in javascript" - what's the difference between downloading one/two…

asm.js is a universal VM with bytecode that just happens to be similar to subset of JS, but it doesn't have dynamism, doesn't have OOP, doesn't have garbage collection.

Firefox has a separate ahead of time compiler for asm.js that isn't a JS VM.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#150

Post by azakai »

Hnefi wrote: post #138
azakai wrote: post #101

Earlier quoted context omitted.

> 1. asm.js makes running C++ code that would render to OpenGL in the browser a possibility, and with relatively good performance. Kudos to Mozilla. > 2. It runs on browsers that don't know about asm.js, but it's effectively an emulated machine, and it's slow. Do you have benchmark numbers to support that? In my experience, asm.js code is quite fast even without special asm.js optimizations. It depends on the benchma…

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 Epic Citadel is on the GPU anyhow, say it's about half, so the difference is then only something like 2x.

2x is not that much, we have similar differences on the web anyhow because of CPU differences, JIT differences, etc. That's within the expected range of variance.

Also, asm.js code is faster even without special optimizations compared to handwritten JS (see for example http://blog.j15r.com/blog/2011/12/15/Box2D_as_a_Measure_of_R... and http://blog.j15r.com/blog/2013/04/25/Box2d_Revisited ). So even without those optimizations it is worthwhile.

Post reply on HN