We are designing a game that has what we feel is abnormal performance difference between iPhone 3G and 3GS/4. I know the 4 should be faster but 15x?? We have 13 rigid bodies using physics and on the 3G it performs near 3-4fps yet 60fps on 4. Is there something obvious we might be doing wrong??
Nothing wrong there.
on the 3G you are hitting the gpu cap with your drawcalls cause if you have 13 rigids already you are likely above the 20 drawcalls you have available at max.
on the 3GS+ you have much more power under the hood (combined, they are very well in the 10x+ range if your game was limited on both sides and not bottlenecked due to one end only)
I thought Unity batched draw calls now or something to avoid that being as much of an issue these days? Is there anything I can do to get this to run better on the 3G. What’s even more odd to me, is it used to run a lot better. I am not sure if its iOS4 or something else. I am just not convinced having 13 simple square blocks on the screen should run this poorly and 12-15x slower than a 3GS.
Unity batches drawcalls right (to what degree you see in the editor)
but depending on what you do (they must all use the exactly same material) it can or can not batch them.
also on the iphone 3G, with that much physics, you have a polygon budget of 7000 if not less and you better didn’t use polygon colliders (they are a very bad idea)
We are using blocks for a physics puzzle game. So blocks will fall down and interact with other blocks in a 2D kind of way. So there are very few polygons. I feel like I must be missing something for why its running this poorly.
FYI, I just checked in Editor. Its shows the following in regards to draw calls:
Emulated Draw Calls: 4 Batched: 2
Editor Draw Calls: 5
Removing blocks from the screen does not reduce draw calls. If I turn off all physics on the blocks, the 3G increases to about 45FPS, turned on, does only about 3FPS!
Anything else I could change/tweak? 13 blocks doesn’t seem like a lot to be causing this problem. Maybe I am doing everything wrong, some other approach?
13 blocks are no problem
13 blocks with rigidbody on the other end are a hefty thing cause that means a lot of linear equation systems that need to be solved each frame.
the cpu of the 3GS is somewhere of 2-3x as fast (200mhz faster, new cpu architecture, more cache), the iphone 4 has the 3gs cpu but at 800mhz, so much much faster.
you will need to tweak the physics settings likely for the iphone 3g, like raising the time between physics updates to 0.033 and not let it do that many iterations (0-3 is reasonable)
what are you doing exactly with the rigidbodies?
also can you post the device profiler data (you enable them through the define in the xcode project)
and did you ensure to restart the device, cause debug demons that float around etc will get its ram that low that this will add additional problems
Yeah I will get you that and answers to your other questions soon, thanks a lot for any help.
I did try rebooting the device and tried on multiple devices as well, with no increase in performance.
One last thing: its an iphone 3G right, not a trashphone 3G (iphone 3G trashed by iOS 4.x)
cause iOS4.x isn’t as optimized for ARMV6 anymore, you lose performance for the very same app when ran on 3 and 4
It is running iOS4.1. I could not find a way to downgrade it or to install 3.1.3 SDK after installing the 4.1 SDK. Would it make that much of a difference? I thought 4.1 fixed a lot of the perf issues. If so, how do I target below 3.2 in XCode? 3.2 is the lowest option I have.
base SDK to the current (required, otherwise it won’t go onto the appstore anyway)
and then in active target settings, you set the deployment target to 3.1.3
the iphone itself can not be downgraded anymore at least not without jailbreak. os upgrades are one way
and yes 4.1 helped generally but for stuff like games it unhappily did help all that much.
I am not following how to get 3.1.3 as an option? 3.2 is the lowest I have.
Do you think iOS4.x would account solely for the performance issue we are having?
To get 3.1.3 you need to go to projects - edit active target
and in there, alter the iOS Deployment Target, 3.0 and higher is fine, 3.1.3 is what you likely will use cause beyond 98%+ of all are on that one or higher
iOS4.x on iPhone 3G accounts for performance reasons and crashes cause already on iOS 3 you only had 25-30mb RAM available, on iOS4 it can be even less
Thank you, I was able to downgrade one of the 3G’s to 3.1.3 and get it running on there. That didn’t seem to make hardly any difference to the issue we are having though.
Will get you the profiler data in a bit. Can you explain what settings these are exactly that you reference here and where I would change them?
You change these values in the physics settings as well as time settings (both editor things)
Yes but what settings specifically? Sorry I don’t understand the physics settings very well.
Hello dreamora, thanks for the help thus far.
In answer to a few of your questions:
-
Our rigidbodies have no mesh renderers, and all rigidbody textures on on the same spritemap.
-
Each rigidbody is locked for Z motion, angular X motion, and angular Y motion via configurable joints. This should cut all calculations and linear equations by half.
-
Gravity is disabled. The cubes only interact with constant forces.
-
There is no OnCollision data being manipulated
SO, all things considered, I would not think that 13 blocks sitting and doing nothing could cause such a performance burden, but I’ll play with fixed delta time. Is that the variable you are referencing for the time between physics updates? Also having a hard time finding how to alter the amount of iterations, unity script reference isn’t being much help.
Thanks!
EDIT: Found the iteration variable. Thanks again.
by now I’m pretty confident that we have a cpu bottleneck here and that the graphics chip is not even close to bogging down.
Don’t see why.
The linear equation system is still widely the same, it just can skip part of the resolutions but just by cutting 2 of 6 degrees of freedom, you are not even close to “halfing it”. if it only could move in x and y and not rotate, then yes you could theory wise cut it heavily, but even then it depends on how physx handles it.
but from your description it sounds like your application might use physics material and or rotational simulation too, is that correct?
As mentioned before, most optimally you would give the profiler output a go, up to that point all is just assumption and commonly “risky” to do
which isn’t any better, actually worse as they now have X gravities not just 1
Correct
for others searching it, its
Physics.solverIterationCount
Great, thanks for the response Dreamora!
The application does not have any physics materials, and I am pretty sure (unless our descriptions of simulated rotation are different) that it is not using any simulated rotation.
Apparently the default iteration count is set to 20, and I was able to lower this to 1 for a huge performance increase. The FPS went from about 3-5 to 20-25, thank you!
It runs acceptably at the current increased frame rate, but we would love to be able to pick up as performance increase as possible for the best game experience.
Here is the debug output you asked for, on said level that was having issues previously (13 rigidbodied cubes). Does this tell you anything?
iPhone Unity internal profiler stats:
cpu-player> min: 25.6 max: 70.7 avg: 37.3
cpu-ogles-drv> min: 0.4 max: 4.8 avg: 0.7
cpu-present> min: 1.1 max: 5.9 avg: 1.6
frametime> min: 29.5 max: 81.6 avg: 44.1
draw-call #> min: 4 max: 4 avg: 4 | batched: 0
tris #> min: 190 max: 190 avg: 190 | batched: 0
verts #> min: 380 max: 380 avg: 380 | batched: 0
player-detail> physx: 24.7 animation: 0.0 culling 0.2 skinning: 0.0 batching: 0.0 render: 3.9 fixed-update-count: 3 .. 9
mono-scripts> update: 1.2 fixedUpdate: 3.9 coroutines: 2.5
mono-memory> used heap: 442368 allocated heap: 643072 max number of collections: 0 collection total duration: 0.0
Yupp it tells me that you are definitely wasting all the frametime in physx as you can see from it 
your time for a full frame is about 26ms (so over 30 fps technically), and of that 26ms, nearly 25ms are burnt through by physx.
as for rotation simulation: unless you freeze rotation on the rigidbody it will always simulate rotational impacts too