UnityをIphone上で動かした時のフレームレート（以下FPS、単位はF）について、
せっかくiOS出力を使う機会が出来たので、
iOS端末上でどの程度のオブジェクト数までなら対応できるのか確認してみた。
実験環境は以下の3機種
・IPhone３GS(ios 4.3.5)
・IPad2(ios 5.0)
・Iphone4（ios 4.3.2)
ルールは以下の通り
1.ブロック内にオブジェクトを生成する仕組みを用意
オブジェクトは、初期生成できるオブジェクトにrigidbodyを追加した物。
2.オブジェクト（箱・球）を大量に生成（飛ばす）
3.FPSの最低値を記録する
4.FPSが1桁になるまで2と3を繰り返す
用意するオブジェクトの種類は、掲示板で球が軽くブロックが一番重いと論じられているので、
一番重い処理と一番軽い処理さえわかれば十分かなと。
（Mesh Collisionは用意するポリゴンによって変わるような気がするので割愛)
参考URL：http://forum.unity3d.com/threads/34254-Capsule-vs-Box-Colliders
ちなみに標準ではFPS最大値は30前後に固定されているが、
FPSを60にしたいので以下の処理でフレームレートを60前後に設定。
function Awake () {
Application.targetFrameRate = 60.0f;
}
どうやらUnity3.5からFPSの固定はソースコード改変ではなくこの記述でOKになったみたい。
使い方は、このスクリプトを空のオブジェクトに適応させればOK。
逆にUnity 3.4以前のバージョンでFPSを変更する場合は、
生成するソースコード内にあるAppController.mmの「#define kFPS 30」を「#define kFPS 60」に変更する必要がある模様。
（Applicationの親オブジェクトがわからんかったのでJavaScriptで記述したのは内緒）
参考URL：http://d.hatena.ne.jp/nakamura001/20110720/1311180071
また、FPSの計測はこちらのHPにある処理を丸ごと拝借。感謝。
参考URL：http://www40.atwiki.jp/spellbound/pages/1377.html
それでは実験スタート。
BGMは天国と地獄を脳内再生でよろしく。
うじゃうじゃうじゃ・・・
さて下が実験の結果。
y軸がFPS、x軸が出現個数。
まずは各端末毎の平均。
IPhone３GSとIPhone４は思っていたよりも差が無かった。
30Fをゲームができる限界と捉えると、IPhone３GSは150前後、IPhone４は210前後のオブジェクトが限界っぽい。
→高い解像度にグラボの性能が追いついていないらしい。納得。
次の表は個別の数値。
意外なことに箱のほうが高FPSを維持している時間が長かった。
が、箱は途中からFPSを大きく落とし、あっさりと一桁に落ちた。
逆に、球は20F以下になってからしぶとく残り続けた。
ただ出現個数が増えるごとにFPSを順当に落とし続けてる。
面白いのが、箱の場合は発射後数秒経つと60F前後までFPSが戻る所。
というか、オブジェクト同士が接触していない時は、概ね60Fを維持していた。
球の摩擦率を最大値まで上げて、しばらく放置した場合も同様に回復した気がする。
ということは、
FPSが低下するような事が起こるのはオブジェクト同士が接触したタイミングのみで、
当たってさえいなければオブジェクトが多少多くても大丈夫なんではないかと。
そう考えると、球のFPSが最初から低下し箱のFPSが最初は低下しなかったのは
球が転がり停止しなかった為なんではないかと。
で実際に当たり始めてから球と箱の立場が逆転したと?
つまり、
メダルプッシャーのような常時当たり続けているゲームなら兎も角、
あまりオブジェクトが当たることのないSTGやらシミュレーションでは、もう少しマシな数値を叩き出せるって事かな？
で、これを正しく検証するためには「あたり続ける＋動き続ける」環境でオブジェクトを増やすみたいな処理にしないといけない、と?
うーん・・・
調査対象を募集中 
