Slashdot Mirror
Epic and Mozilla Bring HTML5 OpenGL Demo To the Browser
sl4shd0rk writes "Mozilla and Epic (of Epic Megagames fame) have engineered an impressive First Person OpenGL demo which runs on HTML5 and a subset of JavaScript. Emscripten, the tool used, converts C and C++ code into 'low level' JavaScript. According to Epic, The Citadel demo runs 'within 2x of native speeds' and supports features commonly found in native OpenGL games such as dynamic specular lighting and global illumination. This concept was previously covered on Slashdot, however the Citadel demo has just been released this week."
Using Firefox 20 on Linux, I get browser not supported.
Cross platform compatibility at its finest. Not that I really wanted to peg my i7 cores with Javascript, but...
They need to get it working one browser first. They chose Firefox. Its not my preference of Chromium or your preference of IE6, but its a start.
This comment shows an amazing understanding of the article and it's contents, clearly a Slashdotter for the ages.
With the exception that even the "best view" lags like hell.
Dunno. I think Chrome, Chromium, Safari and a few others could've been done in one throw of a stone.
Well you can try it in Chrome, but right now Chrome crashes when you do.
They also don't prevent you from trying it in any browser (AFAIK) except pre-23 versions of Firefox.
This requieres Mozilla JS enhancements (asm.js) currently on nightly builds, It can work on other browsers but without the performance tuning made for the JS subset that is asm.js it will run slow. Chromium bug proposing to add support for asm.js http://code.google.com/p/v8/issues/detail?id=2599
It died. RIP little instance.
This demo is plain Javascript, but only uses as subset of it (asm.js), the VM needs performance enhancement to run (asm.js) efficiently so it is not an easy task to support other browser, unless you call "supported"to run it very slow http://code.google.com/p/v8/issues/detail?id=2599
They wrote the demo according to web standards, and it only worked in Firefox. Now they need to fix bugs in the other browsers, not in the demo.
I won't mod you down, but I will call you out for being a massive dickhead. You massive dickhead.
For some reason the people here don't understand immediately what this is: A tech demo.
asm.js is experimental. html5 is very new. WebGL is not that widely used yet. emscripten. This is just demonstrating what is possible with what we have today.
I tried it on linux with intel 4000 with mesa git master and firefox nightly.
I haven't looked into why the rendering in the default settings is bad. Maybe they still blacklist it.
To get decent performance I had to go to about:config and set layers.acceleration.force-enabled to true.
Then the rendering is really smooth. And with really smooth I would be happy with this performance in any game. At 1920x1080. With intel integrated graphics on a mobile cpu.
For some reason disabling vsync is not so easy. I have tried setting layout.frame_rate to 500 (was -1, so maybe auto or off) like they say in the faq and started firefox-nightly with vblank_mode=1 but still didn't get much more fps. Maybe I also need to disable kwin vsync? Or maybe it just was the maximum perfomance, but I find it hard to believe that the maximum is by chance so close to 60 fps.
This is what "benchmark" says:
http://i.imgur.com/sWdSC16.png
And yes, this was without anti aliasing and didn't look too good because of that. It also had some tearing issues but that was maybe because I tried to disable vsync.
A 3D environment running in my browser, without Flash or some proprietary plugin not available on Linux? And all on fully free software stack*? I'm impressed. It runs smoothly in full screen as well.
* Excluding the game assets obviously.
Oh God no!
We've finally reached the "Best NOT viewed on Internet Explorer" days, and it's about time.
If you'd read the links, you'd know that this is new technology being created by the Mozilla folks and being debuted in Firefox first. It's open source (as would be expected from Mozilla) and available to every other browser maker. It uses a subset of JavaScript that's specially compiled to run very fast in the optimized Firefox engine. It's still valid JavaScript, though, so it will run in other browsers, just slower. Some browsers like Chrome can't handle it and crash at the moment. There's already a feature request to add this into Chrome/Chromium. And, since it is in Firefox, it'll be in Firefox OS as well, making gaming on Firefox OS cell phones more of a possibility than it was before.
Portable versions of Firefox, GIMP, LibreOffice, etc
Let me get this straight.
They (the asm.js nutjobs and the vendors who trot along) are proposing to take programs written in C or C++, "compile" them to the fascist brother of Javascript (I won't call it a "subset" of the language because it actually works by adding boilerplate code) so that supported implementations can recognize that the Javascript source has all the boilerplate cruft in place and try to compile the damn thing back to machine code.
Rube Goldberg would be proud.
Besides, I can see the security chasms opening as we speak
Nope, because these are just experiments, not final code.
These are experiments by groups of people that may or may not reach a final standard for the web.
Experimentation drives creation and standardization.
And now that most have agreed to, browser prefixes are going the way of the dodo so you don't see website developers adding prefixes all over their websites that end up breaking when they get removed.
People will now, again, need to directly enable experiments in the expert pages of their respective browsers.
Prefixes were a nice experiment, but it just resulted in a mess because people implemented them as if they were standard.
What the hell does "within 2x of native speed" mean? Is it 2x faster? Is it 2x slower? Is it 200% faster/slower? Is it 50% slower?
If only there were a marketing-to-English dictionary, or perhaps a school we could send people to ...
Is there any way to invert the mouse controls? You know, up/down? Stupid kids and their non-inverted controls...
So it's a ‘subset’ of JavaScript but for it to be useful (or in this case, work at all) you need to have extensions in your browser so it actually isn't even a superset - it's a completely different language. Also on the surface it looks like the only place where HTML is involved is to provide a place to put the OpenGL graphics. And obviously it won't run near twice native speeds but (if you have a special browser) near half native speeds.
So almost every sentence in the summary is wrong, to create a picture of this wonderful thing that can be done within web standards, whereas almost the complete opposite is true. You need a special browser for this and even then performance is shitty.
If this really takes off (it's now only in it's early stages and still is only 2x slower than C/C++!) then we could really see the YOTLD for real (+Steam gaining more GNU/Linux games). Also now with Android more devs are ditching DirectX and Windows specific engines. The C/C++ -> JScript seems like a quite amazing hack, hope it isn't as riddled with potential exploitation's as i fear. Great work Mozilla!
Were you also ranting against Chrome Experiments during the one or two months it ran exclusively on Chrome?
standards.
welcome to the open webz
I just tried, and I was able to "play" the demo, walking around the environment, etc. I ran the benchmark, and got 57fps, and although I have 120hz monitors, I suspect something is limiting most of the rendering to 60hz. TBH, this is amazing to me. I tested under windows 7 with firefox 20.0.1 however, so I'll have to try booted into Ubuntu and see how it works there.
This requieres Mozilla JS enhancements (asm.js) currently on nightly builds, It can work on other browsers but without the performance tuning made for the JS subset that is asm.js it will run slow. Chromium bug proposing to add support for asm.js http://code.google.com/p/v8/issues/detail?id=2599
It doesn't require special asm.js optimizations (asm.js is a subset of JavaScript, so it already runs properly in all modern browsers). The demo works fine in the stable release of Firefox for example, which has no special asm.js optimizations. It is faster in Firefox nightly though which does have those optimizations. But how much faster depends on the CPU and GPU, it might matter a lot or it might matter a little. In this demo a lot of time is spent in WebGL, so a fast GPU and good WebGL implementation matters a lot too.
The demo should work in any browser with WebGL and JavaScript support. For example the only reason it currently fails in Chrome is due to a bug related to memory use. Hopefully that will be fixed soon.
The difference between asm.js with and without special optimizations is not necessarily that big. See benchmarks here, showing it can be anywhere from 1x (almost no change) to 5x. It depends a lot on the benchmark. And in a demo like this, the GPU matters a lot too, which makes asm.js matter less.
So all modern browsers should already work on this demo. But this is a very large codebase (over 1M lines of C++ compiled to JS), and it pushes the limit of what browsers have tested on. Now that this demo is public, that should make it easier for other browsers to fix what they need so the demo can work on them.
All we've ever really wanted was a unibiquitous software development platform that wasn't bloated as hell and allowed optional access to the local file system (for save data / load data). Java could have been this, but they didn't make Applets be trimmed down lean and mean for the web, and included the kitchen sink so the attack surface was too large. HTML+JS is becoming what we want, if it wasn't for the horribly designed scripting language -- Its design had no concern for speed since all the heavy lifting was to be handled by Java, hence "JavaScript"... Unfortunately since Sun dropped the Java ball, JavaScript is left to take up the reigns. Instead of redesigning it, or giving us a new language to use in all common browsers that could be compiled to bytecode -- Lua w/ LuaJIT? (well, one that is more friendly, perhaps).
Anyway, as a game developer I've experimented in HTML5+JS+WebGL, but you know what's holding me back? Two things: IE support for WebGL, and HTML5 Audio: Look, It takes just as long to code the thing in OpenGL and C than WebGL and JS, and afterwards I can reach the whole market, not just the FF / Chrome market, and I can control the damn audio pipeline properly -- By whole market I mean my code runs on Linux, Mac, Windows, natively. With a bit of meta programming and some purpose built "platform abstraction layer / runtime" I can create programs that deploy to iOS and Android as well as the desktop OSs... I can add Firefox and Chrome as a target platform, if only AUDIO wasn't screwed. Play a sound, then play it again while it's still playing. There's noticeable lag even if you remember to seek to the beginning so your sound actually plays. To combat this I create 10 or so of the same exact same audio tag for one sound effect and loop through them so that I'm not re-using the same audio tag... And it still stutters and pops and lags -- This time because we've got 100s of audio tags to maintain, and the scripting host is too damn slow to keep buffers full, apparently. Notice how the Citadel demo is lacking any sound effects except a single looped sound playing fades out at either end? And even then it cuts out in the middle instead of transitioning smoothly to the next area -- Shit, even I can pull off a dynamic audio fade transition, with just two audio tags (WTF are you even doing Epic? It's unreal you'd make this newb mistake). Yeah, there's a reason for the lack of interactive audio effects, and that reason sucks -- I guess I'm wearing pillows on my feet?
I think the web is an interesting platform -- browsers can provide access to machine features through OSs (add another abstraction layer: meta programming, ugh), but the only reason the web is interesting at all is because of the huge adoption rate of web browsers which we can leverage. Everything else about them sucks. JS is used because it's there, not because it's any good. Hell, I could say the same thing about HTML -- It's not any good. Come up with a low level bytecode interactive glyph and shape rendering system and allow us to compile sites down into that, then we can have freedom to escape the 1.5 decade long march it takes to get from one version of HTML to the next by creating better markups that compile down to efficient cross platform display and animation bytecode. Yeah, like Flash, but browsers could compile HTML, CSS and JS, or support faster pre-compiled stuff. Otherwise, screw the web, Apps will eat you alive. Text can be embedded there for search spiders, and they'd have an even easier time lexing past bytecode to get at text rather than We can't afford to keep tweaking crap just because a browser changes the way it renders some tags -- Even some designs on CSS Zen Garden are broken in FF now. Ugh. Give us a binary SVG already, with pixel perfect definition for rendering, it's not rocket science.
Interesting, but the web isn't ready for large scale games just yet without plugins because of its flaky audio and inefficient scripting language (even with ASM.js). Stic
Mozilla & Epic worked together on this together.
They used Emscripten, which Mozilla developed, to compile to asm.js, which Mozilla developed and put an optimized module in Firefox's Javascript engine.
So I'd say it's little more than Epic choosing Firefox.
It performs fine with just JITing, and amazingly (for a C++-to-JS ported codebase) with asm.js.
Can't wait to try this. Citadel is one of my all time favourite games!
Tried the demo and it's actually pretty surreal being able to play a game like that in a web browser. I hope the technology improves further as time passes. One issue is that it cannot capture the mouse in fullscreen meaning you have to click in order to turn the camera. This would be a big problem playing windowed of course but in full screen, it's more intuitive just to move the mouse to turn around (like every FPS has implemented).
I tried the demo. It feels extremely slow despite very low CPU usage (15%) and a high-end graphics card.
It might be a problem with latency or responsiveness, but it's definitely not as smooth as an AAA game.
Graphics-wise it also feels like an Android game.
Shitty flash games actually look better than this.
Then show us a flash game that looks better than this.
Uh, guys... This is waaay old news (as in several months old...). I was suitably impressed they got the demo working and it IS something to talk about, but March wants it's story back.
Apparently this is another proprietary codec. Brendan Eich considers this unimportant because "consumers" won't get sued for using the browser, but it leaves people who want to participate (by encoding their own material) my have the same limitations that h.264 users do - no participating unless you pay the Intellectual Property Poll-Tax.
It sounds like they're still in "discussions" about the licensing of the codec itself. Unfortunately I'm not too confident that Mozilla is concerned much about that these days - they seem to be starting to fall into the same "consume-only" mindset that Microsoft, Apple, and Google seem to these days...
Hacker Public Radio is our Friend
So all modern browsers should already work on this demo.
Except for IE10 of course. IE11 might have WebGL.
It is C++ compiled into "javascript" that is basically equivalent to LLVM bitcode, which the browser will compile into machine code.
It worked for me using FF20.0 on Lubuntu12.10. Since I have a HP dv6 I have the infamous Optimus tech with a 650m. The first go around I ran FF as usual and got an average of 26 FPS. Then I thought that I would get better perfomance using optirun firefox.... NOpe! Average FPS, 18.... wtf?!
It does lens flares ... badly.