[絵]霊夢描いてみた

2008 / 07 / 31 ( Thu )
霊夢なにやら鼻水がやけにくさく、頭痛発熱があると思いきや、どうやら蓄膿になったみたいです（鼻のつまりはないので多分軽い）；この症状は土日から。今は発熱が引き、頭痛もよくなり、鼻の臭いもそうでもなくなってきたんですが、悪化したら大変なことになるみたいなんで、こいつは早めに耳鼻科に行ったほうがいいですな。きっと最近引いた風邪のせいだな・・・ぐう。

ということで絵。
本日は霊夢。ゆゆさまで試した灰色での色塗りをもうちょっとがんばってやってみた。
多分永夜抄あたりの霊夢。(模様ちがうけど。)
絵少しでもうまくなってきてるのかなぁ。。。ツールの使い方に慣れてきてるだけのような。
傾きなおしたり、範囲移動とかそういうのを使う回数は格段に増えてるし。
次は表情だ！表情の練習だ！喜怒哀楽、、むずそうだー。

17 : 07 : 12 | イラスト | コメント(4) | page top↑

Grazeエフェクト追加

2008 / 07 / 29 ( Tue )
Grazeのパチパチってやつを実装しました。(音はないです。)

しっかりとカスッた方向から発生し、適当な向き(基本カスッ方向)に火花を飛ばします。
(ちゃんと初速が速く減速しつつ消えるようになってます。)
SS張りたかったんですが、火花の消えるが速すぎてSSにすると全然量がすくない；
動いてるとどんどん生成されてそれっぽく見えるわけですが。

とりあえず実装したかったので今はfillRect(矩形塗りつぶし)で描画してますが、
どうにも見栄えがよろしくないので最終的には画像でやります。
すんごい重そうな方法で載せましたが、数フレームで消滅することと最大数を決めてあるのであんまりコストは高くない。(1msはない。画像にしたときはちと遅くなるはず。)

次はアイテム。
信仰点表示もさくっと実装へ。

いや〜それにしても目に見えるものを追加するのは進んでいるような感じがしていいですなぁ。


□設計反省
各オブジェクトはすべて基本的な動きつけることのできる機能をもったクラス(メンバ変数いっぱい…)を継承してるんですが、これをインタフェースにしてもっと柔軟性をもたせればよかったなぁと。
例えば今回の火花は単純な動きしかないし、そういう機能がいらなかったので別クラスで管理しているんですが、これではメインの走査リストに追加することができない。なので毎フレーム走査する必要があるのに、そのオブジェクト内にメインとは別のリストを持たせ別個走査するという面倒なことになってる。

＝走査リストは各(主に描画機能をもった)オブジェクトのためだけではなく、フレーム依存で行動を起こすあらゆるものを格納できたほうがいいと思う。走査に必要なもの(メソッド１つ)をインターフェースで定義しちゃえばいいわけですな。

23 : 42 : 59 | 東方らしきもの | コメント(3) | page top↑

Graze実装

2008 / 07 / 28 ( Mon )
□今日の戦果
当たり判定周りがまとまってきたところでカスリ=Grazeを載せました。
自機相手のみの機能なのでちょうど判定を総当りでおこなっているところで、Graze実装も処理速度を落とさず実装できました。円判定ならちょっと径を大きくして判定を行うのみ。
割と広め、だと思う。操作性がケータイだとあれだからこの辺は。

まだパチパチっていう火花（？）の表示がないのでかすってもおもしろくない。
効果音は同時発音数がすくないので、ここに使うのはもったいないのでなし。
(いや、他が鳴ってないときくらい…)

他ドット絵を多数追加。
Grazeのフォント作るのについでにスコア周りのフォントを総入れ替え。
低速時、自機当たり判定の目安表示。
点符まわりの追加。(信仰点符。)


□動作テスト
割とシステム周りも作り始めたところで友人にSH902iでのテストを依頼。
動作は意外にも良好のようで、
30fpsでも穣子弾幕に処理落ちを軽くしますがfpsが1〜2落ちる程度とのこと。
30fpsでいう1〜2ってまぁ10%以下の速度低下なので気にならないらしい。
15fpsだとケータイアプリならまったく問題レベルだが30に比べるとやっぱりカクカクに見えるみたい。
ただ処理時間に余裕ができるのでこっちのモードだと300発はだせそう。
(といっても公式アプリのSTGって大概15fps。)

