iPhone Input and GUI Performance Problems

[anon_70955258]

We at DigDog studio are having some severe performance problems with our Unity iPhone game. We have done as much debugging as possible and have pin-pointed a list of potential problems. Here they are, if anybody can give us a feedback.

Problems

1. Touching the iPhone seems to affect performance dramatically, even without any iPhoneInput.GetTouch calls, and even with iPhoneInput.multiTouchEnabled set to false. This can be easily tested by creating an empty project, filling the screen with a fillrate-hungry particle system, and seeing the effect on framerate from touching the screen.

2. We have been able to increase performance once by changing the kFPS define from 60 to 120, but later this seemed to worsten performance. Setting the define to 30 or 25 instead got us back a performance increase. Is there a way to find out what is the best value instead of trial and error? Does it have to do with the fact the game is either GPU or CPU bound?

3. Another big performance hog is also the two 3D texts and two 2-poly planes we are using as our HUD. Is this coming from the extra four draw calls? Or does it come from the 3D Text as some forum posts seem to point out? If it is the latter, we have already tried setting useGUILayout to false on these objects, but as these GameObjects don’t have any scripts, adding one to set the variables is causing even more performance problems.

Some forum posts seem to say the GUI Layer could be the culprit to some of these problems, but we have already removed all GUI Layers from all the project’s cameras.

Summary

The performance problems in our game seem to come from a superposition of performance problems in the Unity input system and the 3D Texts. Are we correct? What options do we have to solve these problems?

[Dreamora]

1. Thats to be expected. The CPU has to process the touches and generate the touch data indepent if you use them in this frame or not.

2. kFPS best is either fixed at 60 or 60 / i where i is a positive integer so it fits with the screen refresh rates → FPS you will be seeing. Raising it above 60 causes a serious amount of data flooding.
   Both bottleneck it in a real game. which to which degree can be found out through Shark up to a given degree

3. Depends on the amount of draw calls. You have a budget of <= 30 drawcalls so if you got it above the 30 with that four then yes.

Generally it sounds like your game is pretty heavy on scripts and as if you might not have optimized it yet to put everything on sleep that is not needed immediately. Its not optional to disable anything on the iphone you don’t need immediately, its a basic requirement for any more complex game and/or especially object rich game

Don’t forget, its a phone, not a PC. The iphone cpu at best has 1/10 to 1/20 of a first generation mac mini core processor, not only caused by the speed but the fact that the iphone processor has no cache to handle massive dynamic data bombardements.

[anon_70955258]

1. Thats to be expected. The CPU has to process the touches and generate the touch data indepent if you use them in this frame or not.

Expected, but it drops my fps by 10. That seems a but much to me. In the sample example I have given, the fps drops from the maxed out 60 to 40.

2. kFPS best is either fixed at 60 or 60 / i where i is a positive integer so it fits with the screen refresh rates → FPS you will be seeing. Raising it above 60 causes a serious amount of data flooding.
   Both bottleneck it in a real game. which to which degree can be found out through Shark up to a given degree

Thanks for the info, I’ll try to look into it.

3. Depends on the amount of draw calls. You have a budget of <= 30 drawcalls so if you got it above the 30 with that four then yes.

We have about 14-17 draw calls. Weird.

Generally it sounds like your game is pretty heavy on scripts and as if you might not have optimized it yet to put everything on sleep that is not needed immediately. Its not optional to disable anything on the iphone you don’t need immediately, its a basic requirement for any more complex game and/or especially object rich game

I’m running about 3-4 scripts in my test scene and all need to be run, and have been optimized as much as can be. I spent a week optimizing them.

Don’t forget, its a phone, not a PC. The iphone cpu at best has 1/10 to 1/20 of a first generation mac mini core processor, not only caused by the speed but the fact that the iphone processor has no cache to handle massive dynamic data bombardements.

As I’m using a Trail Renderer, that could be the dynamic aspect which takes it down. Hmmm…

[Dreamora]

The more often you check the input, the more data it generates and the more power it requires.
Multitouch is not a lightweight thing.
But if you have 60 and 40 FPS: is that an empty screen? because games won’t run that fast on the device at least unless its not much more than a a few objects + click.
if that is what the editor shows you, then keep in mind that the FPS and VRAM stats are in no way related ot the iphone.
Also FPS drops always happen in steps that are 60 / i due to the hardware vsync
so you either have 60, 30, 20, 15
40 sounds a bit impossible perhaps an error on the calculation routine or caused by buffering.

[anon_70955258]

But if you have 60 and 40 FPS: is that an empty screen? because games won’t run that fast on the device at least unless its not much more than a a few objects + click.

Yes that is indeed in a pretty empty scene. It’s in the example I gave in the original post of creating a new scene, only having a fill-rate hungry particle system to have a clear demonstration of the input problem.

With this example scene, not touching the scene gives 60 fps, touching it gives 40. That’s what troubles me: the difference of 20 fps by touching the screen.

[tomvds]

@""

With this example scene, not touching the scene gives 60 fps, touching it gives 40. That’s what troubles me: the difference of 20 fps by touching the screen.

As dreamora pointed out, the iPhone framerate is always one of 60, 30, 20, etc. Once the application load becomes too much to maintain 60, it will drop to 30. In theory, one extra multiplication per frame can cause this 30 fps drop. In your test application, the overhead of the iPhoneInput when the user touches the screen is simply that extra bit of work that makes maintaining 60 fps impossible. This does not mean that screen touches “cost 30 fps”. There is probably a lot more you can do before the frame rate will drop down to the next level (20 fps).

I can imagine this is a problem if you want your game to run at 60fps, but wanting a 60 fps game with any interesting content seems a very unrealistic expectation to me.

[Dreamora]

60FPS for games is impossible, independent of what you do.
Already 30FPS is pretty much unrealistic on anything but a 2nd generation ipod touch.
20 frames is a realistic target actually.

[anon_27183217]

@""

40 sounds a bit impossible perhaps an error on the calculation routine or caused by buffering.

This can happen if the framerate fluctuates a lot and the FPS is averaged.

[anon_70955258]

This can happen if the framerate fluctuates a lot and the FPS is averaged.

I calculate FPS in two ways: first by using the Unity Profiler, which I enable from Xcode, and the second way, using the Instruments OpenGL ES fps sampler. Both give me values of fps which can vary between the fixed values of 15, 20, 30, 60. Do both average over time?

[Dreamora]

No, they are both pretty much precise, especially the OGLES fps sampler