いつも大変お世話になっております。
kirainです。m(__)m

いろいろと勉強した事を生かして？(^^;)ゲームを作ってみたのですが・・・
動作がかなり鈍いものが出来上がってしまいました。

１．50pic×50picのpanel_mcを１つのパネルとし、それを100個（10行10列）Duplicateして並べる。
２．直径50picの丸いMy_mcが１で敷き詰めたパネル上をキー操作で動く。
３．イベントを起こすためのevent_mcを、パネル上にDuplicateして散らす。（100近くあり、ゲーム中ワラワラ動きます）


My_mcはキー操作で動かしますが、計算で_x、_yを数ピクセルづつ加減しています。
5行5列程度のテストでは問題なかったのですが、いざパネルを多くしてみたらかなりMy_mcの動きが鈍くなりました。
またステージ上で再生されているほかのアニメも再生速度が遅くなりました。
（タスクマネージャーで見たらCPU使用率100%になってました^^;）

panel_mc、event_mc、My_mc、どれにもonMovieClip(enterFrame)で200行くらいのスクリプトが記述してある事は関係あるでしょうか？
MCの数が多く、またさらにそれらがenterFrameで行なっている仕事量を考えるとちょっと自分でも怖いです。
（主に、音量のセット、My_mcとのヒット調べ、event_mcの位置を計算、などしています）

実際にスクリプトの内容をみないと判断しにくいと思うのですが、
・スクリプトの書き方に問題がありそうなのか、
・そもそもこれだけの量のenterFrameがあることが問題なのか、
そのあたりについて、まずアドバイス頂ければ幸いです。m(__)m

よろしくお願いいたします。

----------------
Kirarin

こんにちは。

スクリプトの載ったインスタンスを100個複製すれば、当然スクリプトもそれぞれのインスタンスにコピーされます。100個分の変数を宣言し、100個分のメモリを確保し、100個分のイベントが参照されることになります。
例えば、位置の計算処理は関数にし、フレームで宣言もしくはクラスメンバにしておき、イベント内では関数の計算結果の適用のみをしたりします。そうすることで計算処理に使った変数はインスタンス変数として残ることなく、アクティベーションオブジェクト（関数内で宣言された変数群等）としてメモリから削除されることが出来ます。

ただ大抵の場合（環境にもよりますが）、速度は描画量に反比例するように思います。試しに_qualityを下げて実行してみて下さい。それで大幅にパフォーマンスが改善されるのなら、大量のイベント処理よりも描画量の多さが足を引っ張っているのでしょう。

引用：

マツダさんの言うようにクオリティを下げてみるとか同じような動きをするトゥイーンをつけたMCを100個並べてみて現状と比べた上で負荷がかかる原因の所在を追求してみるといいと思います．

----------------
nao [seto@graffiti-web.org]

マツダさん、s-nさん、早速のアドバイスありがとうございますm(__)m

ひとまず週末中に試して週明けには結果がご報告できるようにしたいと思います。
出来るだけ関数化も計ってみます。

----------------
Kirarin

描画の処理スピードは、アニメーションでもスクリプトでも共通の要因が少なくありません(たとえばアルファの描画)。
引用：
MovieClip.hitTest()メソッドは、負荷の高い処理です。多数のMovieClipの総当たりチェックは、避けるべきでしょう。
引用：
onClipEvent (enterFrame)の存在自体が高負荷ということはないと思います。

----------------
　

フォローありがとうございます。確かにMovieClip.hitTestは重いです。
引用：

ただ各ムービークリップにonClipEvent (enterFrame)を置いて処理するよりも、一つのイベントハンドラに、forステートメント等を使って同様の処理をする関数を割り当てている方が高速なのですね。
引用：

マツダさん、s-nさん、野中さん、いろいろとありがとうございましたm(__)m

今回試してみた結果をご報告いたします。
以下「変わり具合」については正確な数字などではなく、あくまでも私の主観によるものとなってしまいますが、ご容赦くださいm(__)m