60fps精度から下げる必要は結局ないの感じかなぁ。
60fps精度だと本家並みの高速弾に耐えられる。

SH902iはN904i同様3DCGが遅め。ただ2Dはめちゃくちゃ速く、このあたりがN904iとの差のようです。
SHは903i以降は902iより3DCGが1.5倍程度はやい上、2D処理・演算速度もあがってることだろうから、このあたりの機種はなんも心配することはなさげ。
あぁSHに機種変したいｗ

F902iは惨敗。3DCGが遅すぎて、30fpsはとてもじゃないがでない。
だが15なら穣子弾幕で多少処理落ちする程度で動く。
Fは903iから3DCGが爆速すぎるので30fpsだせるかもしれない。

尚フレームスキップは載せません。
本家同様ですな。処理落ち中は弾が遅くなる。
フレームスキップするのは大概弾が多いときになるわけですが、
このときいきなりフレームが落ちたり落ちなかったりするとと見にくいことこの上なく、死ねます。


■制作のしおり
アクセス数みたらボコンと伸びている箇所がったので確認したところ、
久々に制作のしおりさまに紹介していただけました〜！(あれ、敬語だか謙譲語あってるかな；)
前に載せた耳コピのですな。しおり様、こんなヘタレな耳コピなのにわざわざありがとうございます！

22 : 39 : 02 | 東方らしきもの | コメント(0) | page top↑

[絵]ゆゆさま描いてみた

2008 / 07 / 28 ( Mon )
幽々子絵を描いてアップしてるときはいつも徹夜です。

っというのもテスト期間。レポートが重なるなどなんかひどい状況。
のんきにアプリとか作ってるからこんな時間が足りない自体になるわけですが、
なにはともあれいろいろと間に合わせないといけない季節。
あーやだやだ。はやくテスト終わんないかな。

テスト期間になれば更新頻度が上がるのは徹夜してるから。

06 : 57 : 46 | イラスト | コメント(0) | page top↑

[耳コピ]信仰は儚き人間の為に

2008 / 07 / 27 ( Sun )
だいぶ前に作ったのを忘れていた；
折角なので公開。
はげしく未完成だったような気がするが、今となってはどこのことだったかわからない。

■ケータイ用
・信仰は儚き人間の為に(3gpで1.5MBくらいのステレオ、128kbps)
↓QRコード
信仰

サイズがなんだかアホみたいにでかいのでパケホじゃない人は注意してください。
相変わらず音声のみの3gpが作れず変換君デフォの画像が一枚はいってます；
3gpp2なるものもあるらしいがどうやんだろ。

■PC用
・信仰は儚き人間の為に(mp3で2.0MBくらいのステレオ、192kbps)

今度はちゃんとフェードアウトさせてますよ〜。
この曲は確か耳コピはじめて2曲目ですな。3曲目が稲田姫。

それにしても最近耳コピやってない。
こんだけあいちゃったらなかなかこんなのでも作れないだろうなぁ；
夏休みはいったらまたちょっとやってみなくては〜。(らしきもののタイトル曲あたりを。。。)

02 : 45 : 48 | 耳コピ | コメント(0) | page top↑

[絵]もこう描いてみた

2008 / 07 / 26 ( Sat )
妹紅携帯用。妹紅描いた。これであの日に描いた3名描き直し作戦終了。

前にけーね・かぐや・もこう描いたのは正月だったのかぁ。
あのころは確かペンタブを使い始めたばかり。。。にしても結構半年以上もたてば絵柄もだいぶかわるもんですなぁ。

にしても日記を見返すのって意外におもしろいもんですなぁ。
らしきもの開発はじめたのは12月ですかぁ。
随分たちましたなぁ。8ヶ月以上ですよねぇ。
どんだけ作る遅いんだ；


