1やっくるObjectを大量に描画したいが...重い。efault.jpgすぐに画面のfpsが遅延状態になってしまいます。画面内に入ったらインスタンス化する様にしてなるべくギリギリまで生成されない様にしています。その障害物のサイズも8×8と小さいです。画面内に15個〜20個作られた時点で画面が相当重くなってしまうのです。雑魚敵と同じクラスで作っています。大量のif文で実行処理を分けています。座標とHPだけを持ち、HPがゼロになったら消えるって処理だけの非常にシンプルな内容のクラスを雑魚敵用のクラスとは別で作り、インスタンス化する方が良いのでしょうか?また、雑魚敵のクラスといっても自分は癖で何種類もの雑魚敵をそのひとつのクラスで回しています。動きなどを、処理の中で細分化させてすべての雑魚敵がそのクラスでインスタンス化するだけで動く様に記載してしまっています。得る方法がわかりませんので、こちらで質問させて頂きました。昔pc-98でファーストクイーンとゲームがありました。ここの回答者サマたちならご存知かと思います。ss03-2.jpgこんなのを将来作ってみたいとも思っていますので今回の質問は重要かと考えます。Objectを大量に描画したいが...重い。5年前さすがにオブジェクトの20個や30個で、fpsがガタ落ちするようなことは普通ではありません。プログラムにもよりますが、負荷が少なめのオブジェクトであれば、1000個~2000個は軽く処理できるはずです。描画処理のちょっとした知識と工夫がないと若干重くなりますが、それでも100枚程度までなら問題ありません。何か無駄な処理を繰り返してしまっているのではないでしょうか?例えば、初回だけ実行すれば済む比較的重い処理を、毎フレーム実行してしまっている、とか。Objectを大量に描画したいが...重い。5年前たぶん、どこかで間違っています。実証したいのなら、超簡単なプログラムで画面内に15個〜20個表示してみてください。それで問題ないのなら、ロードが無駄に発生している、画面内に15個〜20個つもりが数千個表示している、どこかで過剰な負荷のかかる処理をしているのいずれかです。自分のプログラムが間違っている発想でデバッグしないとデバッグできるものもできなくなりますよ。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。皆さんが色々な意見を投稿しておられますが、僕は処理に関する気になる所を攻めてみます。すべての敵・障害物で同じクラスを使っている件について。これはいろいろとまずいです。比較で処理が遅くなってしまったり、あるいはコードが読みにくくなってしまったり。これはポリモーフィズムを用いて、同じような機能を持ちながら別の処理を行なえるような処理にするべきです。これを用いれば少なくとも障害物と敵との差別化は図れるはずです。あとは画像の違いなど、軽い変更なら汎用化して外部データ化するのもありです。これでファイル数の増加も抑えることができます。どっちの方が見やすく、修正しやすいかは現状のコードと、分けて書いたときのコードを想像すれば一目瞭然のはずです。etc...次に、インスタンスの管理方法です。これはコードがないのではっきりとしたことが言えないのですが、もしC++でstd::vectorを使って管理している場合、eraseの時の処理で時間がかかっている可能性が高いです。この場合、挿入と削除に強いstd::listを使う事を推奨します。こちらの場合基本的に添字ではなくイテレータを用いてアクセスすることになるので注意してください。etc...あとはソフト屋さん・せとさんが言うような、処理のミスを地道に探していくことが大切です。デバッグしてみれば自分が思わないような処理をしていることが多々あるので、ゆっくりたどっていくことが大切になります。Objectを大量に描画したいが...重い。5年前いまどきの弾幕シューティングだと同時に4000くらいのオブジェクトでも少ないほうだと思います。投稿に書かれている内容についてわたしなりの回答をします。以下はより高速にするための提案になります。質問者さんのプログラムが重い原因は別にあるはずです。それはコードを晒してもらわないことには分かりません。FCのBGと同様に背景の描画はタイルマップを採用したほうが良いと思います。破壊できる障害物については個別にインスタンスを作るのではなく、タイルマップを直接(あるいは内部に確保した状態マップを)チェックして『ある状態からある状態に変化させる』処理を対応させると良いでしょう。すれば描画はタイルマップというひとつのオブジェクトで一括して行え、対応する処理は障害物の種類(且つ状態変化のあるものだけ)分で済みます。スクロールに応じてタイルマップの画面に入ってくる端の分を更新していきます。同時に障害物と状態変化処理の対応表も(必要であれば)更新していきます。ゲームプログラムでコンテンツとしてのキャラの種類に応じてクラスを継承するようなことはむしろ非推奨なので、その辺は安心してください。コンテンツとしてのキャラの種類は、動きを定義したデータを再生する処理(いわゆるスクリプト)を組んだりして実装します。何種類ものキャラの動きを直にコーディングしてifやswitchで分岐するようなものではありません。どんなキャラにでもなれるクラスであって、いくつものキャラをまとめたクラスではありません。#どんなキャラにでもなれるクラスとして、機能を継承するといったことはよくあります。Objectを大量に描画したいが...重い。オブジェクトの20個や30個で、fpsがガタ落ちするようなことは普通ではありません。1000個~2000個は軽く処理できるはずです。何か無駄な処理を繰り返してしまっているのではないでしょうか?例えば、初回だけ実行すれば済む比較的重い処理を、毎フレーム実行してしまっている、とか。1000個~2000個は軽く、、ですか、良いですね、素晴らしい。今回の問題が自分のせいだとわかり、安心しました。1000個~2000個は軽く処理出来るところを20個やそこらでガタ落ちさせる処理に気付けない自分ってかなり致命的ですね。初回だけ実行すれば済む処理を毎フレーム処理している更新関数内には入れてないつもりなんですけど、、でも今回のことでもう一度しっかり確認したいと思います。どこかで間違っています。実証したいのなら、超簡単なプログラムで画面内に15個〜20個表示してみてください。それで問題ないのなら、ロードが無駄に発生している、画面内に15個〜20個つもりが数千個表示している、どこかで過剰な負荷のかかる処理をしているのいずれかです。一応その辺は守っているつもりです。自分はまだまだ知識が浅いので、そういうミスをたまに犯している場合もあります。発生処理については色々と確認しておりますので今回に限っては、この辺も大丈夫なはずです。ソフト屋さんのご指摘で私が自信の持てない項目は過剰な負荷のかかる処理ですね。これは、先のせとさんのご指摘と同じかと思います。何か無駄な処理を繰り返してしまっているのかもしれません。その雑魚敵用のクラスで作ったオブジェクトを画面内に増やせば、すぐに画面が遅延するのでとても怪しいです。思えば、アイテム類を構成する別のクラスで作ったオブジェクトは画面内に20個いくつ作ろうが、画面は遅延しませんでしたし。雑魚クラスの更新関数が怪しくなって来ましたので確認したいと思います。さん、ソフト屋さん、ありがとうございます。Objectを大量に描画したいが...重い。C++でstd::vectorを使って管理している場合、eraseの時の処理で時間がかかっている可能性が高いです。この場合、挿入と削除に強いstd::listを使う事を推奨します。要素の追加や削除が頻繁に行われるものはlistで、と勉強しましたので、ゲーム中に消去される様なオブジェクトはすべてlistで管理しております。これはポリモーフィズムを用いて、同じような機能を持ちながら別の処理を行なえるような処理にするべきです。実はこの辺が自分は弱いです。毎回move関数をどっかから繋げてインスタンス化させるというのがありました。うろ覚えですが、確か、別のところに様々な動きの処理の関数が用意されていてそれを各雑魚のmove関数にポリモフィズムで繋げて、その雑魚の更新中はその処理をさせる、みたいな感じでした。その時は自分が初歩の初歩でしたのでいまいち理解していませんでしたが自分はそれを理解しなければならないところまで進んだようですね。要は、今の私の処理では、ひとりひとりが処理を持ち動いているわけですが、ポリモフィズムをすることにより、ひとつの処理をみんなで使っているといった感じでしょうか。残念ながらポリモフィズム、すなわち多態性を利用した敵の生成を解説しているサイトなんて、見当たりません。その本をもう一度探してみることにします。FCのBGと同様に背景の描画はタイルマップを採用したほうが良いと思います。はい、現在自分のシューティングの背景はタイルマップを採用しております。それこそステージ開始時に描画タイル座標と描画タイル画像Noを持つ構造体でvectorに詰めて描画しております。確かに、そこにflgでも加え、背景が壊れる前、背景が壊れた後、で描画する画像を設定する、のは良いかもしれません。背景vectorと動いてるオブジェクトたちとの衝突判定関数ではぶつかると移動停止(押される等)の処理をやっているのですが、そこにオブジェクト同士の判定と同じ様な判定内容も作る必要性が出て来ますからなんだか、ややこしくなりそうで怖いです。オブジェクトがタイルマップの上下左右それぞれのどの面に当たっただのの判定関数と、オブジェクト同士の矩形領域の重なり判定とは別の箇所で処理しています。なんだか、グラディウスでいうところの生き物みたいな障害物はオブジェクト同士の矩形領域の重なり判定の方でやりたくなるんですがナンセンスなんでしょうか?また、たまたま今回はマップのタイルサイズと障害物のサイズが同じなので問題無いですが、障害物のサイズがタイルより小さい場合タイル構造体がその障害物の座標なりサイズなり別で持つようにしなければならずさらにややこしくなりそうな気がします。判定関数を二種類作る、は正解なのでしょうか?ISLe()さんなら、そこはキャラ同士でも上下左右の面との判定してやればひとつの判定関数で済むじゃん、なんでしょうか?とりあえず、まずはクラス内で無駄な処理をしている可能性が大なのでそこを確認してみますがISLe()さんの言う、「より高速にするための提案」は今後のために勉強すべきだとは思っています。Objectを大量に描画したいが...重い。本当に問題ないのか、グローバル変数で良いので初期化と描画にカウント処理を埋め込んでみてください。そのカウントを1フレームの最初でクリア、フレームの終わりでDrawFormatStringなどで描画します。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。5年前それと処理の時間計測をされていない様なので、まとまった単位で時間計測を行ってください。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。Objectを大量に描画したいが...重い。グローバル変数で良いので初期化と描画にカウント処理を埋め込んでみてください。そのカウントを1フレームの最初でクリア、フレームの終わりでDrawFormatStringなどで描画します。「そのカウントを初期化と描画に埋め込む。1フレームの最初でクリア、フレームの終わりで描画」についてもう少し詳しくお願いします。count)}ってことでしょうか?だとすれば自分は頭が悪く、これで一体なにを調べられるのか検討がつきません。Objectを大量に描画したいが...重い。){この直後にcount=0;ですね。上のwhileのとじカッコ}の直前に入れます。InitializeとDrawは別カウント変数です。