>list内に約60以上、オブジェクトが入ると遅延して来ます厳密にはトピの質問内容通り、約30以上から遅延は始まっており、60以上では完全にゲームプレイに支障をきたしているレベルの遅延となっています。Objectを大量に描画したいが...重い。ISLe()さんも言った通りひとつのlistにすべてのオブジェクトをまとめて衝突判定させてやる方法はゲームプログラムにおいて別に特殊でもなんでも無いと思うんです。ひとつのlistで管理するならば抽出させる時に二重for文を利用するのは避けられないはずです。わたしの場合、衝突判定は更新処理の中にあって、衝突判定のための独立したループはありません。衝突判定の相手も、そもそもする必要のない無駄な判定などを省きます。総当りなんて無茶は最初から除外しますね。コストの増加が常に線形になるように考えます。リストそのものを分けなくても、グループ化のオブジェクトを作ればメインのリストはひとつのままで拡張できます。No.20の赤字で書かれた部分は、わたしにはひとつのリストで更新処理を一回だけ回すという意味に見えました。ことあるごとに何回もループを回すという発想はありませんでした。Objectを大量に描画したいが...重い。5年前>1000000以上も増加するレベルになってますね。100要素だと3重ループ以上している計算になりますね。2重ループだと数学的に計算がおかしいのでコードの流れの見直しが必要かと思います。100要素なら2重ループで100の2乗なので1万のはずです。>すべてのオブジェクトをひとつのlistに入れる方法を取った事が問題、>というのはちょっと現代の言語処理速度にガッカリな感じです。ちなみに速度にがっかりされるのは、Releaseビルドされてからのほうが良いと思います。いうパターンは劇的に早くなるでしょう。パワーに任せて解決しても根本的にアルゴリズムに問題があると思うのでDebugビルドでも問題なく動くようにするのが鉄則です。Releaseビルドに頼るのは最後の手段ですからね。8bit時代なら、こんな事したら数秒に1コマも動かない激遅ゲームだと思いますよ。コードを見直すことが必要です。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。No.20の赤字で書かれた部分は、わたしにはひとつのリストで更新処理を一回だけ回すという意味に見えました。ことあるごとに何回もループを回すという発想はありませんでした。二重for文にしても、当たり判定なのですから無駄なループをさせているわけではないはずです。そのオブジェクトが、list内のすべてのオブジェクトと今衝突しているか判断するそれを毎フレーム行っているだけです。衝突判定の相手も、そもそもする必要のない無駄な判定などを省きます。「する必要のない無駄な判定」なのでしょうか?listの中を対象だけに絞っていれてれば、そんな判定すらいりませんがすべてのオブジェクトをいれたlistを扱う方法では、それでは無理な話なはずです。ひとつのリストで更新処理を一回だけ回す更新処理は当然として、衝突判定も自分は、毎フレーム1回だけ回しています。衝突判定は更新処理の中にあって、衝突判定のための独立したループはありません。listにあるオブジェクトたちの更新関数の中で衝突判定を???それとも、ObjectMgrの更新の中ででしょうか?いや、でもそれなら、HitCheckの更新でやろうと一緒ですよね、、どいうことでしょうか。Objectを大量に描画したいが...重い。100要素だと3重ループ以上している計算になりますね2重ループだと数学的に計算がおかしいのでいや、すみません、すごいスピードでloop回数が増加するので自分が計算苦手なのでアバウトに話しただけです。3重ループはしてないでしょう、for文は2カ所しかないのですし。ちなみに速度にがっかりされるのは、Releaseビルドされてからのほうが良いと思います。いうパターンは劇的に早くなるでしょう。?それだとありがたいです。Releaseビルドに頼るのは最後の手段ですからね。{↑この四つの箇所は絶対必要じゃないですか?わからなくてすみません。Objectを大量に描画したいが...重い。判定をやっている最中終わり位置のイテレーターが変化しないなら(判定のチェック中にlistに項目の追加がない)終了位置のイテレーターは最初に取得すれば使いまわせるということではないでしょうか。僕もそこの改善でかなりループを軽くできたことがあります。intのところをlist<type>::iteratorに書き換えれば。Objectを大量に描画したいが...重い。5年前そんな難し話じゃないですよ。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。5年前>いや、すみません、すごいスピードでloop回数が増加するので>自分が計算苦手なのでアバウトに話しただけです。>3重ループはしてないでしょう、>for文は2カ所しかないのですし。プログラムで確認できるのでループ数と付きあわせてみてください。1フレーム辺りでリスト数xリストの数と等しくなるはずです。いう所は手を抜かないでくださいね。自分を信じないようにしましょう。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。Objectを大量に描画したいが...重い。二重for文にしても、当たり判定なのですから無駄なループをさせているわけではないはずです。そのオブジェクトが、list内のすべてのオブジェクトと今衝突しているか判断するそれを毎フレーム行っているだけです。それは縦横無尽にドット単位で動くシューティングにおいて必ず行い続けなければならない処理のはずですよね?キャラの移動処理などを含む更新処理のループが別にあるのではないのですか?そうであれば、わたしの感覚として、ことあるごとにループを組んでいるということになるのですが。当たり判定には、『当たっているかどうか』『当たっていたらどうするか』の2段階あります。『当たっているかどうか』を総当りで求めるのは無駄でしかありません。軽量化」などでネットを検索してみてください。空間分割などさまざまな手法が見付かるはずです。メジャーなテーマなのです。「する必要のない無駄な判定」なのでしょうか?listの中を対象だけに絞っていれてれば、そんな判定すらいりませんがすべてのオブジェクトをいれたlistを扱う方法では、それでは無理な話なはずです。いくつもヒントを出しました。タイルマップは同じ大きさのマスが格子状に並んでいるので、どのマスと重なっているかは簡単な計算で求められます。重なっているマスにあるオブジェクトとだけ当たり判定をすれば良いのです。敵の弾グループというオブジェクトを用意します。ひとつのリストに登録するということは共通のインターフェースを持っているはずですよね。敵の弾は、敵の弾グループにリスト登録します。敵の弾グループをメインのリストに登録して、敵の弾グループは自分に登録された敵の弾に処理を委譲します。敵の弾同士は当たらないとすれば、敵の弾グループで弾くことができ、同様にグループ化することでループ回数を減らせます。空間分割手法などを使う場合も同様です。『誰と』当たっているかを求める方法はいくらでも工夫の余地があります。工夫の余地が入るようにコーディングすべきだと思います。更新処理は当然として、衝突判定も自分は、毎フレーム1回だけ回しています。それが、二重for文だから、量が多い?というだけですべての要素を毎回通らせるのは、無駄な処理では無いと思うのですが自分は思い違いをしているのでしょうか?更新処理で回し、衝突判定で回しているわけですよね。わたしの感覚ではそれは無駄です。Objectを大量に描画したいが...重い。36の方法に変えたところ遅延がまったく起きなくなりました。問題自体は解決しました。結局、総当たりさせる自分の衝突判定方法とひとつのlistでオブジェクトを管理するということの相性の悪さで起きた遅延だったということですね。usaoさんいいえ、違います。いうことではありません。キャラの移動処理などを含む更新処理のループが別にあるのではないのですか?はい、別にあります。オブジェクトlist管理のクラスにて、list内の更新をしているのです。そこでついでにオブジェクト同士の衝突判定もしろ、ということでしょうか?確かに、自分は癖というか、衝突判定するクラスを作るやり方を最初に覚えたのでなんの疑問も無く、すべての製作ゲームで衝突判定はクラスで作ってます。当たり判定には、『当たっているかどうか』『当たっていたらどうするか』の2段階あります。『当たっているかどうか』を総当りで求めるのは無駄でしかありません。空間分割は初めて聞きました。こことか読んでみましたが、頭が爆発しそうです。http://marupeke296.com/COL_2D_No8_QuadTree.htmlゲーム制作を続けて行く上で必要な知識だというのは理解出来ますので勉強してみます。タイルマップは同じ大きさのマスが格子状に並んでいるので、どのマスと重なっているかは簡単な計算で求められます。重なっているマスにあるオブジェクトとだけ当たり判定をすれば良いのです。ああ、タイルマップで衝突の判断をするんですね。衝突判定処理は、オブジェクトの座標はしったこっちゃ無くてオブジェクトがいるマスを認識していればいいと。イメージは見えましたが、碁盤感覚でシュミレーションゲームのイメージです。それをアクションゲームやシューティングにも利用するイメージを持つようにならなければならないのですね。意識していこうと思います。27の件をお待ちしております。Enemyクラスがインターフェースとして働くことになるのでそれに関する部分は自ずと共通化されることになります。各キャラクタの固有部分が分離されて、オブジェクト別に状況に応じた柔軟な設計が可能になります。自分の中ではENEMYクラス内でswitch文で分けて処理する方法以外考えられないのでソレ以外の方法?でどうされてくるのか楽しみです。Objectを大量に描画したいが...重い。Objectを大量に描画したいが...重い。5年前オフトピック>usaoさん>いいえ、違います。>そういうことではありません。Objectを大量に描画したいが...重い。5年前usaoさん自分は最初、あなたのいう↓の処理方法でやっていました。それで遅延が起きていたんですよ。}}それで遅延が起きていたんです。itをメインとして、it2で対象を探すわけですがit==A、it2==Bの衝突判定をしている場合はもちろん重複するようなit==B、it2==Aの衝突判定はしていません。Aに関係無いit==B、it2==Cはしますけど。Objectを大量に描画したいが...重い。Objectを大量に描画したいが...重い。私も2重ループが遅い原因でした!って片付けるのは何かが違うと言うかゴーストがささやくと言うか、もう少し具体的な数字などの情報がほしいです。このトピック見ている人のためにも必要な情報だと思います。2重ループの場合、NxNでM万回ループしていて処理時間はQmsでした。これはループだけの処理時間です、ループ改善後は、M2回ループしていて処理時間はQ2msでした。感じで情報を出せませんでしょうか。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。いう状況だったりすると今さら再検証とか無理なのかもしれませんが.一応,補足しておきますと,>loop数ですが、これがまたすごいスピードで増加しまして、>これが処理として少ないのか多いのかわかりませんが>その遅延状態にはloop数が2,3秒もしないうちに>1000000以上も増加するレベルになってますね。Objectを大量に描画したいが...重い。{を真っ先に導入したのですが、遅延状態は変わりませんでしたのでこれはObjectMgr::getInstance()の書き方の問題では無いのだなと思いました。(が、一応No.39でのソフト屋さんの「4回も出てくる必要性は無い」との言葉を重んじて遅延状態の改善は見られなかったのですが、教えてもらったこの方法を使ってfor文は書いています)で、僕が発言しました>loop数ですが、これがまたすごいスピードで増加しまして、>これが処理として少ないのか多いのかわかりませんが>その遅延状態にはloop数が2,3秒もしないうちに>1000000以上も増加するレベルになってますね。調べたのはHitCheck::hitcase()が呼ばれた数ではありません。二重for文でjを通った数(list内のソレが対象かどうか探した回数)です。その増え方ですが、総当たりなのでlist内のオブジェクト(要素数)が増えれば、当然通る数も増加しますがその増加の量が1要素数に対し、なぜか尋常ではない量でした。list内の要素数が少ないと遅延は起きません。listに沢山入ると遅延するのです。}としたら、まったく遅延が起きなくなりました。listBにオブジェクトを200ほど入れても遅延は起きません。自分としてはこれで解決したと思ったのです。確かに、数値として出して無いのはうやむや?っぽくてアレですが、皆さんの言われる数値の出し方が自分はちょっとハッキリわかりません。時間を置く場所もわかりませんし、どの状態でいつの数値をどう説明すればいいのか、ちょっとわからないのです。知識というか技術というか、それらが不足しているからでしょうね。その辺の手ほどきをして頂ければ、正確に実行し、お伝えしたいと思いますが。2重forの内側で、大体何回ぐらいループしてますか?list要素数次第では恐ろしい回数回りそうです。実際、二重for分のjの場所に設置したカウンターは毎フレーム凄まじい増加量が見て取れました。数千のレベルではありません。数万、いや、数十万のレベルで増え続けてました。Objectを大量に描画したいが...重い。5年前>その増加の量が1要素数に対し、なぜか尋常ではない量でした。やっくるさんの予想と、その数に大幅なズレが有るなら想定外の動作をしている証拠です。今回一見直ったように見ますが、実はプログラムは思っても見なかった動作をしている可能性があります。やっくるさんが1フレームに1回だけこ当たり判定の2重ループが動作すると説明してますが、そう思い込んでいるだけの可能性が高いです。>アレですが、皆さんの言われる数値の出し方が自分はちょっとハッキリわかりません。>ループ数も凄いスピードで増え続けていますし、>時間を置く場所もわかりませんし、>どの状態でいつの数値をどう説明すればいいのか、ちょっとわからないのです。>それは自分がまだプログラムの初心者で、その辺のテクというか、>知識というか技術というか、それらが不足しているからでしょうね。プログラムの動きを書いたのはご自身ですから、1フレームに通る回数、1フレームにループするであろう回数、処理として許容できる時間を想定できるはずです。想定できないなら、一度じっくり考えてみてください。それを検証できる方法を考えます。検証する方法を考えるのはプログラムを組むこととなんら変わりがありません。プログラムを考えれたなら、検証する方法も同様に考えられるはずです。テストとデバッグは、プログラムの工程の大半を占める非常に大事な作業です。これが出来ないとプログラムは完成しませんので身につけましょう。今がその時だと私は思います。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。27の件をお待ちしております。Enemyクラスがインターフェースとして働くことになるのでそれに関する部分は自ずと共通化されることになります。各キャラクタの固有部分が分離されて、オブジェクト別に状況に応じた柔軟な設計が可能になります。自分の中ではENEMYクラス内でswitch文で分けて処理する方法以外考えられないのでソレ以外の方法?でどうされてくるのか楽しみです。省メモリを意識したサンプルコードにしてみました。0;}クラスのインターフェースとインプリメント(実装)の分離は、これも検索すれば山ほど記事が見付かると思います。デザインパターンとしても有名ですしね。このサンプルでは全部パブリックにしてしまってますが、オブジェクトのメンバ周りやそのアクセスをどうするかといったあたりはいろんな方法があるので調べてみてください。Objectを大量に描画したいが...重い。Objectを大量に描画したいが...重い。Objectを大量に描画したいが...重い。5年前ISLe()さん自分なりに努力したのですが大変申し訳ないのです。書かれているソースが私のレベルではまったくトレース出来ませんでした。理解することが出来ませんでした。自分のレベルとで天と地の差があるのは最初から承知していますがそのISLe()さんにわざわざソースを書いてもらったにも関わらずなにひとつ得られなかったことが自分は残念でなりません。「初心者相手にこんな難解なレベルにしあげてさ、この意地悪!」なんて申しません。理解出来る自分がいたらいいなと思います。ありがとうございました。Objectを大量に描画したいが...重い。5年前おそらく、「実装を分離する」という概念そのものを受け入れられないでいるのではないでしょうかね。No.7で、制御関数を外から繋ぐようなことを本で読んだと書いておられますが、たぶんそこに書いてあったのと同じようなものだと思いますが。No.56のコードは、あくまでも、概念の説明のために、基本的な文法だけを用い、単独で動作するように、書き下ろしたものです。ミクプラは自由にリンクできます。