■追記
そのらしきものは100KBを超えてメガアプリ対応機種しかDLできない状態だったので画像類をwebからDLするようにして再び500KBアプリへ対応できるように改良中。(ってか基本機能。)
バージョンアップしたら自動でファイル入れ替え機能とか搭載。
スクラッチパッドのデータ変わるたびDLしなおしはめんどいですからね；

コレ終わったらアイテムと自機被弾など復活させます。
自機被弾時は撃墜地点から円形に当たり判定ひろげて当たった敵には順次ダメージがはいるような感じでいいのかな。ボム機能復活次第夢想封印実装に移ろう。

21 : 05 : 39 | イラスト | コメント(0) | page top↑

続・続・続　高速化中

2008 / 07 / 25 ( Fri )
尚も続く高速化作業。
まだまだ満足できる速度ではない。

□今日の改良点
・背景用Primitive法線なし設定に。
・QuadTreeの調整

QuadTreeの調整は走査量削減のためセルにオブジェクトが登録されているかフラグを立てていましたが、低階層化もありフラグ立て、フラグチェックなしの方が高速っぽかったのでコレを削除。またまた自弾の(すこーし)処理速度が向上。
今思えば敵弾を総当りにしたのは正解。敵弾はGraze機能があってGraze範囲は判定範囲が広めなわけだから、結果セル境界線に乗る可能性がかなり高いわけで。

背景用Primitiveの法線情報を削除しました。
これはボムのために照明を落とすなどの効果を使うためだけに以前追加したもの。これがあるとマスコットカプセルで最適化されないらしく随分とレンダリングコストがあがっていました。
これを削除でなんとまぁ3msの高速化。
ボム時暗転は黒色1ポリゴンのプリミティブをアルファでかぶせて再現する。
結構照明設定微妙だったし、むしろこっちのがやりやすい。かも。
ただ再現度はおちるのかなぁ。。。1ポリゴンだと2ms程度でレンダリング可能なので、ペナルティ的なものは特にない。

さて、これで弾ないときの処理時間が18ms⇒14msに。
これは今となってはもうかなり大きな高速化。
弾200個は余裕でだせるようになりました。220程度までは大丈夫かも。
あと30個！3msくらい！走査1回にしたら余裕の達成だが・・・


■追記
弾でもなんでも生成時に設定用スクリプト(文字列ではないが)を読ませていたが、
実際は雛形をひとつ作ったらあとはメンバのコピーで同じ結果が得られるので、コピーメソッドを作って置き換えてみた。

ただメンバはほとんどprivateでオブジェクト渡しただけではコピーできないので、
引数30個もあるめちゃくちゃなメソッド書いて代用。

スクリプト読み込みと引数30個のメソッド呼び出しとどっちがはやいかというお話。
ってかなんでclone()使えないんだろ…cloneable自体DoJaにはない？

しかし、コレの効果があったのかは実際のところよくわからなかったが、
自弾消している状態では穣子弾幕(180個)ではピーク時でも10msの余裕がでるようになった。
これで処理落ちしていた時が懐かしい。

20 : 09 : 18 | 東方らしきもの | コメント(0) | page top↑

[絵]かぐや描いてみた

2008 / 07 / 25 ( Fri )
輝夜レポート完成したあと息抜きに描いてみた。ペンタブ入手直後あたりに描いた輝夜見て書き直そうと決意(1月のアレ)。

下絵を描かないでいきなり300%にくらい拡大して1dotペンでガリガリやり、左右反転で確認とかそういうのしてないんで全体が少し曲がってる。全体バランスもなんかおかしいので、やはり下絵は必要。

髪描くのうまくなりたいあなぁ。

07 : 52 : 34 | イラスト | コメント(0) | page top↑

続・続　高速化

2008 / 07 / 25 ( Fri )
テスト他の部分を作ろうと思うがどうにも速度面を気にしてしまう；

□今回の改良点
・オブジェクト走査方法の改良。
・4分木走査方法の改良。
・計算クラスの改良。
・エリア外判定の精度をあげた。
・fps計算精度の向上。

