I wish google would stay on board with JS since they have the engineering power to do a lot in this area, but to me it seems after V8 they've kind of abbonned JS in favor of Dart (As oppossed to supporting asm.js). For instance, I just did the "try anyway" in chrome 26.0 linux and everything crashed. Did anyone get it working in chrome?
- Chrome currently crashes, but is expected to be resolved by the Chrome team soon.
Crashed my whole system
Chromium 25.0.1364.160 Ubuntu 12.04
Where did you get that idea? Just look at these graphs:
http://www.dartlang.org/performance/
Apparently, they are still trying to make V8 faster. V8's graph isn't flat and there are also very recent bumps.
>As oppossed to supporting asm.js
Asm.js is about JavaScript the compiler target, not JavaScript itself. Using asm.js means writing code in C/C++ (or something similar), which means it's more comparable to PNaCl than Dart.
It is still just javascript and totally readable as such.
For example: https://gist.github.com/calvinmetcalf/5473022
Haven't they announced that they have no plans to integrate the Dart VM with the Blink rendering engine?
You make it sound like they're the only ones doing this kind of thing. Anybody remember this?
www.findyourwaytooz.com
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.
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, only better. Because Diablo 3 should be easier to crack and play on private servers (not sure if even that has happened yet).
Making an "online game" instead of a native "PC game" is the best way to stop most of the piracy.
The piracy while a legitimate problem is a relatively minor one. The first is visibility, the second is quality. Getting to the point where someone bothers to pirate your stuff and the majority of people that download it install it and play trough it is a mark of success - doing something right.
And with sizable proportion of the gaming community in their 30s - you will be surprised how many people have desire to support the studios. We learned our lessons with Shadow of the colossus, Psychonauts and the fate of Black Isle.
Additionally, asm.js is not part of HTML5. It's interesting, and this demo is cool, but it's not JavaScript/HTML5.
It is faster with asm.js optimizations, but as other comments mention, it also runs well (depending on CPU/GPU) even without such optimizations, in browsers that have no special asm.js optimizations whatsoever.
All the demo needs to work is WebGL and JavaScript.
> The source is emphatically NOT JavaScript, it's a subset that's meant to be a target for compilation
It is not 'typical' JavaScript, but it literally is JavaScript since it's a subset.
> (like a bytecode in .NET and the JVM) and is treated entirely differently from JavaScript by the JIT.
Only in some cases (Firefox 22 and 23) is it treated in a special way, and as mentioned above, the demo works great in other cases as well, that treat it like normal JavaScript (Firefox 20 stable, for example).
Even when it is treated in a special way, it still uses the same parser and same backend and optimizations (IonMonkey) as the Firefox JS engine uses for all JS.
> We don't call everything that runs on .NET C# nor everything that runs on the JVM Java.
The main difference is that .NET and the JVM have bytecodes. C# is not .NET bytecode and Java is not JVM bytecode. But, JavaScript does not have a universal bytecode, there is just the language itself.
So asm.js is literally JavaScript, not some lower-level bytecode. It runs like normal JavaScript, the only difference is that some JS engines might optimize it a little better, since it's easy to optimize.
Note that asm.js-like code is nothing new. It's been generated for years now by compilers like Emscripten and Mandreel, and Firefox and Chrome (and likely others) have been optimizing for it, for example Google added a Mandreel benchmark to Octane. (The only thing new with asm.js is that there is a formal typesystem which makes it simple to make sure you emit proper code, and simple to verify you are receiving proper code; also, while developing the type system some bugs in how emscripten generates code were found and resolved.)
Actually, that's not true at all. That's the plan for asm.js, but this demo doesn't run in anything other than very new Firefox builds, AFAICT. It crashes chrome, IE doesn't support WebGL (yet).
To correct your analogy: it'd be like using a subset of C# as the bytecode rather than a language. It's still actual C#, it's not just .NET bytecode, but it's being used differently.
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.
Comparatively, this runs a little sluggishly on a MacBookPro8,2 (early 2011).
Demo itself ran halfway ok, clicking on 'Benchmark' (which I had to guess was in the upper pulldown) immediately froze everything for me (Firefox on Kubuntu).
Still: I do appreciate a demo that even kinda-sorta works on gnu/linux.
It is actually both downloading and compiling during that time, and probably spending far more time in the download.
It would be nicer if the text said "retrieving code" as opposed to "compiling code" at that point.
edit: looks like the demo site was just updated, the message is better now :)
It is very refreshing to see something cutting edge work on linux.
I'm using Firefox 20 on Ubuntu 12.04/amd64 and everything works flawlessly.
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 switch to them while the other implementations tries to catch up.
It will also prevent new browsers from trying to pop up, unless they simply fork and try to keep up with one of the two major engines. Google and Mozilla know they can outpace any competitors that are trying to innovate in the web space by having the "latest" html5 features integrated. In example, unless Microsoft pours a bunch of money into it, or Internet Explorer forks Mozilla or Google, they can pretty much count that competitor out.
Is this supporting an open web?
What's the problem with focusing on open source plugin virtual machines that can work in every browser regardless of that browser's version?
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 "specification" is a gift to other engine implementers to super charge evaluation of compliant code.
> Is this supporting an open web?
http://asmjs.org/spec/latest/ http://code.google.com/p/v8/issues/detail?id=2599
Exactly, an open source standardized VM would be ideal, then you would have a choice of languages as well.
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 improve.
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.
As for the demo, I'm stunned. It's incredible.
Still, it's pretty amazing.
Is anybody able to get it running on android? The nightly has both asm and webgl but is showing up as unsupported (and not just doing UA sniffing).
https://twitter.com/vvuk/status/330119715546624000
some known bugs that cause us to use way too much transient memory while loading. Fixes incoming.edit: although there is no path finding
I have a gaming desktop at home that runs all new games at 50+ FPS, but for some reason looking at graphics that a late-era PS2/early PS3 game would have _in a browser_ is more impressive than running a game like Crysis 3 for the first time.
I wouldn't be able to play a fast paced shooter like this, but I could see it being more than tolerable for playing a slow paced role playing game or something in the browser, with the added ease of connecting with other players, possibly MMORPG-style.
On a side note, it'd be nice to make it capture the mouse instead of having to drag it.
52 MB of JavaScript is... a lot (even if half of it looks like data tables of some kind)
OS Browser Avg. FPS Min FPS
Win8 Fx 20 26 16
Win8 Fx Nightly 46 34
Ubuntu 13.04 Fx 20 17 16