To convert the Unreal Engine 3 tech demo to standards-compliant HTML5, Epic made use of Emscripten, a tool that allows users to compile programs written in C and C++ into asm.js, a stricter subset of JavaScript that adds additional low-level functions and optimization. This allows the demo to run "within 2x of native speeds," according to Epic, while still supporting features like global illumination and dynamic specular lighting.

Indeed, in our tests, the HTML5 version was benchmarked at just under 28fps at a 1920×1200 resolution on a three-year-old Windows desktop rig, compared to about 48 frames per second for the native version running through UDK on the desktop. The HTML5 performance appeared comparable to the Flash version of Epic Citadel that was released last year, but that version lacks the native benchmarking capabilities that would allow for a like-for-like comparison to other versions. Still, I was able to get a smooth 60fps on the Flash version running in Chrome (though, oddly, only 30fps in Firefox).

While the new version of Epic Citadel could theoretically work in any browser that supports HTML5, the demo is only currently fully supported in the latest versions of Firefox Nightly, which fully supports WebGL and asm.js. The Chrome development team is reportedly working on fixing a problem that currently crashes the demo, while Internet Explorer users are left out in the cold with no WebGL support at all. Opera and Safari are not supported, even in their WebGL-equipped incarnations.

While apps running in the browser will likely never be able to match the kind of performance you can get with native code, it's nice to see more developers working to narrow the gap without needing to resort to proprietary plugins or coding environments. After all, releasing a single HTML5-compliant game that works across browsers and platforms is a lot more straightforward than crafting dozens of different ports for different systems.

Promoted Comments

I'm probably wrong here... but from my somewhat limited understanding, all JavaScript-based web applications are not really 'compiled', and basically anyone who's displaying the web app in their browser can check the entire source code...

While I'm aware that this excludes code executed on the server (i.e. PHP, ASP.NET etc.), with this example it's mostly interpreted client-side code which can be seen by everyone.

Isn't this a major issue that would make businesses hesitant to invest time in making serious web applications -- or games -- with the intention of making profits? Am I missing something?

Raw source javascript is a pretty rare thing these days, for anyone making a seriously performant production application at least. The code you see is going to be minified/gzipped javascript. With these games I'm betting a lot of it is going to be compiled to javascript from C/C++ too. So it will almost certainly be incomprehensible/unmaintainable garbage. asm.js, the fast javascript subset they're using here, is even worse, with tons of weird notations and quirks to help the javascript interpreter do more efficient static compilations. It would be easier to steal/modify than a binary, certainly, but it would still be a nightmare to properly use it.

Game devs also tend to work on source that is technically freely available, but is simply not licensed for free use. Any legitimate competitor wouldn't be able to use their code, and reverse-engineering would probably take more energy than just re-inventing the wheel. Cloning via asset swaps is in some sense a concern, but clones spawn even without the source.

So basically piracy is probably the biggest concern, but as long as part of your functionality is tied back to the server (as most webapps inevitably are), stealing it would be... tricky. Granted, server APIs have been replicated and circumvented on native desktop applications. However with webapps there's generally more streaming of content going on. Games like SimCity are basically entirely there on your computer when you download them. With a webapp, a hack to work locally, or on a pirated server, would have to be a bit more sophisticated, I think.

Further, a lot of games on the web (usually flash) in some sense can actually rely on being "stolen", in that they use in-game ads or other mechanisms to generate revenue just based on usage. When I was working with people in this model a few years back, the margins were basically horrible though (single-digits thousands of dollars is "big", maybe double digits thousands if you've got established IP), so that's probably not a great model to try to replicate. And that's GROSS profits.

Source: I've done a few years of contracted web-based game development in both Flash and HTML5. I also help teach the webapps course at my university.

Indeed, in our tests, the HTML5 version was benchmarked at just under 28fps at a 1920×1200 resolution on a three-year-old Windows desktop rig, compared to about 48 frames per second for the native version running through UDK on the desktop.

Was that in Nightly or Stable? Firefox Nightly runs it at more than twice the frame rate for me, because it has optimisations which aren't yet in normal Firefox.

Also, some more info about this: This is actually the full Unreal Engine, although unfortunately they used an old iOS demo, maybe because it was easier to port. The controls will be better for actual games, since Pointer Lock exists allowing FPS-style controls, but sadly this demo doesn't use it (probably because the iOS version didn't).