走査方法は前回のものの延長。リストクラスを走査を行うクラス内に展開した。
展開といっても配列一個と変数１つしかないようなクラスだったんであっさりと。
オブジェクト数200ともなれば20fpsで１ループ600回も呼ばれるような機能だから重要。

4分木の方の走査も配列を取り出してからにしてみた。
今は4分木は敵⇔自機弾間でのみの使用ですが、自機弾のコスト軽減に貢献。
しかしこの方法、保守性もなにもあったもんじゃないなぁ…まぁ個人開発だからやれるというか。。。

計算クラスはradianの精度向上。回転系の動きがよりスムーズかつ自然になりました。

エリア外判定というのは弾などは画面外にいくと自動で削除される仕組みなわけですが、その判定。これまではかなり大雑把で割りと広かったため、弾の寿命がすこし長かった。この精度を上げたので画面外の弾の処理はきれいになくなります。これまでと同じ弾幕でも表示される弾数が減っていることを確認できた。


今回から描画と一切関係ない走査部分のみにかかる時間を計り始めた。
弾200発程度で15msもかかっているらしい(N904i。20fpsなので3走査分)。このとき総処理時間は50msほど。内、背景含む基本処理が17ms。このことから2D描画にかかってる時間は18msってことになる。

2D描画にかかる時間は減らしようがないとして。
やっぱキーになるのは走査にかかる時間か。
１走査5msから3msくらいにしたいなぁ…無理っぽいけど。

03 : 13 : 04 | 東方らしきもの | コメント(0) | page top↑

[絵]慧音描いてみた

2008 / 07 / 24 ( Thu )
慧音レポートに疲れてきたので息抜きに慧音。いっつも無駄に目がでかいのでちょいと小さく描いてみた。このくらいのがいい。

怒ったら頭突きをする人らしいですがそんな先生アラレちゃんにもいたような。

09 : 38 : 52 | イラスト | コメント(0) | page top↑

続・高速化中

2008 / 07 / 24 ( Thu )
今日もせっせと高速化。

・オブジェクトの走査方法の変更
・自機当たり判定方法の変更

などをおこなったところ、これまたちょっぴり高速化。
自弾ださなければ穣子弾幕(200発)を微妙に処理落ちはするものの耐えられるようになった。

走査方法は従来版はArrayListでリストから外す際arraycopyで前後どちらかをコピーするという方法をとっていました。それを配列を二本用意し走査時にリストに残すものはもう一方の配列にコピーしていき、削除するものは移動しない、走査する毎に使う配列を切り替える。という方法にしてみた。
arraycopyでは削除箇所によってコストが異なりますが、新しいのではそんなことはない。
これを使ったらエミュ上では結構な高速化を達成。
実機では微妙。遅くはなっていない。ただ処理時間が安定した、、、かもしれない。

２つ目は自機についての当たり判定方法の変更。
自機⇔敵弾は常に１対多の関係。少し前からここにも４分木を使っていましたが、対象が１つなのだからわざわざ毎回４分木に弾を登録し、自機のセルから当たり判定を見ていくくらいなら、敵弾の走査中にすべての敵弾が自機と当たり判定をとった方が高速かな、と。つまり総当り。
予想は当たっていたようで微妙に高速化。
４分木のチェックが減ったので弾がない状態でも微妙にはやくなったかも。


ん〜、そろそろ思い当たるところがない；；
走査を３回もやって3D+弾200発なら結構がんばってる方なのかなぁ・・・

3DCGが高速でなおかつ30fpsで表示可能(走査が2回でいい)な機種での動作が気になり始めてるので、さっさとテストアプリを仕上げよう。他の機種は何発たえられるのかな。


■追記
走査時にListクラスから配列を取り出してそこから直接アクセスできるようにしてみた。
これも効果あったようで結構高速化できた。穣子弾幕(200発)をほぼ処理落ちせず出せる。
この変更は要はListの要素にアクセスする際にget関数を使わなくなったということ。
呼び出しコストってやっぱ高いんですなぁ。これのせいでLinkedList全廃したくらいだし；；

02 : 07 : 30 | 東方らしきもの | コメント(0) | page top↑

気合の高速化中

