I’m gearing up to release my first iOS game made with Unity, but I’m running into a strange issue. I’m seeing that after loading this game onto a device, it will stutter terribly during the first 30 seconds or so. It then levels out and everything is fine. From that point on, if the application is closed and reopened, everything is smooth. But once the device is restarted, it will be incredibly choppy again.
During this time the game isn’t doing much. There’s really just a slow pan over fairly low poly geometry and only a few draw calls. There is no object instantiation, very little component instantiation. The first drawn out scene where this is noticeable is after logos are displayed. It’s the third scene loaded by Unity. It is also worth noting that this occurs on all devices; from an iPhone 3GS to the latest iPad.
I have attached a screenshot from the profiler. The spikes are caused by the process Mesh.DrawVBO, which seems to take between 500ms-1000ms each time it spikes. Sometimes it spikes when a new mesh enters the scene, but others (like the highlighted spike) seem unprovoked. I searched around on this forum for DrawVBO but there appears to be no real information available.
I’m quite concerned about this issue since it leads to a very bad first impression. Any help on how to resolve this is very much appreciated.
Just figured I’d write a quick reply to this since there’s not a lot of info on DrawVBO issues. I did eventually come around to a workaround.
First, this only really seems to be an issue using OpenGLES 1.1. Unfortunately, OGLES1.1 is currently much faster than OGLES2.0 in Unity.
After some trial-and-error I found that the spikes will sometimes occur when a new mesh enters the scene (even if the mesh isn’t particularly complex) or when an object gets scaled non-uniformly for the very first time.
My workaround involves activating all objects in the scene and positioning a camera so it’s all rendered in one frame. I also perform simple non-uniform scaling on objects that need it later on. I put a black quad in front of the camera so the player can’t tell this is happening. In my case this process takes about 10 seconds, so it simply feels like an extended loading time.
The fact that this issue resolves itself after playing the game a few times on the same device is still a mystery to me.
I’ve contacted Unity about this and they state they are not interested in resolving the fundamental problem. If anyone else is experiencing this you’ll need to use a workaround like the one I’ve found or use OGLES2.0.
OGLES 1.1 is not currently much faster than OGLES2.0 in unity.
What you are experiencing are automatically-compiled shader conversions meaning the unity mobile “fixed function shaders” are internally recompiled to generic ES 2.0 shaders.
The result? ES2.0 seems slower.
However using well-crafted 2.0 shaders and OGLES2.0 will actually be faster across a wider range of devices than translated fixed function.
Unity show no interest in this because you’re wrong, not because they are not interested. If you are interested in speed being faster, you can try echo’s shader pack in my signature that exactly proves the case. Ask him or his customers.
If you are talking about pure mesh stuff, it could be your ES 2.0 shaders are not optimised. Let us know if this helps or its a viable direction for you (I am not attacking you btw)
Perhaps some additional details would help. I wouldn’t mind being proven wrong about anything that I posted. I admit that I only have a high-level understanding of the issues.
My understanding is that the shader I’m using across my project is as bare-bones and efficient as they come (given that I need color multiplication). Take a look and tell me if I’m mistaken. http://twinskygames.com/tmep/VertexLitWithColor.shader
Unity support told me themselves that they’re making a push so that OGLES2.0 is as efficient as OGLES1.1 in Unity 4.2. But right now that’s a ways out.
As it stands, on each iOS device I’ve tested, my game will run just under half the framerate if using OGLES2.0 versus 1.1.
I have exactly the same problem for almost a year. After upgrading to Unity 4.2, it got worse. Now the game is almost unplayable in the first load. I have used echo’s framework, but nothing changed, because my shaders are already very simple, mostly mobile/unlit (supports lightmap) and mobile/vertex lit (directional light only).
Thanks Graham, I should have missed it because I didn’t read unity 3.4 changelog.
Anyway, I tried that, but unfortunately the screen goes black after the Shader.WarmupAllShaders() call.
It says:
Shader warmup: 18 shaders 143 combinations 7.395s
But there is nothing but black screen after that. (The game continues as I hear the sounds etc.)
I think I should reduce the number of shaders, because 18 is a bit high.
