22 December 2015

The quest for WebGL - part 3

Find part 1 here. Find part 2 here.

So we have our semi-working webgl build. I still had to re-enable parts of the code that I commented out, so the adventure isn't over yet :)

A bug with RawImage

In our dialog system we use images to represent the player and the NPC's talking to each other:

But on the webgl build the scale of the images were completely wrong. I made a separate project and could reproduce the problem, resulting in a bug report that the QA people of Unity could confirm:

In the code we assign a texture to a RawImage object and then call "SetNativeSize()", but as you can see this doesn't happen correctly in a WebGL build. See here for the development on that. In the meantime I changed the code to use an Image instead of a RawImage. Instead of a texture for the RawImage, we now need to create a sprite from the texture and assign that to the Image which works, so I'm in the clear for now.

The battle with memory

Our game is a memory hungry monster, when we load the first scene Firefox takes +/- 1.8GB of memory! And that's without the asset bundle memory leak problem from my previous post. That problem has been solved since 5.2.3p1, but it appears that there are still some issues, the memory doesn't leak anymore, but it still takes a lot; Firefox goes to 3GB when we load the assetbundles in the cache. In other words, not usable yet.

So obviously a lot of memory is going to the assetbundles, but how much? Why? And where does the rest go to? I asked on the Unity forum for some leads on this. I learned that surfing to "about:memory" in Firefox gives you a complete breakdown of its memory use, cool! But apart from "a lot of memory goes to javascript handling" I learned nothing useful from that.

To limit the javascript impact on memory it is key to have as little code as possible, and certainly to have very few to no plugins, since they can drag in a lot of .Net code that you don't even use. We removed the UniWeb plugin from our game, since we don't use it in the webgl build and the uncompressed development build size went from 195mb to 119mb! That didn't translate to a big difference in Firefox' memory abuse though.


Audio seems to be an issue by itself on WebGL. As the manual clearly states, audio is handled completely different compared to the other platforms, and unfortunately it shows. In your project, if you use wav, mp3 or ogg exports of the same audio file, they should all sound the same, which they do in the editor, windows standalone and webplayer builds, but in WebGL there is a difference between the three! I found that mp3 files are best when targeting WebGL, but it still strikes me as odd why there would be a difference since they are all converted to AAC.

5.3.x headaches

And then finally Unity 5.3.0f4 was released! Hurray! Lots of fixes and improvements!

Or at least that is what was promised, but it was the opposite.


So that's it. I got until the end of the year to create a decent WebGL version, but because of all the bugs in Unity (most not even WebGL related) I cannot in good conscience declare that I have a WebGL build that is remotely ready to go to the production branch. I'll have to abandon this endeavor and instead we'll create a standalone build with an installer and hope that users will not complain too much about that.

I hope I find time here and there to continue because I still believe it should be possible, but first Unity will have to get their shit together. Where Unity 4 was a stable engine, Unity 5 is biting your nails every time there is an update and hoping nothing obvious went broken.

So I'm a bit disappointed yeah.

No comments: