I’ve read a bunch of the topics on optimizing draw calls, and I’m still running into some performance issues. I’m making a small platformer and I I’m getting around 12k tris on screen, 16 - 22 draw calls. I’ve combined my whole level into 1 mesh to drop the draw calls down, and the whole level takes up 4 draw calls and uses 4 512k textures. I also have 25 bounding boxes for physics in the level.
Is there anything I could do to optimize it? I’ve tried combining the level further so that I could drop a couple draw calls, but I have some transparency textures that are giving really bad sorting issues.
What else should I be looking for when trying to optimize? I also read that everything should be in one script instead of OO oriented with scripts attached to Game Objects, how much does keeping it separate affect the FPS rate, as combining everything into 1 script will take some time.
reduce the amount of polygons. putting all in a single mesh only makes sense if all is always on screen. otherwise combine it to blocks of about 1.5 times the screen size so only the block required is active.
does Unity automatically get rid of anything not on screen at the moment or do I have to manually deactivate the objects if my camera gets far enough away?
the rendering is disabled automatically for all meshes (bounding volumes of meshes) that are not within the view frustrum.
Within the view frustrum means within the camera rect within the specified view ranges, independent if it is behind something else or not.
I got it down to displaying 6k tris by breaking up the geometry more, and it’s still around 16 - 24 draw calls, but the improvement has only been 1 or 2 fps.
Is there anything else I should be doing? Does putting the whole game into 1 script speed things up a lot?
No, I’m not using OnGUI, as per the iPhone optimization guide, I turned it off with:
useGUILayout = false;
I also set my accelerometer processing frequency to 10 and my fixed timeStep to .06 but nothing is really giving me any significant boosts. It’s staying at a consistent 13 - 15 fps.
I also tried running the Built-In Profiler, but I got this output
Something is really up with the performance I’m getting. I disabled every piece of background geometry, all the bounding boxes, all the UI elements. All I have on screen is my character and some particles, all of which is showing as 4 draw calls and 2.3k tris, and I’m still getting 15 - 20 fps. This leads my to believe my main bottleneck is my scripts, but in total I have less than 1500 lines of code.
What’s the best way to go about optimizing scripts?
Don’t use GetComponent etc all the time, store the reference to the component if you need it again later and get it once in start for example.
but to be sure that it is the script: how much of that 2.3k polys are particles?
What are the specs of your character (triangles, bones and average amount of bones influencing a character).
Bone animations have their cost and are pretty heavy especially with non iphone targeted models
My character is a car that’s 2200 tris, and it has no bones, it’s just parented to a gameObject with a bounding box and it’s using physics with a constantForce to maneuver it, so I believe it should be pretty light for the phone to handle.
As for strings, the main thing I’m doing with them is changing on-screen text mesh objects (for score and such) using floats .ToString() a lot. Would that affect performance that much?
not needfully.
Physics, when used wrong, can actually be pretty heavy.
Also, the type of collisions can have a massive impact.
Conversion from float to string, to update it when the value has changed, should be pretty light.
Stuff like string concatenation and alike can cause trouble as they create a lot of temporary objects.
I’m making a 2d game, so I don’t need 3d physics at all. Would it be possible to save some processing time by forcing 2d physics? How would I go about that?
What do you mean by “type” of collisions. When I turned off all the geometry, I only had 6 box colliders including 1 for the car, and it was still running at 15 - 20fps
there is no real 2D physics.
What you can do is lock specific dimensions like movement on the z axis.
That will keep it in 2D.
But processing wise it won’t become really lighter.
Without the profiler output it isn’t possible to give any further hints and ideas.
As you can impossibly develop iphone games as long as basic stuff blows up that ugly when you try to enable the profiler, I would recommend to check your installation, if the iphone 3.0 sdk install worked fine and if xcode is all fine for example
would also recommend to check the private iphone dev boards at apple on the topic of that errors
Hi,
give a try internal profiler. You can enable it in XCode project AppController.mm file. Profiler output is printed to XCode Debugger Console (Run->Console).
I got the internal profiler working from before. It seems the problem was that I was building a distribution build. Once I built a developer build, the profiler turned on without spitting out crazy errors. Anyway, here are my stats:
this seems a bit weird as it’s saying, if I’m reading right, that it’s going at an average of 53fps, but I made an fps timer using a gui text with 1/Time.deltaTime as the output and it’s showing me 20fps. There’s also very noticeable slowdown when I play the game, so it just doesn’t seem like the 53fps is accurate.
These numbers aren’t fps, they are time spent on each component in milliseconds per frame. I see that scripts are your major performance bottleneck. To get good framerate you need to bring it down to 5 ms.
Have you enabled Fast icall optimization in Player settings? Another hint - if you deal a lot with game object transforms then you can benefit from caching them.
I see. Thanks! I’ll try optimizing the scripts more. Turning on iPhone fast call optimization, I shaved off around 5ms. I’ll try the transform caching stuff. Is there anything else I should be looking out for? I already moved all my GetComponent calls out of the Update functions