I thought the whole idea was a standards compliant web. Yet, instead of attempting to display the demo, I see a hard coded browser check that tells me to download FireFox.

How is this better than "This site requires IE6" exactly?

It allows you to try anyway. They aren't forcing you to use FF at all.

Late EDIT: Note, this option doesn't show up if your browser doesn't support WebGL.

Unfortunately, there's a Chrome bug meaning it will crash Chrome at the moment. But it isn't the same as requiring IE6 - it's based on web standards, and any browser implementing them should be able to run it. The reason they check for FF is because currently it only works well in FF, but soon the other browsers will catch up - even IE! IE11 leaks have been shown to support WebGL.

Indeed, in our tests, the HTML5 version was benchmarked at just under 28fps at a 1920×1200 resolution on a three-year-old Windows desktop rig, compared to about 48 frames per second for the native version running through UDK on the desktop.

Was that in Nightly or Stable? Firefox Nightly runs it at more than twice the frame rate for me, because it has optimisations which aren't yet in normal Firefox.

Our tests were in Nightly. Obviously a better rig is gonna get better frame rates.

Indeed, in our tests, the HTML5 version was benchmarked at just under 28fps at a 1920×1200 resolution on a three-year-old Windows desktop rig, compared to about 48 frames per second for the native version running through UDK on the desktop.

Was that in Nightly or Stable? Firefox Nightly runs it at more than twice the frame rate for me, because it has optimisations which aren't yet in normal Firefox.

Our tests were in Nightly. Obviously a better rig is gonna get better frame rates.

Well, I have a pretty rubbish PC (Intel Pentium Dual Core, ATI HD5450 budget), and I get just under 60fps out of it in Nightly, but YMMV.

The title of this article is misleading. While WebGL and OpenGL are closely related and share the same standards body, they are different specifications. This shows the power of WebGL in the browser.

Also, what most people don't realize is that the two most popular browsers (Firefox and Chrome on Windows) render WebGL content using DirectX, via a translation layer known as ANGLE. So if you're on Windows, you aren't even using OpenGL (unless you specifically went in and shut ANGLE off). While other OSes use OpenGL directly, it's an implementation detail and not a requirement.

I'll also plug my own open-source WebGL project, Cesium. I would normally not plug something in an Ars comment but it's open source and relevant.

Also, what most people don't realize is that the two most popular browsers (Firefox and Chrome on Windows) render WebGL content using DirectX, via a translation layer known as ANGLE. So if you're on Windows, you aren't even using OpenGL (unless you specifically went in and shut ANGLE off). While other OSes use OpenGL directly, it's an implementation detail and not a requirement.

Any particular reason why these browsers are using this translation library versus Windows' native OpenGL support? Merely because drivers (which really should install anyway, if you are expecting to use graphics acceleration) provide anything in excess of OGL 1.1?

That can't be right. Perhaps that should say within half native speed? I'm sure it's not possible for the Javascript/HTML5 version to have double the performance, otherwise every game would be written in Javascript.

I'm not a web developer so I won't comment on all the underlying technologies or complain about the fact it's FF-Nightly-Only at the moment, but I will say I feel this is cool as heck.

I benchmarked 96fps on my 2009 Mac Pro in fullscreen. I fully agree this engine doesn't compete with a standalone Skyrim or [insert pretty-game-here], but this was really smooth for a 30 second download that played within a browser.

I thought the whole idea was a standards compliant web. Yet, instead of attempting to display the demo, I see a hard coded browser check that tells me to download FireFox.

How is this better than "This site requires IE6" exactly?

It allows you to try anyway. They aren't forcing you to use FF at all.

Unfortunately, there's a Chrome bug meaning it will crash Chrome at the moment. But it isn't the same as requiring IE6 - it's based on web standards, and any browser implementing them should be able to run it. The reason they check for FF is because currently it only works well in FF, but soon the other browsers will catch up - even IE! IE11 leaks have been shown to support WebGL.

I'm apparently running on stupid instead of caffeine today as I couldn't find a way to force it to execute. No mater where I clicked I could not find anything that would initiate an attempt. Just a "unsupported.jpg" that displayed the message "This browser is currently unsupported. Please download Firefox 23 (Nightly) for an optimal experience." and wouldn't do anything else

Please provide further instructions if you would on how to force it to attempt to execute instead of giving this IE6 style message?

