初の実機テスト しかし・・・・

いよいよきました、初のandroidでの動作確認!
結構いろいろやってたのに一度も試してなくて、android向けにビルドしたら死ぬほどエラーをはかれてげんなりしてましたが、勇気を出して潰しにかかる。
結局数週間つかったけども、ようやくビルドが通った。

さあ、実行・・・・

あれ、お、重いぃぃ!
きました、FPSまさかの4です

急いで影やらイメージエフェクトやらを変更して、テクスチャもでかいものはがっつり圧縮。で、結果がFPS7。なんだこりゃ!
こんな数値なんだから、よほどやってるんだろうな、と思われるかもしれませんが、プレイヤー1人とテストステージ「正方形」だけなんだなこれが。

いろいろおかしい箇所はあるけど最優先でこの重さは治したい。
とにかく影響しそうなところは触りまくる。

screenshotshare_20160131_145635.jpg
結果、20~30ほどになりました。
ちなみにターゲットが30なので、もう少しといった感じ。
敵もオブジェもないマップでの話だけど

あと、攻撃とか環境とか・・とにかく色々なところで使うエフェクト。
試しに設置してあるんだけど、何一つ再生できてないです。
android対応とあるけど・・・unityでの再生はまだ対応してないのかもしれない。

ロジック的な部分でいえば、フレームレートが落ちまくったせいで攻撃時の踏み込み移動処理がだめだったことに気づいた。
移動処理はStateMachineBehaviour内で行っているのですが、これがフレームがガタ落ちするとアップデートを全く通らないときがある。
よくて一回呼ばれる程度なので、つまり(見た目上ではなく実際に)ワープ移動してしまうか、まったく移動しないかの2パターンになる。
どうもアニメーションの更新はUpDate寄りらしいのでFPSの影響をモロにうけてしまうというわけだ。
走る歩く等の持続系な移動はdeltaTimeをかけてあげればいいけど、短い時間で移動するタイプだと呼ばれない場合があるからダメ、というとこでしょうか。
結局、StateMachineBehaviourを使う前にめんどくさいなーと思いながら書いてた、攻撃タイプごとの移動処理をfixedから呼ぶ必要がありそうだ。
なんだか紛らわしいし、アニメーション毎のStateMachineBehaviourのOnStateUpdateは入力監視andフラグ立て以外やらないほうがよさそう。

と、とにかくエフェクトだけは出さなくては!

comments

comment form

管理者にだけ表示を許可する

trackback


この記事にトラックバックする(FC2ブログユーザー)

リンク
報告
20150405 新カテゴリ追加
月別アーカイブ