１．関数化してみる
　正しい構造化の方法は熟知していませんが、出来る限りスッキリとしたスクリプトを作れるようになるためにも、まずは出来るだけの関数化を行なってみました。
　ただ残念ながら、あまり動作上の違いはありませんでした。

２．再生時の「画質」を高→低にしてみる。
　スクリプトに手は加えておりませんが、気持ち、早くなったような気がしました。

３．アルファ塗りの見直し
　アルファ塗りが影響するという頭がなかったので、「アルファ＋グラデーション塗り」をかなり多様していました。
　これを全て見直し、必要最低限に留めました。数にしておよそ100以上の塗りを修正したところ、　かなり動きがよくなりました。
　（本当はグラデーションもやめたほうがいいのでしょうが、今はひとまずアルファ指定のみ、止めてみました）

４．hitTest関数の見直し
　これも多様していました。
　hitTest関数でなく演算で判定出来るものは演算に置き換えました。
　（パネル1つ1つにもhitTest関数がありました^^;）
　微妙ですが良くなったと思います。


以上4項目を順に試してみて、結果、少ないパネル数で試していたときよりは遅いですが、かなりの改善が図れました。
本当にありがとうございましたm(__)m。

ただし、パブリッシュするサイズが800×600で、それを100%でブラウザに表示している時は良いのですが、最大表示してしまうと、まただいぶ遅くなってしまいます。
・グラデ塗りを止める
・各MCのフレーム数を減らす
など、もう少し何かできる事を探してやらないとだめかな？と思っています。

より何か改善できる方法が見付かったら、引き続き投稿したいと思います。m(__)m

----------------
Kirarin

kirarinさん、こんにちは。
自分もゲームを作っていると同じ様な悩みに時々直面します?。とくに自分は低スペックマシンなので。
さて、既にみなさんが書かれていることですが、たくさんのonClipEvent(enterFrame)じゃなくて、たくさんの複雑な再描画を毎フレーム実行させるのがキツイのだと思います。

とぼしい私の経験からですが、毎フレーム「MCの描画に関わるプロパティを変更する関数」を実行し、かつそのMCが複雑な図形（アルファやグラデ、カスタムラインなんかを多用してるやつ）だったりすると、かなり高負荷になります。
スクリプトに関して言えば、毎フレームすべてのMCにチェック&変更させるより、必要なものを必要な時だけチェック&変更するとか。画像なら、描画の速いベタ塗りかビットマップを使うとか…でしょうか？
ただ、単純な図形MCでも個数が多くなれば、個々のonClipEvent(enterFrame)に関わらず、毎フレーム一斉に動かすのはキツイです。
自分も勉強中なので、これだ！ってことは言えず申し訳ないのですが、こちらのスレッドなども「処理スピードについて」のお話なので参考になるかもしれません。

rin-koさん、アドバイスありがとうございます。m(__)m

同じような局面に当たる方も少なくないのですね。
あれから試行錯誤してみましたが、アルファ塗りを止める以外に一番効果があったのはやはりグラデーションを止めることでした(^^;)
フレーム数を減らすというのはそんなに目立った効果が得られませんでした。
（もちろんスクリプトの書き方にも問題は残っているのかもしれませんがね(^^;)）

3D感を出したい時にはどうしてもアルファ、グラデ、など多用しがちになってしまうのですが、ゲーム性に関係ないところは割り切ったほうがいいのかもしれません。

教えていただいたスレッドは野中さんにも教えていただいていたので拝見していました。
目の錯覚を利用するというのはかなり高等な技術だと思いますが、私も今後、勉強していきたいと思います(*^∇^*)
ありがとうございました。m(__)m

----------------
Kirarin

少し逸れますが、イベントハンドラメソッドを使っているときに有りがちな、スコープチェーンのせいでアクティべーションオブジェクトが残ってしまう不具合を、試しに出来るだけ排除してみた所、思ったよりもパフォーマンスが改善されました。
場合によりけりでしょうが。