Also, what most people don't realize is that the two most popular browsers (Firefox and Chrome on Windows) render WebGL content using DirectX, via a translation layer known as ANGLE. So if you're on Windows, you aren't even using OpenGL (unless you specifically went in and shut ANGLE off). While other OSes use OpenGL directly, it's an implementation detail and not a requirement.

Any particular reason why these browsers are using this translation library versus Windows' native OpenGL support? Merely because drivers (which really should install anyway, if you are expecting to use graphics acceleration) provide anything in excess of OGL 1.1?

If you're a gamer and install the latest Nvidia or ATI Drivers, then OpenGL most likely works great on your system. However, the average Windows user is either running with out of date drivers or using an Intel card which in general has incredibly buggy OpenGL support. The card's drivers still claim support for the latest features, but using them is a buggy mess and an exercise in futility. While Intel has made stride in the last few years (the HD 4000 is a huge improvement over older cards but there are a ton of 3000s out there that are horrid) this is still a problem in many cases. Furthermore, newer solutions like Nvidia Optimus, which switch between onboard/discrete graphics at will only do so when DirectX calls are encountered. So an OpenGL based app will not trigger discrete graphics on those boards. DirectX, being an MS technology, has excellent support across the board.

Long story short, if you want WebGL support to be as ubiquitous as the web in general, OpenGL is not the way to go on Windows. Using ANGLE allows WebGL to work on almost all hardware out there that can run Windows.

Chrome also includes swiftshader support, so even if your driver is out of date or unable to support the DirectX features it needs, it will render in software.

Hope that helps, if you have any other questions, I'll do my best to answer them.

I'm not a web developer so I won't comment on all the underlying technologies or complain about the fact it's FF-Nightly-Only at the moment, but I will say I feel this is cool as heck.

I benchmarked 96fps on my 2009 Mac Pro in fullscreen. I fully agree this engine doesn't compete with a standalone Skyrim or [insert pretty-game-here], but this was really smooth for a 30 second download that played within a browser.

It works on Aurora as well. Controls take a little getting use to, and the cursor isn't locked into the window.

Webdev who is currently dabbling in gaming right now, so I'm curious about a couple things here... ould this would work with Oculus Rift, and are all the game assets pre-delivered, or did they somehow do lazy loading of them?

Regardless, cool as shit. Love it.

Oh one other thing. Are network communications governed by the browser, or can you open up sockets to do UDP?

I'm apparently running on stupid instead of caffeine today as I couldn't find a way to force it to execute. No mater where I clicked I could not find anything that would initiate an attempt. Just a "unsupported.jpg" that displayed the message "This browser is currently unsupported. Please download Firefox 23 (Nightly) for an optimal experience." and wouldn't do anything else

Please provide further instructions if you would on how to force it to attempt to execute instead of giving this IE6 style message?

I see this text message: "This browser is currently unsupported. Please download Firefox 23 (Nightly) for an optimal experience or try anyway." "try anyway" is a link.

A: This is very new technology based on the latest existing web standards. Not all browsers are currently using these standards, and they may also have issues with such large content. We expect most or all browsers to eventually support this demo, which requires Web GL and JavaScript, and benefits from asm.js. For an optimal experience right now, we recommend Firefox Nightly (Version 23 or higher), which can be downloaded at http://nightly.mozilla.org/.

Please note: If your browser does support WebGL, you should be able to try Epic Citadel HTML5, though it may result in a browser crash or other similar issues. As WebGL becomes more widely adopted, these issues should be resolved with later browser versions.

A: This is very new technology based on the latest existing web standards. Not all browsers are currently using these standards, and they may also have issues with such large content. We expect most or all browsers to eventually support this demo, which requires Web GL and JavaScript, and benefits from asm.js. For an optimal experience right now, we recommend Firefox Nightly (Version 23 or higher), which can be downloaded at http://nightly.mozilla.org/.

Please note: If your browser does support WebGL, you should be able to try Epic Citadel HTML5, though it may result in a browser crash or other similar issues. As WebGL becomes more widely adopted, these issues should be resolved with later browser versions.

No dice. I did have WebGL enabled, I cycled it off and on with a restart and still no luck. Java's enabled too. This is Opera 12:15

Interesting demo. Wonder if it will take as long to download the HTML5 version as it does the native version?

Pretty much the same time.

