3 ms·

(on Scaling) Games usually scaled based on GPU power, but not so much on the core game logic, AI, etc. Any CPU processing that actually affects gameplay outcome

(on Scaling) Games usually scaled based on GPU power, but not so much on the core game logic, AI, etc. Any CPU processing that actually affects gameplay outcome (e.g. collision detection) cannot really be disabled and scaled. Otherwise, you end up playing a different game based on your machine, not a game that only looks uglier or plays choppy. This demo looks great, but all I see are environments rendered. I didn't see any firefights between lots of player models or vehicles, no Havok/PhysX/Bullet, I didn't see any enemy AI running. I did see some frame rate hitching. It's not the first time someone's had environments (sans game) running, see for example Quake3 (http://media.tojicode.com/q3bsp/ http://media.tojicode.com/q3bsp/). Even the Rage Engine got an environment renderer ported to the Web. There's a danger in overselling stuff. When I helped port Quake2 to the Web (GwtQuake), I didn't have any illusions about being able to run something like Crysis or Call of Duty series in the the browser in JS, or consume the same resource requirements. I mean, I thought it would be possible, but a hideous waste of system resources. There was a time when Sun was marketing Java and pushing heavily on this idea that it would one day meet or beat C/C++ performance, but it never quite got there after 2 decades (yes, in some circumstances it comes close, in others, it fairs badly). I see the same parallels today, pushing the idea that a dynamically typed language with some extra 'hints' is going to match a language that gives full control over memory, SIMD, layout, threading, etc. This is not to say that asm.js couldn't do most of the 'casual' games you see today (e.g. Ridiculous Fishing on iOS, Angry Birds, etc), and most of the Flash games, I'm totally onboard with using it for that, but I think it's a mistake to push this as a real solution for bringing triple-A FPSes to the web. And what of Mobile? Can this even run Infinity Blade on a recent smartphone? What would be the different in battery life between an iOS version and an asm.js version?

jlongster 14y ago
Have you seen BananaBread? It is a fully runnable 3d game that does all the AI, physics, etc. It's compiled with emscripten (I'm not sure if the online version uses asm.js yet, but it just needs to be recompiled). https://developer.mozilla.org/en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread
- cromwellian 14y ago
  Yes, I've seen it, but "physics" in this case means ragdoll physics, it's not like Havok/PhsyX or anything that modern game engines uses. These things are impressive for Web demos, but the question you need to be asking is, what would someone who visited GDC or E3 to see console or desktop games say about it? Would they pay $39 for it, or would they think it looks like a toy compared to what the other vendors are showing? End users don't care what something is implemented it, how open it is, all the stuff that hackers care about. All they see is a game, and they will compare it to other games that are implemented with different technologies. You won't get bonus points because you managed to implement it in a difficult environment.
  - jlongster 14y ago
    This is all early stuff, yes. We aren't quite at the point yet where people can sell AAA games for $40 on the web. But I wouldn't be surprised if it happens, and what we are showing that it's certainly possible with some more work (not a huge amount, either). End users could benefit greatly; just click on a URL and immediately start playing a game! The game needs to be on par with native, yes, but if we can pull this off there are huge benefits for distributing over the web. Note that the Bullet physics engine was compiling with emscripten into a library called "ammo.js" and is somewhat of a standard for 3d games on the web.
    - mtgx 14y ago
      Since WebGL uses the same graphics API as the mobile devices right now, you're only going to see mobile apps being ported to. It just gives developers one more platform to port to.
