Unreal JavaScript | Hacker News Reader

Unreal JavaScript

blog.bitops.com

159 pointsndr71 comments

Slight nitpick, but this is Unreal Engine 3, not Unreal, the 1998 PC FPS[1].

That game blew me away when I was younger—the graphics were truly stellar, better than Quake 2 and Half-Life, games released at the same time—and for a moment I thought someone had managed to port it to JavaScript.

I would pay good money to play it in my browser.

[1] http://en.wikipedia.org/wiki/Unreal

You're correct, I should have left it as "Unreal Javascript", but it's too late to edit now, I guess.

can you explain to me why would it be a better news ?

I was impressed that Unreal was running in the browser via Javascript. Unreal Engine 3 is a much more resource intensive engine so that being able to run in the browser is even more impressive.

oh ok I thought you were saying "damn it's not unreal 1, it's unreal 3".

I actually exclaimed "UNREAL!" when I launched this in Firefox Aurora. I was expecting Engine 1, but I see now it's Unreal Engine 3. WOW.

If that's not proof that asm.js is a cool concept, then I don't know what is.

I don't understand how they're making this so freaking fast; they've done some special work to get it running with WebGL.

> We’ve had success in running it in other browsers, but it’s somewhat hit and miss – it heavily depends on the quality of the WebGL implementation, memory management, and JavaScript engine

Anyway, Firefox does a great job with it. I'm impressed.

Just think of how far we got in recent years: C++ code compiled to asm.js, JITted and running in browser running on OS running in virtual machine running on OS running on a microcoded CPU -- and GLSL shaders compiled to ARB, running on microcoded GPU.

Next thing you know, antivirus software for web browsers (sic) will become the norm.

Why would web browsers need anti-virus software? It's not really a problem, since the web's APIs enforce a lot of sandboxing and hence security.

WebGL is pretty scary since it's only a thin wrapper around OpenGL. OpenGL drivers tend to run in the kernel, have direct access to the complete memory of the box and not be hardened from a security perspective. It's only a matter of time before someone figures out a way to own a box via WebGL by simply visiting a website. This is why Apple leaves WebGL disabled by default in Safari, and I think Microsoft is hesitant to add support in IE for the same reason.

I agree. There was a recent time - maybe a few months ago - where Linux with nvidia hardware and their binary driver blob would instantly panic the system when I visited a page in firefox that used webGL shaders.

http://www.opengl.org/registry/specs/ARB/robustness.txt

WebGL is more secure than OpenGL. It helps a lot that the major browsers don't implement WebGL with OpenGL on Windows. Chrome and Firefox implement it with DirectX.

Ok so first, I'll just say, this is cool. I'm pretty excited about asm.js in general.

I'm sort of skeptical when they say they ported "Unreal" though. What I see there is an Unreal map viewer. I don't see any physics or AI or sound going on. The thing is about doing a map viewer, pretty much all the work is going to the graphics card, so it really doesn't matter what language you use. I think I'll be more excited when I see a demo that actually plays like a full game.

If you look at the video you'll see they have full gameplay with bots. Presumably they still have some bugs to iron out or are working on how to present the whole thing to users as a playable game on the web.

I don't think there are any bugs, we showed that map with bots in a booth at GDC 2013 where people could play it. Worked fine.

They note they ported Epic Citadel, it's a tech demo which uses most of the Unreal engine directly, Epic Citadel was originally developed for iOS to demonstrate UE3 ran on/for the platform (before they wrote Infinity Blade) it's not a "map viewer": http://kotaku.com/5627701/play-with-the-unreal-engine-on-you...

As for the physics, you can clearly see flags waving and trees moving, as well as birds flying and water running.

just watch the video to the end, they have some full blown UT3 gameplay vs alot bots in there!

I have played the real Unreal 3 level (the one that ships with UDK) in the browser with bots and physics at one of the webGL meetups. It was awesome. I think the game demo is coming soon.

How are threads handled? The standard Unreal engine isn't single-threaded.

Web workers I guess.

Emscripten uses web workers to compile multithreaded code, provided they don't use shared states (which isn't doable in JS).

Do you know where I can find documentation for that?

They aren't. There is no 1:1 thread construct in JavaScript for sharing memory between threads. Web workers seem like a solution, but it's incorrect to think that is what's going on here. You could use message passing with web workers, but emscripten currently won't turn a semaphore into web worker code. The Unreal Engine 3 had to support older hardware, single core boxes, which is what the demo is compiled as.

