作品やら思ったコトを書き留めておく、付箋みたいなトコロ。
M.E.の思うトコロ
壊)最適化が済んだので、ネットワーク対戦の本格実装
最適化が済んだので、3日ほど休暇を頂きました。
これから、コワリス壊のネットワーク対戦完成に向けて色々やります。
ネットワークのメニューの作り替えとかあるんですが、
階層構造が変わるようなデザイン変更が結構だるい。
まぁ、ここを過ぎれば、あとはα版の動画制作に王手なのですがね。
αが過ぎたら、様々なオプションの実装と、NPC対戦でβ版へ移行、
完成版は、要望を聞きながら突き詰めていきたいと思います。
予定
α版完成:3月3日前後
β版完成:3月17日前後
完成版:4月4日前後
これから、コワリス壊のネットワーク対戦完成に向けて色々やります。
ネットワークのメニューの作り替えとかあるんですが、
階層構造が変わるようなデザイン変更が結構だるい。
まぁ、ここを過ぎれば、あとはα版の動画制作に王手なのですがね。
αが過ぎたら、様々なオプションの実装と、NPC対戦でβ版へ移行、
完成版は、要望を聞きながら突き詰めていきたいと思います。
予定
α版完成:3月3日前後
β版完成:3月17日前後
完成版:4月4日前後
コメント ( 12 ) | Trackback ( 0 )
壊)ブロックをこするときの当たり判定を最適化
検証用バージョンv2
今までは、Flash独自の機能を使って当たり判定を出していました。
しかし、その機能が重いのに結構大雑把なため、実装を変えてみました。
ブロックを回転させたときに、溜まっている300個のブロックすべてを検索対象にし、
それを落下ブロック分だけ繰り返すということをしていました。
つまり、「300×落下ブロックの個数」のコストでした。
今回からは、ブロックの位置を検索しない事で高速化しました。
原理を簡単に言うと、一つの落下ブロック当たり25箇所の地点が、
ブロック溜りのどこに相当する位置であるかを計算で求めています。
計算でブロックの位置が分かるので、その場所にブロックがあるかを調べるだけです。
これにより、「25×落下ブロックの数」の大幅な最適化。
これにより、当たり判定が高速化しました。
調べる地点が、25箇所という大雑把さなのに、
Flashの機能を使うより精度が高いという、驚きの結果。
これで、いくらか軽くなると良いのですが。
今までは、Flash独自の機能を使って当たり判定を出していました。
しかし、その機能が重いのに結構大雑把なため、実装を変えてみました。
ブロックを回転させたときに、溜まっている300個のブロックすべてを検索対象にし、
それを落下ブロック分だけ繰り返すということをしていました。
つまり、「300×落下ブロックの個数」のコストでした。
今回からは、ブロックの位置を検索しない事で高速化しました。
原理を簡単に言うと、一つの落下ブロック当たり25箇所の地点が、
ブロック溜りのどこに相当する位置であるかを計算で求めています。
計算でブロックの位置が分かるので、その場所にブロックがあるかを調べるだけです。
これにより、「25×落下ブロックの数」の大幅な最適化。
これにより、当たり判定が高速化しました。
調べる地点が、25箇所という大雑把さなのに、
Flashの機能を使うより精度が高いという、驚きの結果。
これで、いくらか軽くなると良いのですが。
コメント ( 2 ) | Trackback ( 0 )
コワリス壊のネットワーク対戦のチューニング その5くらい
検証用のバージョン
直接オブジェクトのディープコピーを渡して検証したら、
RTMFP経由よりちょっと軽くなりました。
でも、何故か重いです。
データは次のとおり
単体での処理速度
メイン : 平均 0.29623893805309737 ms 最大 10ms
トータルの最大 : 10ms
RTMFP経由
メイン: 平均 0.9333838001514004 ms 最大 39ms
サブ 1: 平均 0.4125662376987131 ms 最大 07ms
サブ 2: 平均 0.39137017411052233 ms 最大 07ms
サブ 3: 平均 0.38152914458743376 ms 最大 09ms
サブ 4: 平均 0.37395912187736563 ms 最大 16ms
トータルの最大 : 41ms
オブジェクト直接コピー
メイン: 平均 1.7802850356294537 ms 最大 68ms
サブ 1: 平均 0.850356294536817 ms 最大 25ms
サブ 2: 平均 0.8218527315914489 ms 最大 25ms
サブ 3: 平均 0.8242280285035629 ms 最大 26ms
サブ 4: 平均 0.8390736342042755 ms 最大 27ms
トータルの最大 : 101ms
オブジェクトの直接コピーでちょっと軽いのに、
これの処理時間が長いのは、見えなかった処理部分が出てきたのだと思います。
それにしても、単体では以前とは比較にならない位軽くなりました。
直接オブジェクトのディープコピーを渡して検証したら、
RTMFP経由よりちょっと軽くなりました。
でも、何故か重いです。
データは次のとおり
単体での処理速度
メイン : 平均 0.29623893805309737 ms 最大 10ms
トータルの最大 : 10ms
RTMFP経由
メイン: 平均 0.9333838001514004 ms 最大 39ms
サブ 1: 平均 0.4125662376987131 ms 最大 07ms
サブ 2: 平均 0.39137017411052233 ms 最大 07ms
サブ 3: 平均 0.38152914458743376 ms 最大 09ms
サブ 4: 平均 0.37395912187736563 ms 最大 16ms
トータルの最大 : 41ms
オブジェクト直接コピー
メイン: 平均 1.7802850356294537 ms 最大 68ms
サブ 1: 平均 0.850356294536817 ms 最大 25ms
サブ 2: 平均 0.8218527315914489 ms 最大 25ms
サブ 3: 平均 0.8242280285035629 ms 最大 26ms
サブ 4: 平均 0.8390736342042755 ms 最大 27ms
トータルの最大 : 101ms
オブジェクトの直接コピーでちょっと軽いのに、
これの処理時間が長いのは、見えなかった処理部分が出てきたのだと思います。
それにしても、単体では以前とは比較にならない位軽くなりました。
コメント ( 6 ) | Trackback ( 0 )
AS3のプレレンダリングがすごい高速な件
さて、ちょっと耳にした、「プリレンダリング」を試してみました。
方法は、こちらに説明されている通り。
Bitmapを AddChild して、BitmapDataの中身を入れ替えるだけ。
MovieClipを継承したクラスを利用すると、扱いやすいです。
普通のMovieClip(≒ MC)と、プリレンダリングとの比較。
5000個のブロックを、色を変更しながらヒビの加減を変えたとき。
普通のMC:10233.6ms
ビットMAPを貼ったMC:5786.1ms
プリレンダリング:22.9ms
普通のMCが10秒超で、15秒のタイムアウト寸前ですね。
それに比べて、圧倒的すぎる速度ですね。なんと、446倍速!!
コードの最適化で120%の高速化をしましたが、
44688.2%とか、正気の沙汰ではないです。
さらに、維持にかかるコストも低く、美味しいです。
これを使えば、とても重いFlashですら楽に動画化できます。
では、これで、実装を進めていきたいと思います。
方法は、こちらに説明されている通り。
Bitmapを AddChild して、BitmapDataの中身を入れ替えるだけ。
MovieClipを継承したクラスを利用すると、扱いやすいです。
普通のMovieClip(≒ MC)と、プリレンダリングとの比較。
5000個のブロックを、色を変更しながらヒビの加減を変えたとき。
普通のMC:10233.6ms
ビットMAPを貼ったMC:5786.1ms
プリレンダリング:22.9ms
普通のMCが10秒超で、15秒のタイムアウト寸前ですね。
それに比べて、圧倒的すぎる速度ですね。なんと、446倍速!!
コードの最適化で120%の高速化をしましたが、
44688.2%とか、正気の沙汰ではないです。
さらに、維持にかかるコストも低く、美味しいです。
これを使えば、とても重いFlashですら楽に動画化できます。
では、これで、実装を進めていきたいと思います。
コメント ( 1 ) | Trackback ( 0 )
フレームをばらしてみたけど、余計重くなった
コワリス壊の方で、ちょっと失敗談。
フレームの切り替えがとても重くて困っていたので、
この際、全部1フレーム目に描写したら、余計に重くなりました。
なので、最終手段として、プレレンダリングを使います。
こんどこそ、速くなるといいなぁ・・・。
フレームの切り替えがとても重くて困っていたので、
この際、全部1フレーム目に描写したら、余計に重くなりました。
なので、最終手段として、プレレンダリングを使います。
こんどこそ、速くなるといいなぁ・・・。
コメント ( 0 ) | Trackback ( 0 )
コワリス壊のネットワーク対戦が重い原因
いろいろ試した結果、「プログラムそのもの」は、とても軽いことがわかりました。
一番重い連鎖落下の部分の処理ですら、0.00001~0.002秒の処理時間でした。
コードの最適化をした結果、ここまで軽くなったのかもしれませんけどね。
負荷を計算すると、以下のようになります。
60フレームで必要な処理時間は0.016666秒以下(1/60秒)なので、
最大負荷でも 7人(最大人数) × 0.002秒(最大負荷) = 0.014秒(全体の最大負荷)
つまり、プログラム自体は7人対戦でもそこそこ耐えられます。
それで、肝心の重い原因は何かというと、「ブロックのフレーム変え」でした。
ブロックのフレームが変わるたびに、0.051~0.112秒もかかっており、
全体としてカクカクになる理由がこれでした。
これに対し、メモリを多めに消費する代わりに、
スムーズな描写を可能にする技術の搭載の検討をはじめています。
実装したプログラムでは、消費メモリが500MBくらいですので、
プレイには1GB以上のRAMを搭載したPCが必要になります。
といっても、最近のPCなら、2GB以上当たり前ですね。
一番重い連鎖落下の部分の処理ですら、0.00001~0.002秒の処理時間でした。
コードの最適化をした結果、ここまで軽くなったのかもしれませんけどね。
負荷を計算すると、以下のようになります。
60フレームで必要な処理時間は0.016666秒以下(1/60秒)なので、
最大負荷でも 7人(最大人数) × 0.002秒(最大負荷) = 0.014秒(全体の最大負荷)
つまり、プログラム自体は7人対戦でもそこそこ耐えられます。
それで、肝心の重い原因は何かというと、「ブロックのフレーム変え」でした。
ブロックのフレームが変わるたびに、0.051~0.112秒もかかっており、
全体としてカクカクになる理由がこれでした。
これに対し、メモリを多めに消費する代わりに、
スムーズな描写を可能にする技術の搭載の検討をはじめています。
実装したプログラムでは、消費メモリが500MBくらいですので、
プレイには1GB以上のRAMを搭載したPCが必要になります。
といっても、最近のPCなら、2GB以上当たり前ですね。
コメント ( 1 ) | Trackback ( 0 )
コワリス壊のネットワーク対戦が、思ったよりも重い件。
途中まで実装してみたところ、
コワリス壊のネットワーク対戦が、
思ったよりもかなり重くて、泣きそうです。
果たして、最適化できるのかどうか・・・。
コワリス壊のネットワーク対戦が、
思ったよりもかなり重くて、泣きそうです。
果たして、最適化できるのかどうか・・・。
コメント ( 4 ) | Trackback ( 0 )
壊リス・壊のネット対戦搭載まで、あと少し・・・。
壊リス・壊のネット対戦搭載まで、あともうちょっとです。
長かった内部の整理が終わって、ようやくネットワーク周りにたどり着きました。
あともうちょっとという感じです。
最近の変更点
1.プレイ画面用のインターフェイスの変更。
2.Conboの表示が復活し、獲得ポイントを消えたラインから表示。
3.Line・連鎖・Comboの表示方法を変更。
4.ボーナスゲームがアイテム扱いになり、爆発も爆弾と同じものに修正。
5.爆弾とボーナスゲームを同じ箇所で処理するようにしました。
6.ボーナスゲームのクリアに特典がつくようになりました。
7.ボーナスゲームのレーザーを3段階に変更。
8.壊モードで、Lineの消滅で同じ色のブロックを消滅させると、ボーナスが付くように変更。
9.スコアが動的に変更されるようになりました。
長かった内部の整理が終わって、ようやくネットワーク周りにたどり着きました。
あともうちょっとという感じです。
最近の変更点
1.プレイ画面用のインターフェイスの変更。
2.Conboの表示が復活し、獲得ポイントを消えたラインから表示。
3.Line・連鎖・Comboの表示方法を変更。
4.ボーナスゲームがアイテム扱いになり、爆発も爆弾と同じものに修正。
5.爆弾とボーナスゲームを同じ箇所で処理するようにしました。
6.ボーナスゲームのクリアに特典がつくようになりました。
7.ボーナスゲームのレーザーを3段階に変更。
8.壊モードで、Lineの消滅で同じ色のブロックを消滅させると、ボーナスが付くように変更。
9.スコアが動的に変更されるようになりました。
コメント ( 5 ) | Trackback ( 0 )