スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

今週は。

今週は忙しくてアプリ関連は何もできませんでした;
レポートをはじめ、サークルの作業なんかもありさっぱりでした。

ってなわけであれからアプリになんの進展もありません。
うーむ。。。。。いくらなんでも開発スピードが遅すぎるな。。。。。
スポンサーサイト

システム着々と製作中

ボスはどうにもめんどくさい感じがたっぷりするので後回し。
とりあえず自機ボムに着手。数ヶ月前のマスパ以来ですね。

まずは画面振動と画面暗転を追加しました。
画面振動は移動範囲を9箇所用意し乱数で位置決定。
各オブジェクトは描画時にその値を使い描画することで画面全体がゆれているように見えるというわけです。画面まるまるコピーして張り付けるってのが一番簡単ですが動作が重そうでやりたくない。
背景を揺らすの一番困りました。
背景に3DCGを使っているからで各オブジェクト同様に平面をスライドさせたような振動はできない。一度描画してコピーしようにも描画エリアをギリギリしか持たせていないのでその方法では黒縁が出てしまう。
このことから画面全体がスライドしているようには見えませんがカメラを振動させることで対処してみました。3DCGの描画自体1フレーム前のものなので自機などのオブジェクトと揺れ方がそろっていませんが、振動自体高速なのであまり目立たないはず。結構3D酔いする;

続いて暗転。照明を落とすのがベストなんでしょうが、高速化のため法線情報を持たせていないのでそれはできません。ならば画面全体を黒い画像で覆うしかありません。Graphics2は重いうえに暗転の段階もどういうわけか少ないので難易度セレクト画面と同様に3DCGでやることに。一回のレンダリングで済ませたいので、背景と同一のプリミティブとし(背景画像を多少細工)処理できるようにしてあるので、ほぼ0コストで暗転が可能です。2Dの上に重ねがけすることができない(しようとすると極端におもくなる)のをのぞけば3DCGはかなり使える。

よーし、夢想封印がもうすぐそこにー

アイテム実装

プーリングはものの見事に失敗。
メモリ確保後は初期コストが増える感じで結果的に処理が遅くなる様子。
おそらくはVMのgc周りの動作によるもので、使用メモリが増加すればするほど負荷が増大するのでしょう。毎回newする方がチェックされるメモリは常に現在使用している量で速度的にはこちらの方が上のようです。なんだか信じられませんがなってしまったものはこう思うしかありません;その変わりgcが頻繁に起こるようになるので速度は安定しません。あくまで平均の速度では上という話。

んで、気を取り直して。
プーリング化していたものを元に戻し、作りかけだったアイテムの機構を実装しました。
アイテムの動作はもちろんのこと、スコアに反映されるしパワー増大でのオプション数の変化にも対応。ギミックも結構凝ってみたり。

基礎を入念に考えて作れば作るほどこういう部分は作りやすくなってくる。
だいぶ前にもアイテムはありましたがねぇ、中身はまったくの別ものです。
前のタイプではアレ以上の機能追加は相当の無理がありますし。


■リンク追加

友人葵がブログを作りました。結構前ですけど。新しい耳コピ作品ができたということで記念にリンクに追加!月之下遊歩道。(あたりまえですが今回のはワタシは関わっていませんよ;)

いやはや、この人最近えらいレベルあげてるな~。今後の作品にも期待。
ブログではMIDIやMP3も公開されています。ケータイの人はMIDI再生できるので聞けるかも?

プーリング失敗?

先日書いたプーリングですが、プーリングによりバグなく動作するようになりましたが、なにやらこれまでよりも重くなってしまいました;どこかに1.4以降のJavaではプーリングコスト>オブジェクト生成であるっていうのを見たんで、多分それですね。

破棄オブジェクトの取得自体はどう考えても早かったので(配列から決まってる番号の要素とるだけ。)、つまり必須の初期化項目数個への0代入よりもVMのメモリ確保の方が高速ということみたい。。。しかし、前それっぽいテストしたら10倍はやかったからなぁ。。。。なんだかよくわからない。

とりあえずプーリング使用前にもどしました…


気をとりなおして別な部分つくろっと;;;


■追記
いろいろ試した結果、原因はオブジェクトの総数にあるかも?
確保するオブジェクト数を減らすと高速化しました。数msの違いがでます。
といっても大目に確保しているからか処理時間は安定化するものの処理落ちの頻度は非プーリングよりも上がっています。
破棄せずそのまま参照を残しておくと、システム的に負荷が増大する模様。
すくないオブジェクト数でことを済ますことが高速化の秘訣なのかもしれません。

高速化中

switchを検証してからswitchを多く使うようになりました。
予想以上にifよりもswitchで書いた方がしっくりくるところが多い感じ。
ついでにいろいろなところを書き換えたりしたのですが、それでなんと高速化しましたw

主な修正箇所は、
ゲーム中で大多数のユニットで実行されるユニット管理クラスのスクリプト解釈部、移動処理部、当たり判定処理部を中心に、なくても影響のない条件文の削除、なくても影響のない変数の削除、不要関数の削除、それに伴う他クラスの修正を行いました。

最適化後の実行ファイルサイズで1KB減程度。switchに書き換えた場合サイズは増えるようなのであまり減ってませんがifのままの場合もっと減っていたと思われます。(容量に困ってないのであんま関係ないですけど。)

高速化のほどはN904iにおいて以前処理落ちしてスローな感じになっていたグランギニュル座の怪人が処理落ちしなくなるほど(若干は遅くなる。)。200発で40ms程度なので、ひょっとしたらそのあたりの弾数で5~10msの高速化かもしれません。とりあえず1ユニットあたりの走査時コストがかなり減りました。
コードの可読性アップ+高速化とは今回はいい変更ができた~。


残りの問題はユニットの生成コスト。
生成中は負荷が大きめになっている模様。
全部newで生成してますから当たり前な気もしますが、ここをなんとかしたい・・・
数が決まっているものに関してはあらかじめ確保しておくってのもありかぁ。。。
(いちいち初期化スクリプトを走らせているのも問題。)


■オブジェクトプーリング
プーリングっていうオブジェクトをあらかじめ保持しておき使いまわすという方法を検討中。
最近はプーリングコスト>生成コストという場合もあるらしく、とりあえず手始めにサンプルアプリ作ってみて検証してみた。

プーリングの方法はらしきものでは配列で走査しており、自動的に配列先頭部分が使用中で後部が廃棄中になっている。追加は使用中の部分の末端の空の要素に格納しているので、ここにあらじめ廃棄オブジェクトをいれておけば、それをとりだして初期化スクリプトを読ませればすむ話。
初期化スクリプトでは必要な部分は使用する値は初期化されるので動作には支障ないはずである。

ってなわで、これらの動作を模して実験アプリを作成。
N904iでやってみたところ、、
なんとオブジェクト生成後+初期化スクリプトよりもオブジェクト取り出し+初期化スクリプト+配列整理の方が10倍以上速いことがわかりました。

コレは・・・やるしかないw弾の発射時の動作が大きく安定するとともにガベージコレクトの呼ばれる回数も減らすことができる!おぉ、なんかwktkしてきた。
Go To 物置。
プロフィール

書いてる人:つん

まったりのんびり。書いてる人の息抜きブログです。

多分連絡先↓
metal_tsun@yahoo.co.jp

カテゴリー
リンク
月別アーカイブ
バロメーター
Java歴:2005年2月から今まで。
3DCG歴:2005年8月から数年。
C歴:2006年4月から今まで。
VB歴:2007年3月からちょっと。
Delphi歴:2007年3月からちょっと。
PIC歴:2007年5月から数年。
イラスト歴:2007年12月から今まで。
DTM歴2008年2月からちょっと。
PHP歴2008年4月からちょっと。
C++歴2008年4月から今まで。
C#歴2009年1月から今まで。
Objective-C歴2009年4月から今まで。
CSS歴2012年5月から今まで。

ブログ開始日2005/10/11


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。