I could start it in nightly on linux but with low framerate. On windows I see this in the console (and it stops at "preparing javascript"):

    [15:16:42.533] TypeError: asm.js type error: Internal codegen failure (probably out of memory) @ http://www.unrealengine.com/html5/UDKGame-Browser-Shipping.js:9649
    [15:16:50.798] out of memory

How much RAM does your machine have? How much was used by other tabs/applications?

Very late reply, but I tried win7 x64 and x86 with 4GB. Taskmgr shows the ram usage jump from 900MB to 2.5GB after a fresh reboot.

I tried downloading the entire page (html,css,js) and increasing TOTAL_MEMORY (et al) in the js, but with the same result.

Nightly-23 from 07 May (firefox-20.1, same result). It did work on ubuntu-amd64 though.

If you're per chance running on Linux/Intel/IvyBridge, it can be even faster than on Windows:

Details:

Windows 7 (latest Intel GPU drivers), Firefox 23 nightly

Ubuntu 13.04 with custom Mesa git (Mesa 9.1 also works, but a bit slower), Firefox 23 nightly

I had to set layers.acceleration.force-enabled variable to true in Firefox (in about:config) because it is blacklisted for some reason on Linux/Intel (probably some previously resolved bug).

The browser Window was maximized in 1920x1080, and game view was not full-screened.

Cpu is i5-3320M on Thinkpad X230

Windows: 40.5 FPS Linux: 43.6 FPS

with asm.js

Did you mean with emscripten to asm.js

It should really be named as 'web bytecode' or 'web assembly'.

What is this "web bytecode" you are referring to?