2008 / 07 / 23 ( Wed )
自弾を3DCGから2Dに戻したところ差は4msほど。
しかしこれでも満足な速度とはとてもじゃないがいえない。
自弾含めて180発程度ですからね；これでも。
いろいろな弾幕を作るのにも幅広い端末で動作するようにするにも高速化は急務。

というわけで、気合の高速化開始。
各オブジェクトの毎ループ呼ばれるメソッドを中心に見直し。
この辺りのメソッドは fps合わせによるループx全オブジェクト数行われる非常に多く呼ばれるものなのでちょっと削っただけでも大きな効果が見込める。

主に移動系周りに改良の余地があったので改良。なんかいろいろ減らした。
これによりオブジェクトの１個当たりのコストが軽減。
どうやら最初より10発程度多くだしても大丈夫なようになったようだ。

あと高速化は特に関係なさそうですが、Graphicsクラスから2Dや3DのGraphics作るときcopyメソッドを使うのやめ、単なるキャストにした。
なにやらレンダリング時の使用メモリ量が大幅に減った予感。

まだいけるかも。。。


しかし初期コストが高すぎる。
18〜19ms。背景だけに15msのようで、、、こいつをどうにかできないかなぁ。
3Dの初期コストともいえるフラッシュバッファに特に設定項目できないし。。。
(メモリ転送だから転送範囲狭めればはやくなる？)
ただ一回使うと追加で3DCGレンダリングするなら低コストでいけるからけづれないしなぁ。
初期コスト残り3〜4msは得点関連の表示。よく考えたらここは部分描画の塊だもんなぁ。
Hiscoreなどの固定文字列はサイドの絵に直接書いて、その絵をjpgにすれば、1msくらいはけづれるかな。デバッグ用のdrawString。これも結構割高。

めざせオブジェクト数計250個。

03 : 06 : 45 | 東方らしきもの | コメント(0) | page top↑

びーもば2.5の予定

2008 / 07 / 20 ( Sun )
裏タスクで新しいびーもば作ってます。
こちらもらしきもの同様完全に新しいものになってます。

で、作り直しはじめるて一気につけたい機能全部つけようとするとゴールできない恐れがあるので、現在公開中のバージョンに+αの機能をつけれたらそこで一旦公開します。
更新はワイド画面の方のみ。正方形の方は多分もう更新しません；ドット編集するの結構めんどいので；

■ver2.5予定機能
・エフェクト3DCG化。半透明(加算)化。
　らしきもので培った3Dクラスをそのまま流用しますｗただ半透過はやっぱりいいものでｗ他にも光を使ったエフェクトはいろいろ積むつもり。
・ロード高速化
　をするつもりはなかったんですが、作り直したらちょっと速度があがったような気がする。
・偽装GIF、偽装JPG読み込み再対応
　SDがなくてもプレイ可能になります。webから偽装ファイルをDLしてプレイも可能になるので、PCない方でもようやくびーもばができるようになります。ここからシステム用の画像類の設定も可能。
・曲セレクト画面のBGMを設定可能
　mld、midを設定可能。似非着メロを使えば結構ソレっぽい？
・MIDI変換精度の向上。
　いろいろ考えて作り直し。サイズ制限もなくす。
・BGAの対応。
　BMSの基本機能のBGAのみ対応。映像はもちろん無理。
画像を複数組み合わせたら軽いアニメーションはできるかも？poor用の画像とかは多分いける。
ただしこの機能を使う場合はレーンの半透過は無効。(いや、気合でいけるのか？・・・)

こんなところ。変更点といっても、2.0と2.5は見た目は同じでもまったく違うものなのでどうなるのかはよくわかりません(マルチスレッドとかの練習もちらほら)。あくまでも3.0までのつなぎ。

3.0ではこらに加え、VGA化、3gp対応、IR(?)対応、曲セレクトの階層表示、とかなんかいろいろ考えてます。いやはや、作ってておもしろいですなぁびーもば。特に悩むところがないというかｗ

予定アプリサイズは…70KBくらい？


