<cite>@glh3586 said:</cite> I'm curious... what kind of reliability problems are you talking about? Most of the problems i've run into or read about have been about speed.I added a link to my article in order to avoid repeating what I already wrote some months ago, I spoke about the poor performances on Intel chipsets, the numerous drivers in the blacklist, the bad user experience as I had to tinker my settings to test most of the demos and it was not homogeneous accross the browsers... WebGL is not ready for industrial use. I could even update my article as I have found some other problems but it is already very long.
Hi. I am sorry to revive this old topic but I saw this article and was wondering if jME3 intent to try and get this going as well? I know that the asm.js is not for languages that handles there own garbage collection but I think there might be a way? Any input on this?
@nehon
I think it would be a great Idea to go with. I’m just concerned that we make sure to note that web games have to rely on “Remember: streaming assets and code”. So there may be the need to inform folks: “yeppers, make sure to have your awesome model with awesome textures ready… and if the game is needing it now… make sure to have something “good enough” ready until the awesome one can be switched in… oh, and start loading way before you need it. See: Metroid Prime… as a Great Example” I know that the setup for the average jme game is pretty much modular. So, thus should adapt pretty nicely if y’all make the gradle/ant build calls for it.
My only questions are:
Can we “taste” of a machine’s ability? to select between multiple rendering algorithms?
How much “space” do we have to play in? I know we can do a quick check for available mem in Java.
Do we have enough of a distinction between our Low-End and High-End modules to perform the inclusion?
Can we generate the documentation to bring others along with us to play with the new toy?
That’s about all I can think of… I’m game, if y’all are… 
Any plans for WebGL support?
1 Like