I have no idea what people are talking about here (web bytecode and web assembly doesn't make any sense to me... thought the latter probably is intended to mean asm.js which is just a subset of js that allows for optimization based on the limitation of this subset).

They compiled C/C++-code using Clang (or possible gcc w/dragonegg, but my guess is Clang 3.2 as that's the supported compiler for emscripten) to LLVM bytecode and then to JS/HTML5 using emscripten, which is aware of asm.js and optimizes for it.

Mozilla (which Kripken is also highly involved with) are behind asm.js and is supported in the latest nightly of firefox (supposedly giving speeds to within 2x of native code, which is damn impressive), and the guy behind emscripten (again, Kripken) works for Mozilla.

I'm don't know to what extend emscripten is part of Mozilla or his own personal project.

---- Slides by Kripken on emscripten (http://kripken.github.io/mloc_emscripten_talk)

The "web bytecode" refers to the fact that the two script files are bytecode and not readable js.

Download them with: 1) curl "http://cdn.unrealengine.com/html5-4c0913f/UDKGame-Browser-Sh... -H "Referer: http://www.unrealengine.com/html5/ > UDKGame-Browser-Shipping.js

2) curl "http://cdn.unrealengine.com/html5-4c0913f/UDKGame_Data.js -H "Referer: http://www.unrealengine.com/html5/ > UDKGame_Data.js

And all you get is 5.4M / 4K of unreadable bytecode.

> And all you get is 5.4M / 4K of unreadable bytecode.

It's just gzipped. ungzip the files (turns 5 MB into 50 MB) and you can read them as plain text javascript.

Ah, that helps. I wonder why the gzip is not done automatically by curl/wget...

Yeah, it confused me at first as well, but I ran `file` to see what was going on and that clued me in.

It will if you pass in --compressed flag, e.g.:

   curl --compressed "http://cdn.unrealengine.com/html5-4c0913f/UDKGame_Data.js" -H "Referer: http://www.unrealengine.com/html5/" -O

Yes and no... once you hit the

   // EMSCRIPTEN_START_ASM

it becomes

    if((d|0)!=36620|(d|0)!=0&(c[b+4>>2]|0)!=0)
    {c[1779323]=6}b=c[1312365]|0;d=7084512;
    c[d>>2]=c[1312364]|0;c[d+4>>2]=b;b=7084520;
    d=c[b>>2]|0;if((d|0)!=36620|(d|0)!=0&(c[b+4>>2]|0)!=0)
    {c[1779323]=7}b=c[1312363]|0;d=7084520;
    c[d>>2]=c[1312362]|0;

all on one line for nearly the rest of the file. It might as well be bytecode. Actually many bytecodes are more understandable.

No, it's still JavaScript. The fact that it's compressed or not human-readable doesn't make it bytecode.

"It might as well be bytecode."

So can you add some dynamic code into asm.js and expect same performance? Asm.js is an assembly that looks like JavaScript for compatibility and readability.

No, asm.js code that parses successfully is compiled ahead of time. It is a strict subset of the JavaScript programming language. If you use parts other than the subset, it will fail to parse as valid asm.js code and revert to the interpreter/JITs.

THERE is the code. LOL, I actually did not spot it in the file and asked myself "just where the ... is the code"?

Well yes, but the same is true of any minified JavaScript, handwritten or compiled. For example look at the output of the closure compiler minifier.

Minified Javascript does not operate on an enormous buffer of bytes, such that you get seven and eight digit numbers flying everywhere. It's still easier to understand and manipulate than ASM.

asm.js isn't just an evocative name, it's a reasonable description... it's assembly in Javascript.

Should they? Both terms appear to not make much sense even in context, and also appear from a quick google search to have no provenance at all.

To be fair, the idea of distributing executable bytecode to be run by some kind of VM in browsers has been around for almost as long as the web has (predating even Java), even if there never was a standard name for it.

Sure, but that's just not what's being used here.

Yes, asm.js is a subset of JavaScript that emscripten compiled UE3 into, in this demo.

I know, I was correcting the title.

Sorry if I wasn't clear, I was just trying to say you were right.

Where's the solution that enterprises can use to build their remaining desktop apps into the browser? People still write native Windows apps, for example, to get performance in large grids with filtering.

A solution is missing that fits between C++ and Javascript.

You could argue that Citrix and Terminal Services do a reasonable job of delivering existing desktop apps to remote users (even in a browser).

Now, of course, there are a lot of advantages to having things really working in a browser - less sensitivity to latency sometimes being a critical one. But there are a lot of enterprises using remote access to thick client applications, even some specialised SaaS vendors.

Ok, that's fine for legacy, but what should enterprise do about new apps? Continue to build desktop apps and deliver with Citrix?

Apart from some specialised scenarios (e.g. direct interfacing with directly attached devices) then web applications are clearly the way to go for newly written applications. However, I would be very reluctant to describe anything non-Web as "legacy" - enterprises will happily (and rightly) still buy desktop applications if they are the best tool for the job - and these need Citrix or Terminal Services.

You could also target Winelib in Enscripten, porting winedrv to canvas.

Err... Have you ever heard of C#/WPF/WinForms?

It's impressive but runs at 19 FPS on my new desktop with a GTX 660 card. It's still slower than I've seen that demo running on a phone. People are doing amazing things with HTML5 and JavaScript but the performance is always behind a native application, even a Java application.

> but the performance is always behind a native application

But the performance will always behind a native application.

I don't understand how removing the verb in a sentence is supposed to be a correction. :)

FPS really depends on which browser you are on.

Since you mentioned Java, note that in some cases JavaScript with asm.js can be faster, for example http://j15r.com/blog/2013/04/25/Box2d_Revisited

If someone gave JBox2D the same amount of attention box2d.js got to win this benchmark, I suggest that the results would look different. Correct me if I'm wrong, but it seems like box2d.js was made and optimized just prior to this benchmark, while JBox2D is an old project that was never meant to win any benchmarks.

I see much higher framerates than that running the demo on a laptop with a boring integrated Intel GPU. Are you using the released version of Firefox, the nightly Firefox, or a different browser?

Sounds uber cool, but don't work in Chrome. The tab just crashed...

Will it be much jobb to make this work in all browsers?

Well yes, as this is compiled for asm.js-capable browsers (i.e. Firefox for now), it will be so slow on anything else that it will just crash.

You can run it in non-asm.js browsers; the released version of Firefox can run it, for example. It doesn't crash, but it is slower. According to the FAQ on the game site [0], Chrome has a bug which is expected to be fixed soon.

[0] http://www.unrealengine.com/html5_faq/

The good news is that the crash in Chrome is not due to issues in asm.js or WebGL. Apparently, this demo exposed a bug in Chrome's garbage collection. There is already a ticket in Chrome to fix it.

What happened to the original title "Unreal JavaScript"? The biggest focus of the article is emscripten, not asm.js.

I downloaded latest Nightly for Windows but it still doesn't open. Tells me to download Nightly which I did. :(

works great in aurora for me (fps caps at 60...whoa)

Very cool. Running very smoothly for me.

Reply on news.ycombinator.com