- You said it brings improvements to memory management - does that mean we as users would get more control of loading and unloading things like textures from memory?
Mainly I was comparing it to a major limitation of asm.js, where by default you get a fixed amount of memory, and that's it. This is a pretty major shortcoming for a game engine since nobody can easily tell how much memory they'll need in advance, or if it might still exceed that in rare cases. Also you can't just set it really high, because it always uses that much memory, even if it is only using less. I think you can enable memory growing in asm.js, but last I looked it had a bunch of caveats and reduced performance. AFAIK WebAssembly aims to solve this problem properly, where memory can automatically grow (and possibly shrink) to match the requirement and not impact performance.
Anything that can be done with textures can already be done with WebGL, it's not really related.
[quote:2yrvin8h] - When you talked about the possibility of rewriting the event system in it, how far would that extend? Would that cover behaviors as well? Would people be able to make third-party extensions using it as long as they had the tools?
I don't know really, this whole project is still just an idea. I would lean towards no, all plugins and behaviors would be written in normal JS, because it's so much easier (JS is easier than languages like C++ and the development process is far simpler without needing ahead-of-time compilation, especially if you get in to debugging). However there is still uncertainty about what the WebAssembly <-> JS transition performance overhead is, which could kill that. Individual plugins and behaviors could still use asm.js/WebAssembly if it benefits them, like Physics already does. Another open question about WebAssembly is if it can elegantly handle multiple WebAssembly programs in the same page.
[quote:2yrvin8h]- In particular I'm interested in collisions - I have a lot of scenarios where using collision cells is either difficult, unfeasible or complicates my code, so any speedup there would be helpful.
Collision cells are an automatic internal engine feature and it doesn't need you to do anything different, so what exactly is difficult/infeasible/complicated about that?
[quote:2yrvin8h] - Rendering - I acknowledge my ignorance on the subject, but since webGL is written in javascript, it seems plausible that it could help with the performance impact of the draw calls or other such elements of preparing the scene for rendering, even if it wouldn't speed up rendering itself?
Yes, it could speed up draw calls, but I don't think it's worth it - usually draw calls are not a bottleneck, in cases they are there are still ways we can optimise it in normal JS, and draw calls are issued by plugins which are typically written in normal JS.
[quote:2yrvin8h]- Physics - because webAssembly needs to be compiled to from another language like C similarly to asm.js, would it be a comparatively simple task to compile the physics for webAssembly to get the 20-30% speed boost (if, of course, it's really that much faster)?
Right now nothing involving asm.js/WebAssembly seems straightforward, because they are not really mature technologies yet so it's easy to run in to roadblocks. So probably not. But I doubt there would be a huge improvement anyway, asm.js is pretty good as it is.
In short, this is still just an idea, there are a lot of details and uncertainties to be figured out, particularly around third-party plugins.