The art assets are identical in a native and HTML5 build of the same project. And the compiler output is quite small compared to those assets, but also of similar size to native code after both have been gzipped.

Testing this on a 27" iMac, full screen, resulted in 58fps, running the nightly build of FF.

It is pretty impressive to see the quality of the rendition and all this done in a browser. For a large number of games this could avoid having to code for a particular operating system. The question I have is whether we will see games written in JS or written in another language and then trans-coded to Javascript for deployment?

The other question is whether we will see a new packaging format that is cross-browser, that would make it more practical to distribute these applications? Maybe something based on zip, like Java does for its apps?

BTW just a clarification, since I see a previous poster making a frequent mistake: Javascript is not the same thing as Java (see here). Put the name confusion down to some historic marketing ploy.

It is pretty impressive to see the quality of the rendition and all this done in a browser. For a large number of games this could avoid having to code for a particular operating system. The question I have is whether we will see games written in JS or written in another language and then trans-coded to Javascript for deployment?

Probably we'll see various approaches. Turbulenz just open sourced a complete JS game engine for example, but you can also compile parts of a game engine from C++ (like the physics part, using say Bullet or Box2D) or a whole game engine like Epic, Nebula3 and Unigine have shown.

Quote:

The other question is whether we will see a new packaging format that is cross-browser, that would make it more practical to distribute these applications? Maybe something based on zip, like Java does for its apps?

You can already ship gzip-compressed code on the web using webserver+browser support for gzip. And you can ship binary files as well in modern browsers. The Epic demo here for example ships the game assets in a binary file, as well as the heap initializer. So you can distribute code fairly efficiently already, and can then cache things using IndexedDB to avoid downloading more than once, etc.

Ran just fine for me on Firefox (not nightly) on Ubuntu 12.04, 64-bit. Benchmarked at 18 fps (!) on a two-year old Core i5 notebook, Intel HD 3000 graphics. Ran noticeably faster in some areas, a bit under in the large outdoor ones. Not bad, actually.

I'm probably wrong here... but from my somewhat limited understanding, all JavaScript-based web applications are not really 'compiled', and basically anyone who's displaying the web app in their browser can check the entire source code...

While I'm aware that this excludes code executed on the server (i.e. PHP, ASP.NET etc.), with this example it's mostly interpreted client-side code which can be seen by everyone.

Isn't this a major issue that would make businesses hesitant to invest time in making serious web applications -- or games -- with the intention of making profits? Am I missing something?

Raw source javascript is a pretty rare thing these days, for anyone making a seriously performant production application at least. The code you see is going to be minified/gzipped javascript. With these games I'm betting a lot of it is going to be compiled to javascript from C/C++ too. So it will almost certainly be incomprehensible/unmaintainable garbage. asm.js, the fast javascript subset they're using here, is even worse, with tons of weird notations and quirks to help the javascript interpreter do more efficient static compilations. It would be easier to steal/modify than a binary, certainly, but it would still be a nightmare to properly use it.

Game devs also tend to work on source that is technically freely available, but is simply not licensed for free use. Any legitimate competitor wouldn't be able to use their code, and reverse-engineering would probably take more energy than just re-inventing the wheel. Cloning via asset swaps is in some sense a concern, but clones spawn even without the source.

So basically piracy is probably the biggest concern, but as long as part of your functionality is tied back to the server (as most webapps inevitably are), stealing it would be... tricky. Granted, server APIs have been replicated and circumvented on native desktop applications. However with webapps there's generally more streaming of content going on. Games like SimCity are basically entirely there on your computer when you download them. With a webapp, a hack to work locally, or on a pirated server, would have to be a bit more sophisticated, I think.

Further, a lot of games on the web (usually flash) in some sense can actually rely on being "stolen", in that they use in-game ads or other mechanisms to generate revenue just based on usage. When I was working with people in this model a few years back, the margins were basically horrible though (single-digits thousands of dollars is "big", maybe double digits thousands if you've got established IP), so that's probably not a great model to try to replicate. And that's GROSS profits.

Source: I've done a few years of contracted web-based game development in both Flash and HTML5. I also help teach the webapps course at my university.

Kyle Orland / Kyle is the Senior Gaming Editor at Ars Technica, specializing in video game hardware and software. He has journalism and computer science degrees from University of Maryland. He is based in Pittsburgh, PA.