現在はまだゲームができる状態ではありませんが、初期のロードはできるようになりました。
2.0をベースを見ながら作っているんですが、よくこれだけのものを1クラスに押し込んだものだな、と；
外に出てるのがBMSのデータ保持クラスしかないってどういうこと…
変数管理が大変だった記憶があるし、仕様変更にもろいのもあったなぁ。
どんどんクラスに分けていってもう30クラス。今度は長く使える柔軟なものを作ろう。

02 : 53 : 53 | びーもば | コメント(0) | page top↑

風邪治る + ４分木

2008 / 07 / 20 ( Sun )
まだちょっとノドがおかしなことになってますが他はもうすっかりよくなりました。

というわけで早速以前書いていた当たり判定高速化のための４分木を実装しました。
結果は具体的な比較を行ったわけではないのであれですが、遅くはなっていない印象。
同等か、少し速いかな？っといったくらいで劇的にはやくはなりませんでした。
ただ例の敵が大量に出てくる場合では威力を発揮し、安定した速度を出せるようになり、処理落ちはそんなにそんな起こることはなくなりました。

４分木自体多対多で威力を発揮するものなので過度な期待はしていなかったんで、これでおｋ。遅くならず同等の速度がでるだけでもかなりの成果といえると思います。
一対多を想定してそれ専用の検索機能も設けました。

自機のセルに関連する当たり判定のみ行うので大量の敵弾が出ているときに威力を発揮してくれると思います。まぁ自機の位置で判定範囲が大きく異なるのでこれも気休め程度。セルの境目にいると結局全弾と当たり判定を取ることになる。。。これさえ解消できればかなりの高速化のような気がするが…


■負荷テスト
かなり久々に負荷テスト。
弾をとりあえず大量にだしてみるっていうテストです。
当たり判定が復活した今、テスト環境は実戦とほぼ同じ。
これが実際に使われる弾数の基準になります。

■結果
弾幕
なんだこれ；めっちゃ遅いぞ；
N904iでは自機が40個弾を出している状態で敵弾100個いかない程度で処理落ち。
自弾をすべて消すと敵弾200いかない程度で処理落ち。
正直お話にならない気がする…
当たり判定をきれば前回の穣子の弾幕テストで見たように自機弾+弾150はいけるので、当たり判定が重い。
20fpsモードでは1ループで当たり判定3回もとってるのが明らかに響いてるよなぁ。
しかしこれを１回にしてしまうと弾のすり抜け現象とかが今の仕様では起こりかねない。
だが１回にしないと速度が…
移動軌跡との当たり判定とかとればいいんだろうか；

3DCGの処理速度も今になって響いてる感じ。
特にN904iでは弾なし状態で18msも処理を食ってる。
自機がショットをオンにするだけで28msまで膨らむのでもういっぱいいっぱいってな感じ；

20⇔30リプレイ互換を捨てて判定精度を落として高速化するのか。
ここは潔く自弾3DCGをやめるべきなのか。(背景3DCGはやめないｗ)
2D+非透過でSTG要素を伸ばすべきなのか。

だがF系とかは弾なしで1桁をマークできるから実はこの遅さはN特有というのも十分にありうる。

うーん悩みどころ。

02 : 08 : 54 | 東方らしきもの | コメント(2) | page top↑

熱出てダウン中

2008 / 07 / 15 ( Tue )
先週のとてつもない忙しさから日曜についに38.4出してダウンしてます；
最後の２徹が効いたか…多分普通に風邪。

20 : 06 : 06 | 雑記 | コメント(11) | page top↑

線形4分木高速化

2008 / 07 / 06 ( Sun )
線形４分木メソッドを自分なりに改良してみた。
オリジナルがC++で前のはJavaにほぼそのままの形だったので不自然な部分がいっぱいでした。

□やったこと
・空間のArrayList化
オリジナルは双方向連結リスト。後部に追加したものが後部から消されていくスタックが多様されていましたが、そこを自前のArrayListにすることで高速化。ArrayListには最後部要素の高速削除機能を追加しときました。自前ArrayListの中身はただの配列なので走査が高速に。ただ各オブジェクトからそれぞれ削除情報をうけとっても後部削除にならない場合は遅くなるので、木を走査後、必ず登録は解除される。(止まる敵なんてぜんぜんいないから大丈夫。)
・1クラス化
上記の変更でCellクラス、OFTクラスが不要になったので削除。
・空間の有無の確認
オリジナルにもある機能ですが、こちらはboolean配列で擬似的に有無をあらわしてみた。これで木の走査で不要な空間にアクセスすることがなくなった。

