Unity Debug Diaries: Radically long load time on Kindle Fire HD
One of the most useful things in day to day game development is to know about those weird gotchas that you find in any complex tech. On top of that, you need to remember said gotchas the next time you encounter them. When developing cross platform games at a fast pace, I have solved problems and completely forgotten the solve the next time I bump into it six months later. Debug Diaries is my first attempt at trying to curb this. When I am faced with a weird problem, I am going to try to fix the problem while writing about it so that I can remember and hopefully, help you too. Here goes…
On doing the Amazon port of our soon to be released game, Thunder Jack’s Log Runner, I found that after adding the plugins to the port, the game took about 5 to 10 mins to load. I have seen this before when loading a lot of textures from resources but can be sure. The last thing I added before the problem was AdColony, which could have pushed me over the memory threshold. Time to pull it out and add some debug logs.
The first thing I did was to switch from my amazon branch to my google play branch to see if the problem was inherent or platform specific. For those who don’t know, most Android builds will work on Amazon devices because they are Android. You just have to watch out for the platform specific plugins.
Result
Same thing. So now, I am going to ignore the platform specific changes and look to shared properties.
Switching back to my Amazon branch, I am now going through my build settings to see if I can find some weirdness. Tip: Command+Shift+B brings up your build settings. I did not find anything in my build settings that stood out. I suspect this is a texture memory issue so I have enabled the 32 bit color buffer and have changed my texture compression settings. I am building for a PowerVR device so I had PVRTC texture compression enabled. iOS is also PowerVR so keeping this texture compression setting greatly reduces platform switching times. Now I am switching to ETC1 (Default Android compression) to see if I get any love there.
Result
Same thing. Stuck on the splash page for 5 to 10 mins.
So now we can rule out Android texture compression settings but looks like its not an easy problem to find. Since I am working in a team its really hard to work backwards to the point that this problem started, especially because we are crunching. But because we are crunching and shoving new assets in as fast as we can, I am going to poke around to see if its something to do with low memory. A side note, I did upgrade to the latest Unity 4 (4.6.4.p1) so it is possible that its a Unity problem, so I am downloading the latest 4.6.4.p2 so see if it helps. Now I am starting the painstaking process of omitting our load time components one by one to find the culprit.
Result
Found a start. I created an empty scene and added in each start up component one by one until the problem occurred. Definitely seems asset related. But what?!?!
I went a little off tangent to figure out how to make my assets smaller. I have a quality manager but I came onto this project and a lot of the assets are either Unity sprites or textures on quads. If we were using tk2d, swapping textures would be a breeze, but alas, no. I started to investigate an old method of managing the quality of mip mapped textures. You can specify whether a mip mapped texture should drop a size using QualitySettings. The size is dropped but the asset is still reporting its original size when profiled on device. But, I was digressing. I need to get back to isolating the problem before I try to fix it.
So, staying true to my previous statement, I drilled down and down. Narrowed and narrowed. Good thing too, because it was not a texture issue, it was a TextMeshPro issue. So now, time ti figure out what. My guess is that the shader has some weirdness… and now I think everything is coming back to me.
Solve
Updated to the latest TextMeshPro 1.4.4. Needed to go through all my text assets and set the shader again to force recompile.