Live data from Hacker News

Unreal Engine in JavaScript/HTML5 – Citadel demo

unrealengine.com

81–90 of 159 posts

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#81
post #4

I love the fact that Mozilla keeps pushing javascript to its limits. They seem to be doing a lot of things really well lately, this is awesome!! Plus you have Firefox OS, which pushes web-standards to native mobile. Now I just wish the devtools would get up to paar with those on chrome/chromium and I'd be switching back to FF in a heartbeat. I wish google would stay on board with JS since they have the engineering po…

> they've kind of abbonned JS in favor of Dart

Haven't they announced that they have no plans to integrate the Dart VM with the Blink rendering engine?

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#82

Earlier quoted context omitted.

From the FAQ: - Chrome currently crashes, but is expected to be resolved by the Chrome team soon. http://www.unrealengine.com/html5_faq/

I wish I had read that first :/ Crashed my whole system Chromium 25.0.1364.160 Ubuntu 12.04

Same here; google-chrome-unstable-28.0.1485.0-195393.x86_64 on Fedora 18.

Hardest crash I've experienced on this new setup.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#85
post #80
post #76

On Firefox 20 on Windows on my 2500k with a 7970 it seems CPU bound and can only achieve 43fps benchmark at 1920x1200, while having some clear artifacts from lack/too little texture anisotropy on the floor and antialiasing issues. Also, the textures are not fully detailed when looking directly at the floor and walls. If this is supposed to be a full quality benchmark (ala Unigine Heaven when it came out), it needs to…

FF 20 does lack the asm.js integration.

[deleted]

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#86
post #54
post #49

I take issue with calling this JavaScript/HTML5. This is powered by asm.js. The source is emphatically NOT JavaScript, it's a subset that's meant to be a target for compilation (like a bytecode in .NET and the JVM) and is treated entirely differently from JavaScript by the JIT. We don't call everything that runs on .NET C# nor everything that runs on the JVM Java. Additionally, asm.js is not part of HTML5. It's inter…

Even though it's using JavaScript as a kind of bytecode, it is just JavaScript / HTML5 (and some CSS, but that's pretty anedoctical I guess). Asm.js is a subset of JavaScript. As soon as Chrome fixes the crash, it'll run in a browser that supports just HTML5 (for presenting the page / the DOM / the canvas) and JavaScript with no special asm.js optimizations, and we'll have to see how fast/slow it is then. To correct…

I understand that. Take a read of this: http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html.

I have a lot of respect for Egorov, and I agree with his views on this matter quite entirely.

The sole benefit of embedding a bytecode in a language is that you get the side effect that it can run anywhere that language runs. But in general, this implies performance penalties, especially when the language is relatively slow to begin with.

But in this case, this demo is made usable (ie: the impressive part) by writing a compiler specifically for the bytecode itself. So it works well in spite of the fact that it's a bytecode embedded in JS, not because of it. The really cool things about this demo are precisely 2 things:

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.

I just take issue with calling this an example of what JavaScript/HTML5 can do. I think seeing an application written in JS using WebGL or Canvas as something much more impressive, and there are Q3 renderers that are natively JS that run with amazing performance in the browser. This is just dressing up the fact that turing completeness is a thing and calling attention to it. The real thing to get from this demo is that there are enormous benefits to having a bytecode for the web over trying to optimize a fully dynamic language like JS. I feel like that is relatively lost by the title.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#87
post #80
post #76

On Firefox 20 on Windows on my 2500k with a 7970 it seems CPU bound and can only achieve 43fps benchmark at 1920x1200, while having some clear artifacts from lack/too little texture anisotropy on the floor and antialiasing issues. Also, the textures are not fully detailed when looking directly at the floor and walls. If this is supposed to be a full quality benchmark (ala Unigine Heaven when it came out), it needs to…

FF 20 does lack the asm.js integration.

Firefox Nightly is indeed much better CPU-wise, keeping 60fps with around 80% single core usage at most.

However, it still has poor graphics, with low quality textures, low/nonexisting anistropic filtering and no AA or bad AA.

Also just noticed that stuff like bracers that should be rounded (using GL 4 hardware tessellation) is not and has visible polygonal edges.

Not really a great showing as a demo.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#89

So it basically means that C++ got another reasonable compilation target. Not much to do with applying JavaScript to large-scale games. Also it is not HTML 5, it is HTML FF23.

Factually, all code emitted from emscripten is JavaScript. It may look funny with all the bitwise operators that are barely ever used by web developers, but it's just JavaScript. It doesn't run correctly in Chrome right now because they have issues with their JavaScript environment not supporting large numbers of variables for a given context. It doesn't run in IE because IE doesn't support webGL. Both of these will be fixed in the future.

Re: Unreal Engine in JavaScript/HTML5 – Citadel demo

#90
This is actually very old demo ported to the browser. The original Epic Citadel was/is an iOS demo released in September 2010. It runs well on an original iPad: http://en.wikipedia.org/wiki/Epic_Citadel

Comparatively, this runs a little sluggishly on a MacBookPro8,2 (early 2011).

Post reply on HN