□結果
N904i+20fpsモード+4分木最大深度3において、

ボール50個　⇒　7ms
ボール100個　⇒　16ms
ボール200個　⇒　50ms

前回に比べると大体倍速といったところでしょうか。
200個においては総当りよりも5〜6倍速。また、50個以下においても総当りよりも高速でした。

これでとりあえず４分木を使うか使わないかを悩まなくてすむかな。

□追記
半ば専用のスタッククラスを作ってさらに高速化
ボール50個　⇒　6ms
ボール100個　⇒　15ms
ボール200個　⇒　45ms
速くはなったけどランダム生成なのでこのくらいは誤差。
しかし200個時になると結構大きな差に。
全部ArrayListを使ってたところを全部そのスタッククラスにしたところ、総当りも高速化。
エラー処理が甘くて機能も限定すれば速度があがりますなぁ。
ボール50個　⇒　14ms
ボール100個　⇒　51ms
ボール200個　⇒　198ms

23 : 10 : 06 | 携帯アプリ | コメント(1) | page top↑

線形4分木

2008 / 07 / 06 ( Sun )
線形4分木線形4分木クラスが完成しました。画像はテストアプリ。

考え方からソースの原型まで『マルペケつくろーどっとコム』を参考にさせていただきました。解説はわかりやすすぎて感動ものです！
ただケータイ用なので、いろいろ省略して作ってあります。

・空間は最初に一括作成
途中で空間作成よりも大量だが一定のメモリ消費を取ってみました。空間の有無のチェックも取り払ってます。
・衝突リスト作成処理の省略
自前の低速なリストしかないので、直接各オブジェクトの衝突判定メソッドを呼ぶことでリスト作成をしないようにしました。スタックは自前のArrayListで。
・その他
他にも不要になったチェック処理などもはずしてあります。メンバのアクセスにはgetメソッドやsetメソッドで統一。

■テストアプリ
ランダムでボールを作成し、他のボールと接触している場合、接触しているボールの数により色が変わるアプリを作成。極力実際のアプリと同様の構造をとらせています。なので、60fps基準、20fpsモードなら衝突判定とボールリスト走査は1ループに3回行われることになります。キー操作でボールを増やしたり（位置・サイズはランダム）、また衝突判定を４分木⇔総当りと変更可。

□結果
N904i+20fpsモード+4分木最大深度3において、
・４分木モード
ボール50個　⇒　判定回数270回、16ms
ボール100個　⇒　判定回数1511回、34ms
ボール200個　⇒　判定回数5270回、85ms
・総当りモード
ボール50個　⇒　判定回数2500回、20ms
ボール100個　⇒　判定回数10000回、73ms
ボール200個　⇒　判定回数40000回、290ms

※４分木での判定回数は実測値、総当りはおおよそ。

全体的に４分木のが高速。ただよく考えたら総当りでも同じ組み合わせが発生しているのを考慮してなかったので判定回数はここからさらに半分にできる。と思う。４分木の方は木の走査にコストがかかっているようで、50個以下の場合は総当りの方が高速の場合がほとんど。ただ後半はさすが４分木の方が圧倒的に高速。処理時間的には４分木が線形増加、総当りが二次関数的な増加。
ちなみにエミュなら４分木の方がさらに高速。


■アプリに載せるかどうか
前回書きましたが実際のアプリではすべてのオブジェクトがすべてのオブジェクトと当たり判定をチェックする必要はないわけですよ；現行のものでは種類別に別リストで管理してあり、衝突判定は対象のリストに対してのみ総当りで、すべてのオブジェクトとの総当りではありません。(たとえば敵弾と自機間では自機が敵弾にして一回走査を行うだけ。)