pcwalton 14y ago
> It's not the first time someone's had environments (sans game) running, see for example Quake3 (http://media.tojicode.com/q3bsp/ http://media.tojicode.com/q3bsp/). Quake 3 was released in 1999. Unreal Engine 3 is a current and top-of-the-line engine for AAA games. > There was a time when Sun was marketing Java and pushing heavily on this idea that it would one day meet or beat C/C++ performance, but it never quite got there after 2 decades (yes, in some circumstances it comes close, in others, it fairs badly). This is totally different. asm.js is just a backwards compatible encoding of a different, much lower-level language. In fact, that lower-level language is in direct correspondence with the intermediate representation of a production-quality C++ compiler (clang)! Sun never tried something like asm.js for Java; rather they claimed that the full language would be as fast as C and C++. > memory, SIMD, layout, threading asm.js gives full control over memory and full control over layout, with the exception of stuff like mmap() and mprotect() and self-modifying code. SIMD is something that RiverTrail/ParallelArray can do. It should be added to asm.js. As for threading, I'm personally in favor of an extension to allow a typed array to be shared between workers, races and all, with some primitives to allow synchronization. Not everybody is OK with this, but I personally believe we aren't likely to get to native performance without it. (Again, this is just my personal opinion; many disagree on whether a racy typed array is necessary.)
- cromwellian 14y ago
  You can polyfill SIMD, but you can't polyfill threads. Once you add shared memory between workers, you've effectively violated the premise that asm.js will run everywhere, even places that don't understand it. In that case, you've got a portable intermediate representation of opcodes in a bloated legacy format, that is now incompatible with legacy runtimes. Why use JS format then?
  - pcwalton 14y ago
    Apps could feature detect threading and fall back to single-threaded mode for compatibility with non-asm browsers if it's not supported. Regarding the claim that asm.js is "bloated": http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling...

jlongster 14y ago

Have you seen BananaBread? It is a fully runnable 3d game that does all the AI, physics, etc. It's compiled with emscripten (I'm not sure if the online version uses asm.js yet, but it just needs to be recompiled). https://developer.mozilla.org/en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread

cromwellian 14y ago
Yes, I've seen it, but "physics" in this case means ragdoll physics, it's not like Havok/PhsyX or anything that modern game engines uses. These things are impressive for Web demos, but the question you need to be asking is, what would someone who visited GDC or E3 to see console or desktop games say about it? Would they pay $39 for it, or would they think it looks like a toy compared to what the other vendors are showing? End users don't care what something is implemented it, how open it is, all the stuff that hackers care about. All they see is a game, and they will compare it to other games that are implemented with different technologies. You won't get bonus points because you managed to implement it in a difficult environment.
- jlongster 14y ago
  This is all early stuff, yes. We aren't quite at the point yet where people can sell AAA games for $40 on the web. But I wouldn't be surprised if it happens, and what we are showing that it's certainly possible with some more work (not a huge amount, either). End users could benefit greatly; just click on a URL and immediately start playing a game! The game needs to be on par with native, yes, but if we can pull this off there are huge benefits for distributing over the web. Note that the Bullet physics engine was compiling with emscripten into a library called "ammo.js" and is somewhat of a standard for 3d games on the web.
  - mtgx 14y ago
    Since WebGL uses the same graphics API as the mobile devices right now, you're only going to see mobile apps being ported to. It just gives developers one more platform to port to.

pcwalton 14y ago

> It's not the first time someone's had environments (sans game) running, see for example Quake3 (http://media.tojicode.com/q3bsp/ http://media.tojicode.com/q3bsp/). Quake 3 was released in 1999. Unreal Engine 3 is a current and top-of-the-line engine for AAA games. > There was a time when Sun was marketing Java and pushing heavily on this idea that it would one day meet or beat C/C++ performance, but it never quite got there after 2 decades (yes, in some circumstances it comes close, in others, it fairs badly). This is totally different. asm.js is just a backwards compatible encoding of a different, much lower-level language. In fact, that lower-level language is in direct correspondence with the intermediate representation of a production-quality C++ compiler (clang)! Sun never tried something like asm.js for Java; rather they claimed that the full language would be as fast as C and C++. > memory, SIMD, layout, threading asm.js gives full control over memory and full control over layout, with the exception of stuff like mmap() and mprotect() and self-modifying code. SIMD is something that RiverTrail/ParallelArray can do. It should be added to asm.js. As for threading, I'm personally in favor of an extension to allow a typed array to be shared between workers, races and all, with some primitives to allow synchronization. Not everybody is OK with this, but I personally believe we aren't likely to get to native performance without it. (Again, this is just my personal opinion; many disagree on whether a racy typed array is necessary.)

cromwellian 14y ago
You can polyfill SIMD, but you can't polyfill threads. Once you add shared memory between workers, you've effectively violated the premise that asm.js will run everywhere, even places that don't understand it. In that case, you've got a portable intermediate representation of opcodes in a bloated legacy format, that is now incompatible with legacy runtimes. Why use JS format then?
- pcwalton 14y ago
  Apps could feature detect threading and fall back to single-threaded mode for compatibility with non-asm browsers if it's not supported. Regarding the claim that asm.js is "bloated": http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling...