22 Mar Our Journey to Unity 5 and WebGL
The process of upgrading a large, complex application like Egowall to Unity 5 and WebGL™ is neither as easy nor straightforward as you might think – or hope. Beyond the fact that WebGL is significantly slower than native code, there are many other things to deal with.
We are sharing a series of posts with behind-the-scenes information about our journey on this road. In the articles, we talk about the issues we have encountered during the conversion and how we dealt (and are dealing) with them.
Below are links to all of those posts in a single place. We wanted to make it easy for newcomers to the series to read any or all of them. As additional articles in the series are written, this post will be updated.
We hope you get value from the information contained in the posts. Please share any thoughts you may have in the comments and let us what your path to Unity 5 and WebGL has been like.
In the first post in our series, we talk about Google’s early 2015 removal of support for the Unity plugin in Chrome and the resulting impact on our development process.
The second post covers the art and asset-related issues we encountered during the upgrade and how we dealt with them.
In this third post, we summarize the code base changes we had to make in order to resolve Web Player-related issues encountered during our Unity 5 upgrade.
The fourth post summarizes the results of our performance testing at the end of the Unity Web Player 5.3 upgrade, comparing it to Web Player 4.3.
EGOWall and WebGL (Part 5): WebGL Issues
WebGL and the WebGL logo are trademarks of the Khronos Group Inc.