15種類の敵の処理をひとつのクラスでさせようと今の時代、重くなるはずないですよね?だとすれば、クラス内の処理では無くもっと根本が、自分の構成の仕方に問題があるんでしょうか?オブジェクトの管理について自分は現在、ゲーム中、オブジェクトlistをひとつだけ作り、そこにプレイヤーや敵、それらの弾、アイテムなどすべてのオブジェクトをインスタンス化しては放り込んで消滅するとflgを立て、毎フレーム最後にlist内から一括で削除しています。各オブジェクトが持つ変数の"ID"で判別、イテレーターにて抽出して処理しています。ちなみに、listを一つだけにしているのもいちいちプレイヤーの弾用のlistとかエネミーの弾用のlistとか作る方が大変でIDつけとけば判別出来るんだからひとつのlistで回せばいいとのアドバイスを受けたからです。Objectを大量に描画したいが...重い。5年前>申し訳ありませんが、出来ましたら、処理時間計測をする重要性と>カウント処理の時の様に、簡単な手順を示して頂ければ非常に助かります。遅延して困っているわけですから、遅延している原因を探さないと行けませんよね。それには、処理のあちこちで時間計測をして何処ネックか探さないといけません。経験を積まない限り、憶測だけで色々やってみても一向にケリが付きませんよ。こちらもソースコードを見ていないので、想像で原因を書いてますが的中率はもちろん低いです。さんの情報が正しいとも限りません。さんの報告は誤情報である可能性が常に付きまといます。言うことで、時間計測して現銀原因を探りましょう。処理にかかっている時間で問題点を探します。時間をミリ秒単位」で得られますので、処理開始と処理後の時間を得て差分を処理時間とします。これで顕著に遅い部分を探しましょう。最初はmain内のループなど大きな単位で、だんだん細かくメソッド関数まで降りてきます。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。その言い様だと、龍神録は"委譲"を使われているのでしょうね。龍神録のC言語のコードを見られたことがないのでしょうか?これです。http://dixq.net/rp/12.html【補足】コードを直す件は、別途やりましょうか。遅延バグ潰しとコードのリファクタリングの2つを一度にやるとろくな事になりません。遅延の原因を探すことです。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。遅延の原因を探すことです。関数の処理にかかっている時間を調べてみたいと思います。Objectを大量に描画したいが...重い。分けて時間計測で調査します。それで前半が重ければ、更に前半の半分で調べます。これを繰り返して絞り込んでいきます。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。開発環境になにを使ってるか知りませんが素直にプロファイラ使えばいいんじゃないでしょうか・・・プロファイラを使わないほうがいい理由とかあったら教えてください。Objectを大量に描画したいが...重い。開発環境になにを使ってるか知りませんが素直にプロファイラ使えばいいんじゃないでしょうか・・・プロファイラを使わないほうがいい理由とかあったら教えてください。expressなら初めからついていないってところでしょうか。【補足】VC++Express系に無料で容易に導入できて、初心者でも使いやすいプロファイラがあったら教えてください。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。委譲といっても対象はいろいろあるので、けっきょくはどういうふうに実装するかの問題に帰結します。複数の種類の敵をどうやって互いに影響し合うことなく実装するか、については簡単なサンプルコードを書いてみようと思います。気長にお待ちください。ソースコードのほうも。ひとつのリストに放り込んで回すのはふつうだと思いますよ。ヒープメモリの確保・解放はけっこう時間を食います。フレームレートがひどく落ち込むほどではありませんが。Objectを大量に描画したいが...重い。5年前オフトピックソフト屋さん、回答ありがとうございます。やっくるさんがご利用できるかはわかりませんが、もし学生ならMSのDreamSparkに入ってProfessional版を使えるようにするといいんじゃないでしょうか。処理落ちの原因を探るとき、重い処理を探すときなんかはクリティカルに役に立ちます。アドレスを入力して学生認証を受けて下さい。学校名が表示されない場合は「自分の学校が見当たりませんか」をクリックすることで市町村や機関別で検索ができます。それでも見つからない場合は「手動検証リクエスト」から手動で行って下さい。この場合、学生証のコピーと現在の成績証明書または課程一覧のコピーの両方を添付する必要があります。僕は高校の学生証をスキャナで取り込んで送ったら認証が通りました。Objectを大量に描画したいが...重い。さんが書きました:オフトピックソフト屋さん、回答ありがとうございます。やっくるさんがご利用できるかはわかりませんが、もし学生ならMSのDreamSparkに入ってProfessional版を使えるようにするといいんじゃないでしょうか。処理落ちの原因を探るとき、重い処理を探すときなんかはクリティカルに役に立ちます。アドレスを入力して学生認証を受けて下さい。学校名が表示されない場合は「自分の学校が見当たりませんか」をクリックすることで市町村や機関別で検索ができます。それでも見つからない場合は「手動検証リクエスト」から手動で行って下さい。この場合、学生証のコピーと現在の成績証明書または課程一覧のコピーの両方を添付する必要があります。僕は高校の学生証をスキャナで取り込んで送ったら認証が通りました。DreamSparkで入手できるVisualStudioPro版が前提なのですね。DreamSparkで入手した物では商用ソフト販売禁止(同人ソフトを含む)ですので、それさえ理解されていれば良いかと思います。学生でない場合はDreamSparkが利用できません。なっているので小学生・中学生が対象外です。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。別の視点から書いてみます。ゲーム作成は未経験なので、プログラミングの一般論からです。[まず前提の確認]色んな実装方法があって、効率面でも一長一短あるでしょうけど、やっくるさんの「遅い」という症状は、そんなレベルではないですよね?何百行のメソッドがあろうが、1つのクラスで管理しようとしていようが、そのこと自体が直接引き起こす性能上の問題は微々たるものだと思います。[考えられる原因]現状で遅くなっている原因については、ざっくりと2通り考えられます。1つは、何らかの単純な不具合が直接の原因であり、プログラムが煩雑であるため、やっくるさんがまだ原因を見つけることができていないという可能性。劇的に改善されるかもしれません。1つは、プログラムの構造自体が遅い原因であるという可能性。この場合は、改善は比較的手間がかかります。[解決への方針(1)]可能ならば、プログラム全体をアップロードしてみてはいかがでしょう。実際に症状が発生しているプログラムが手元にあれば、デバッグしてくれる上級者もいると思います。逆に、プログラムの断片と、やっくるさんの説明のみでは、上級者でも原因特定は困難です。(softyaさんが書いていますね。)掲示板というものの性質上、望む回答が得られない可能性は理解しておいてください。(期日までに絶対解決が必要なら、信頼できる友人や有償のサービスを探してください。)アップロードする場合は、中間ファイルを削除したり圧縮したり、ファイルサイズに気を付けましょう。方法がわからない場合は、質問すると良いでしょう。[解決への方針(2)]プログラムを公開できない場合、上級者がやってくれたかもしれないデバッグ作業をやっくるさんが自分ですることになりますが、自分でデバッグできなかったからこそ、ここで質問しているのだと思います。今のままでは不可能な方法です。デバッグの一番の敵は、先入観だと思います。自分を信用するのではなく、信頼できる手順を身に着けてください。「よくわからないけど、こう変えたら治った」というのも禁物です。学習の機会を逃しますし、より複雑になって再現することも多いです。単純だけど強力な方法を紹介します。『「不具合が発生する」という状態を保ったまま、プログラムをどんどん小さくする』です。バックアップを取って、不具合と関係ない部分のプログラムを削除していきます。BGMとか、2面以降とか、無関係と思われる部分を削除して、不具合が再現するか確認します。不具合が再現したら、さらに別の部分を削ります。再現しなくなったら、そのとき削除した部分を検討してみてください。不具合の直接の原因かもしれないし、別の個所で発生していた不具合が表面化するきっかけだったりします。考えてわからなければ一旦諦めて、プログラムの別の部分を削りましょう。この過程で不具合の原因が判明することも多いし、ある程度小さくなった段階で、公開可能になるかもしれません。[解決への方針(3)]「頭痛がするから痛み止めを飲む」のではなく、「規則正しい生活をする」という方法です。ご自分でも自覚があるようですが、今のプログラムはあまり良くありません。優秀な初心者が陥りやすい、といったら慰めになるでしょうか。楽をする方向に精進してください。この方針を選ぶ場合に限り、色々ある実装方法のどれを選ぶか、どの順番に改善していくかを考える必要があります。直接の原因に気づいたり、不具合が自ずと解決したりすることも多いです。深刻な頭痛だったら生活習慣を改める前に医者に行くように、プログラムについても、明日提出(納品)とかいう場合には、悠長なことは言っていられません。解決への方針を3案書きました。行き詰った時などに、どの方法がベストか考えてみてはどうでしょうか。Objectを大量に描画したいが...重い。アルゴリズムの二分探索をご存知ですか?はい、知っています。真ん中で区切って探索し的を絞って行く方法ですよね?ただ、プログラムの前半後半とかよくわからないので手間でもわかりやすい関数単位で調べるという方が自分向きだと思いましたので時間食いましたが調べていました。TimeStart;といった感じです。(それぞれdouble型で宣言しております)で、結果ですが、時間がかかっている処理をつきとめました。それは、オブジェクト同士の衝突判定を行う処理(関数)でした。自分はHitCheckというクラスをシングルトンで生成しておりそのHitCheckクラスにてオブジェクトlist内のオブジェクト同士の衝突判定をする関数(名をhitcaseとします)を作っています。ややこしいのですが、そのhitcase関数の中で扱っているオブジェクトlistは、オブジェクトを管理させているObjectMgrクラスが持っています。中のオブジェクトを削除したり、オブジェクトの更新をさせたりしています)そのhitcase関数をステージの更新関数内にて実行させているときにオブジェクトが増えると遅延する様です。ここで疑問があります。オブジェクトlistのサイズがただ増加すれば重くなるわけでありません。処理時間計測で調べたのですが、ObjectMgrクラスの更新関数や、描画関数でもオブジェクトlist内の更新や描画処理をさせているのでイテレータを作ってまわしておりますが、オブジェクトが増えたところで、その処理速度はまったく変わりません。目に見えて時間がかかるようになるのはオブジェクトリストを扱っているhitcase関数だけなのです。すべてを削除して、ここにはなにも無い、空っぽの状態にしています。}}}こういう状態にしても遅延が起きるのです。なにも無し}遅延がまったく無くなるのです。これは、どういうことでしょう???オブジェクトlistに入ってる数が問題ならば衝突判定処理だけで無く、オブジェクトlist更新処理なども増加に比例し、時間がかかってくるはずです。衝突判定関数以外はすべて正常時間です。衝突判定処理の内容が問題でオブジェクトが増加とともに遅延が発生するならそのhitcase関数の中でイテレータ宣言と多重for文を残していようがその中の衝突処理を削除すれば遅延は起きないはずです。オブジェクトが増えると遅延が起きます。hitcase関数をコメントアウトするか、hitcase関数内の全処理をコメントアウトすると遅延はまったく発生しません。Objectを大量に描画したいが...重い。複数の種類の敵をどうやって互いに影響し合うことなく実装するか、については簡単なサンプルコードを書いてみようと思います。気長にお待ちください。ソースコードのほうも。ありがとうございます。その辺を熟練者の方ならどのようにされるのか非常に気になりますし、学びたいです。自分の中では自分の様な形しか無いはずだと思っていますので楽しみです。待ってますのでぜひお願い致します。ひとつのリストに放り込んで回すのはふつうだと思いますよ。ありがとうございます。誰も答えて下さらなかったので助かります。自分のこの部分の方法は間違っていないのですね。Objectを大量に描画したいが...重い。5年前2重forの内側で、大体何回ぐらいループしてますか?list要素数次第では恐ろしい回数回りそうです。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。2重forの内側で、大体何回ぐらいループしてますか?list要素数次第では恐ろしい回数回りそうです。「2重forの内側で大体何回ぐらいループしているか」すみません、これはどう調べればいいでしょうか?ちなみにイテレーターの初期化はこのfor文の頭でしか行っておりません。Objectを大量に描画したいが...重い。←こんな感じで設置すればいいですか?そんな感じですが、大体の数も予想出来ていませんか?例えばリストに100個あれば100x100で10000回まわるわけですよね。>衝突判定させるって普通は使わない方法なんでしょうか?>すごく驚かれた感じですが、、、やらないことは無いですよ。恐ろしい回数行きそうなら敵と自分はリストを分けるなど工夫します。ObjectMgr::getInstance()も毎回やらないて良いかなとは思います。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。そんな感じですが、大体の数も予想出来ていませんか?調べました。list内に約60以上、オブジェクトが入ると遅延して来ます。調査ということでわざと100以上オブジェクトを突っ込んでみましたがlist内のオブジェクト数に比例してどんどん遅延します。loop数ですが、これがまたすごいスピードで増加しまして、これが処理として少ないのか多いのかわかりませんがその遅延状態にはloop数が2,3秒もしないうちに1000000以上も増加するレベルになってますね。いや、そうでなくても普段からloopの部分は相当回ってました。1フレームに二重for文全部回るわけですから。これが、二重for文の弊害なんですね。完全に、今回の遅延はこれが原因の様です。ISLe()さんも言った通りひとつのlistにすべてのオブジェクトをまとめて衝突判定させてやる方法はゲームプログラムにおいて別に特殊でもなんでも無いと思うんです。ひとつのlistで管理するならば抽出させる時に二重for文を利用するのは避けられないはずです。自分のプログラム文のミスでも無く、60以上ものオブジェクトを画面内に出現させる様なゲームで、すべてのオブジェクトをひとつのlistに入れる方法を取った事が問題、というのはちょっと現代の言語処理速度にガッカリな感じです。Objectを大量に描画したいが...重い。