４分木の今の方法でこの速度で衝突判定を行うには判定対象がすべて同じ木に登録されてある必要があります。しかしそれでは必要のないオブジェクトも候補にはいっちゃって木の走査で結構なロスが発生する。。。
そのロスのこともありますし、オブジェクト数が少ない場合は総当りの方が高速であることを考えると、ほとんどの場合総当りの方が高速であるのでは。と。

なら４分木は採用できない；；；


■そもそも問題は別のところ？
４分木のパフォーマンスをさらに上昇させれば普通に使えるかもしれませんが、
何より問題は60fps互換を目指して20fpsにおては１ループ3回も衝突判定してる点でしょう；
これが一回でいいなら単純処理時間は3分の1になります。

どうやらこの辺を考え直す必要がありそう。


■そもそもなぜ60fps互換？
確か30fpsでとったリプレイを20fpsでも再生できるようにだっただろうか。
60fps用の設定データひとつから20fpsと30fpsを作ることができて、それをするのにループ回数で制御するようになったことから当たり判定の回数も増減するようになったんだったかなぁ。

リプレイなんてそんなに配るものじゃないんだから、いろいろなfpsでも再生可能なリプレイを作成できる60fps互換モード、プレイ時は軽量だが固定のfpsでしかリプレイを再生できない非互換モードをつくろうかな…

19 : 26 : 07 | 雑記 | コメント(2) | page top↑

速度面最後の難関？

2008 / 07 / 01 ( Tue )
どーも、野菜ジュースは緑が一番体にいいように感じます、つんです。

結構深刻な問題を発見；
オプションをつけて初めて気づいたのですが、当たり判定のコストが高すぎる。というもの。

今の状態。
・敵弾・自弾・敵・自機などはユニットとして管理し、ユニットは種類別にリストで管理している。
・当たり判定は弾以外のすべてのユニットが対象のリストに対して総当りで当たり判定を行う。

敵弾⇔自機間なら自機は常にひとつなので敵弾リストを一回すべて見るだけで判定終了。つまり『敵弾の数x判定時間』かかる。
ところが自弾⇔敵となるとどちらも数は可変。ということはかかる時間は単純計算で『自弾の数x敵の数x判定時間』。。。自弾最大数はオプション最大数で40個程度を予定しています。敵の数が10にもなれば、判定にかかる時間は自弾なしのとき敵弾400個相当の負荷になるということ。

実際に敵の数が10程度のときオ自弾40程度(オプション4個)+敵弾80程度で処理落ち。
敵の判定を切ると20ms近く速くなるでその問題の大きさがよくわかる…
ボス戦ならまったく問題ないんですがね；道中が；


はやいところこの辺の高速化考えないとなぁ。
まぁ確実に総当りがまずいことはわかる。ただそれにかわる方法が思いつかないのが現実。
…まずはググってくるか…


■追記
四分木-クアッドツリーか、、、確か前ににふさんが書いていたなぁ…
必要箇所のみアクセスして判定。
弾の当たり判定が届くところのグリッドにその弾の参照を登録していけばいいのかな？
おもしろそうだ、やってみよう。

■追記の追記
早速すばらしいサイトを見つけました。…これはすごいｗ
線形4分木にモートン。。ふむふむ。

22 : 40 : 45 | 東方らしきもの | コメント(4) | page top↑
| ホーム |

カウンター

プロフィール

3DCG歴:2005年8月から今まで。
iアプリ歴:2005年2月から今まで。
C言語歴:2006年4月から今まで。
VB歴:2007年3月からちょっと。
Delphi歴:2007年3月からちょっと。
PIC歴:2007年5月から今まで。
PCイラスト歴:2007年12月から今まで。
DTM歴2008年2月から今まで。
PHP歴2008年4月からちょっと。
C++歴2008年4月からちょっと。

ブログ開始日2005/10/11

iアプリ公開中↓
『はい、どーも!!物置。2nd』

多分連絡先↓
metal_tsunアットinfoseek.jp

カテゴリー

リンク

このブログをリンクに追加する

猛烈片思いリンク中!!

最近のコメント

最近の記事

バナー

当サイトはリンクフリー。画像への直リンクは禁止です。

バロメーター

RSSフィード

月別アーカイブ

ブログ内検索