10 ms·

I think this is due to competing native platforms for 3D graphics (e.g desktops and mobile clients) and lack of tooling. The browser has historically worked ver

by neovive 11y ago

I think this is due to competing native platforms for 3D graphics (e.g desktops and mobile clients) and lack of tooling. The browser has historically worked very well for static/text content and 2D graphics and building developer mind-share for a new platform is hard. However, the new WebGL export option in Unity 5* should result in more WebGL games and simulations. * https://blog.mozilla.org/blog/2015/03/03/unity-5-ships-and-brings-one-click-webgl-export-to-legions-of-game-developers/ https://blog.mozilla.org/blog/2015/03/03/unity-5-ships-and-b...

yoklov 11y ago
As someone who uses the Unity WebGL export in production, it's a long way away from the point where you can simply build a game in Unity, deploy with WebGL, and expect it to work reliably. It took us several months of optimizations, rebuilding assets, etc. to get it to a marginally viable state, and even then I wouldn't call it reliable. As it is it will usually work on maybe 50% of computers. More if the game is minimal (this is the case with most, if not all, of the online demos). A lot of this is due to patchy WebGL support and the fact that ASM.js's viability is mainly due to politics, not due to it being a good solution in practice. The computers it does work on, frequently you'll get an out of memory error, since you can't resize the memory arena in ASM.js (well, you sort of can but it makes the code much slower, and the resize operation frequently will crash the browser tab). You can mitigate this by requesting a larger memory arena, but in our testing, any size above 128MB fails to work on about 20% of machines. The parsing time for the ASM.js code is also so long that frequently browsers will ask if you want to kill the tab, because the page has been unresponsive... And when the browser is actually parsing the code, it will usually allocate over a gigabyte of memory. (Even firefox, which supposedly has a more optimized parser for ASM.js code). This is ignoring browsers like Safari, IE11, and Edge (not to mention mobile), which all have their own sets of problems. I don't really know where I'm going with this, other than to say that from the people I've talked to, this is pretty much the experience of everybody who has tried to ship anything nontrivial with Unity WebGL. I've heard that Unreal's HTML5 export is similar, but I've never used it so I can't confirm.

by neovive 11y ago

yoklov 11y ago

As someone who uses the Unity WebGL export in production, it's a long way away from the point where you can simply build a game in Unity, deploy with WebGL, and expect it to work reliably. It took us several months of optimizations, rebuilding assets, etc. to get it to a marginally viable state, and even then I wouldn't call it reliable. As it is it will usually work on maybe 50% of computers. More if the game is minimal (this is the case with most, if not all, of the online demos). A lot of this is due to patchy WebGL support and the fact that ASM.js's viability is mainly due to politics, not due to it being a good solution in practice. The computers it does work on, frequently you'll get an out of memory error, since you can't resize the memory arena in ASM.js (well, you sort of can but it makes the code much slower, and the resize operation frequently will crash the browser tab). You can mitigate this by requesting a larger memory arena, but in our testing, any size above 128MB fails to work on about 20% of machines. The parsing time for the ASM.js code is also so long that frequently browsers will ask if you want to kill the tab, because the page has been unresponsive... And when the browser is actually parsing the code, it will usually allocate over a gigabyte of memory. (Even firefox, which supposedly has a more optimized parser for ASM.js code). This is ignoring browsers like Safari, IE11, and Edge (not to mention mobile), which all have their own sets of problems. I don't really know where I'm going with this, other than to say that from the people I've talked to, this is pretty much the experience of everybody who has tried to ship anything nontrivial with Unity WebGL. I've heard that Unreal's HTML5 export is similar, but I've never used it so I can't confirm.