タグ付けされた質問 「c++」

私はタイルベースではない2Dストリートファイターのようなゲームを作っています。通常、人々はエンティティをレンダリングするレンダラーに与えることを推奨しますが、それ自体をレンダリングするのではなく、逆の方が良いようです、 なぜ一方が他方より優れているのですか？ ありがとう

16 c++  rendering 

私はしばらくの間2D RPGに取り組んでいますが、デザインに関するいくつかの悪い決定を下したことに気付きました。特に問題を引き起こしているものがいくつかあるので、他の人がそれらを克服するためにどのようなデザインを使用したのか、または使用するのだろうかと思っていました。 少し背景を説明するために、私は去年の夏休みに仕事を始めました。最初はC＃でゲームを作成していましたが、約3か月前にC ++に切り替えることにしました。C ++を頻繁に使用してからしばらく経っていたので、C ++の適切なハンドルを取得したかったので、このような興味深いプロジェクトが良い動機付けになると考えました。ブーストライブラリを広く使用しており、グラフィックスにはSFMLを、オーディオにはFMODを使用しています。 かなりの量のコードが書かれていますが、それを廃棄して最初からやり直すことを検討しています。 ここに私が持っている主要な関心分野があり、他の人がそれらを解決したり、解決したりする適切な方法について意見を聞きたいと思いました。 1.循環的な依存関係 C＃でゲームを実行していたとき、C＃での問題ではないので、これについて実際に心配する必要はありませんでした。C ++に移行すると、これはかなり大きな問題になり、間違って設計したのではないかと思うようになりました。クラスを分離する方法を想像することはできませんが、それでもクラスに自分のしたいことをさせることができます。依存関係チェーンの例をいくつか示します。 ステータス効果クラスがあります。このクラスには、キャラクターに効果を適用するためのいくつかのメソッド（Apply / Unapply、Tickなど）があります。例えば、 virtual void TickCharacter(Character::BaseCharacter* character, Battles::BattleField *field, int ticks = 1); この関数は、ステータス効果を与えられたキャラクターがターンするたびに呼び出されます。Regen、Poisonなどのエフェクトを実装するために使用されます。ただし、BaseCharacterクラスとBattleFieldクラスへの依存関係も導入します。当然、BaseCharacterクラスは、現在どのステータスエフェクトがアクティブになっているかを追跡する必要があるため、循環依存関係になります。バトルフィールドは戦闘パーティーを追跡する必要があり、パーティークラスには別の循環依存関係を導入するBaseCharactersのリストがあります。 2-イベント C＃では、キャラクター、バトルフィールドなどのイベントにフックするためにデリゲートを広範囲に使用しました（たとえば、キャラクターのヘルスが変化したとき、ステータスが変更されたとき、ステータスエフェクトが追加/削除されたときなどにデリゲートがありました。）そして、戦場/グラフィックコンポーネントがそれらのデリゲートにフックして、その効果を強化します。C ++では、似たようなことをしました。明らかに、C＃デリゲートに直接相当するものはないため、代わりに次のようなものを作成しました。 typedef boost::function<void(BaseCharacter*, int oldvalue, int newvalue)> StatChangeFunction; そして私のキャラクタークラスで std::map<std::string, StatChangeFunction> StatChangeEventHandlers; キャラクターのステータスが変更されるたびに、マップ上のすべてのStatChangeFunctionを繰り返し呼び出します。動作しますが、これは物事を行うための悪いアプローチであることが心配です。 3-グラフィックス これは大きなことです。これは私が使用しているグラフィックスライブラリとは関係ありませんが、概念的なものです。C＃では、グラフィックスを、ひどいアイデアだとわかっている多くのクラスと結合しました。今回はそれを分離したいので、別のアプローチを試みました。 グラフィックを実装するために、ゲームに関連するすべてのグラフィックを一連の画面として想像していました。つまり、タイトル画面、キャラクターステータス画面、マップ画面、インベントリ画面、バトル画面、バトルGUI画面があり、基本的にこれらの画面を必要に応じて積み重ねてゲームグラフィックを作成することができます。アクティブな画面が何であれ、ゲーム入力を所有します。 ユーザー入力に基づいて画面をプッシュおよびポップする画面マネージャーを設計しました。 たとえば、マップ画面（タイルマップの入力ハンドラー/ビジュアライザー）で起動ボタンを押した場合、スクリーンマネージャーへの呼び出しを発行して、メイン画面をマップ画面上に押してマップをマークします。描画/更新されない画面。プレーヤーはメニューをナビゲートし、必要に応じてより多くのコマンドをスクリーンマネージャーに発行して、新しいスクリーンをスクリーンスタックにプッシュし、ユーザーがスクリーンを変更/キャンセルするとそれらをポップします。最後に、プレーヤーがメインメニューを終了したら、ポップメニューからポップしてマップ画面に戻り、描画/更新するようにコメントして、そこから移動します。 バトル画面はより複雑になります。背景として機能する画面、戦闘の各パーティを視覚化する画面、および戦闘のUIを視覚化する画面があります。UIはキャラクターイベントにフックし、それらを使用してUIコンポーネントをいつ更新/再描画するかを決定します。最後に、使用可能なアニメーションスクリプトを使用するすべての攻撃は、画面スタックからポップする前に、追加のレイヤーを呼び出して自身をアニメーション化します。この場合、すべてのレイヤーが一貫して描画可能で更新可能としてマークされ、バトルグラフィックスを処理する画面のスタックを取得します。 私はまだスクリーンマネージャを完全に動作させることができていませんが、しばらくはできると思います。それについての私の質問は、これは価値のあるアプローチですか？悪いデザインの場合、必要なすべての画面を作成するのに多くの時間を費やす前に、今すぐ知りたいと思います。ゲームのグラフィックをどのように構築しますか？

16 c++  architecture  rpg 

私はシューティングゲーム（1942、クラシック2Dグラフィックスなど）を書いていますが、コンポーネントベースのアプローチを使用したいと思います。これまでのところ、次の設計について考えました。 各ゲーム要素（飛行船、発射物、パワーアップ、敵）はエンティティです 各エンティティは、実行時に追加または削除できるコンポーネントのセットです。例には、Position、Sprite、Health、IA、Damage、BoundingBoxなどがあります。 飛行船、発射物、敵、パワーアップはゲームクラスではないという考え方です。エンティティは、所有するコンポーネントによってのみ定義されます（時間の経過とともに変化する可能性があります）。そのため、プレイヤーの飛行船は、スプライト、位置、ヘルス、および入力コンポーネントから始まります。パワーアップには、Sprite、Position、BoundingBoxがあります。等々。 メインループは、ゲームの「物理」、つまりコンポーネントの相互作用を管理します。 foreach(entity (let it be entity1) with a Damage component) foreach(entity (let it be entity2) with a Health component) if(the entity1.BoundingBox collides with entity2.BoundingBox) { entity2.Health.decrease(entity1.Damage.amount()); } foreach(entity with a IA component) entity.IA.update(); foreach(entity with a Sprite component) draw(entity.Sprite.surface()); ... コンポーネントは、メインC ++アプリケーションにハードコーディングされています。エンティティはXMLファイル（luaまたはpythonファイルのIAパーツ）で定義できます。 メインループはエンティティをあまり気にしません。コンポーネントを管理するだけです。ソフトウェア設計では、次のことを許可する必要があります。 コンポーネントを指定して、それが属するエンティティを取得します エンティティを指定すると、タイプ「type」のコンポーネントを取得します すべてのエンティティについて、何かをする …

16 c++  design-patterns  component-based 

そのため、FSMを使用してゲームの状態管理を行うこと、FSMとは何か、1つを構築するためにスタックまたは状態のセットを使用することについて多くのことを読みました。私はすべてを経験しました。しかし、私はそのためにFSMの実際の適切に設計された実装を書くことにこだわっています。具体的には、どのようにして状態間を移行する問題をどのようにきれいに解決するのか、（どのように）状態が他の状態からのデータを使用できるようにするのか、などです。C ++で実装を設計および作成するためのヒントや、さらに良いコード例はありますか？

16 c++  architecture  software-engineering  game-loop  state 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 OpenGL 3とC ++（およびウィンドウ管理用のglfw）を使用してゲームエンジンを開発しています。私はこれまでに進めてきましたが、サウンドエンティティと最適化以外のほとんどのことは完了しています。エンジンは遅延シェーディングを使用しているため、遅延シェーディング自体は平均的なGPUにとって疲れるプロセスなので、レンダリングプロセスを可能な限り最適化したいと思います。 現在のシステムは、レンダラーと現在のワールドを含むシーンで構成され、ワー​​ルドはエンティティとライティングエンティティを別々に保持しstd::vectorsます。 そのため、基本的にSceneが呼び出されるたびに->render()、Rendererを呼び出し、ワールドをパラメーターとして渡し、ワールドからエンティティイテレーターを取得し、FBOにそれらを描画してから、2番目のパスのライティングエンティティを通過します。そして、これは十分ではないと思います。 現在のアルゴリズムは、エンティティが画面スペースにない場合でもすべてを繰り返し処理します。現在のレンダリングアルゴリズムを最適化して、可視オブジェクトに対してのみAPI関数を呼び出す方法を考えています。そのようなレンダラーを最適化する一般的な手法は何ですか？

16 opengl  c++  optimization  deferred-rendering 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Game Development Stack Exchangeで話題になるようにします。 4年前に閉鎖されました。 算術関数が次のように見えるいくつかのベクトルクラスがあります。 template<typename T, typename U> auto operator*(const Vector3<T>& lhs, const Vector3<U>& rhs) { return Vector3<decltype(lhs.x*rhs.x)>( lhs.x + rhs.x, lhs.y + rhs.y, lhs.z + rhs.z ); } template<typename T, typename U> Vector3<T>& operator*=(Vector3<T>& lhs, const Vector3<U>& rhs) { lhs.x *= rhs.x; lhs.y *= …

15 c++  mathematics  performance  refactoring 

CPUキャッシュを賢く使用するための優れたアーキテクチャであるECSゲームエンジンのドキュメントをよく読みます。 しかし、CPUキャッシュの利点を理解することはできません。 コンポーネントが連続したメモリの配列（またはプール）に保存されている場合、コンポーネントを順番に読み取る場合にのみCPUキャッシュを使用するのが良い方法です。 システムを使用する場合、特定のタイプのコンポーネントを持つエンティティのリストであるエンティティリストが必要です。 ただし、これらのリストは、順番ではなくランダムな方法でコンポーネントを提供します。 それでは、キャッシュヒットを最大化するECSを設計する方法は？ 編集： たとえば、物理システムには、RigidBodyおよびTransformコンポーネントを持つエンティティのエンティティリストが必要です（RigidBodyのプールとTransformコンポーネントのプールがあります）。 したがって、エンティティを更新するためのループは次のようになります。 for (Entity eid in entitiesList) { // Get rigid body component RigidBody *rigidBody = entityManager.getComponentFromEntity<RigidBody>(eid); // Get transform component Transform *transform = entityManager.getComponentFromEntity<Transform>(eid); // Do something with rigid body and transform component } 問題は、entity1のRigidBodyコンポーネントがそのプールのインデックス2にあり、entity1のTranformコンポーネントがそのプールのインデックス0にあることです（一部のエンティティは他のコンポーネントを持たず、エンティティを追加/削除するため/ランダムにコンポーネント）。 コンポーネントがメモリ内で連続している場合でも、それらはランダムに読み取られるため、キャッシュミスが多くなります。 ループ内の次のコンポーネントをプリフェッチする方法がない限り？

15 c++  architecture  entity-system  memory-efficiency  entity-component 

スターフィールドを手続き的に生成するコードを知っている人はいますか？ 理想的には、物理​​学に基づいて、現実的な惑星と月を手に入れることができます。最良の方法は、C ++、オープンソース、およびOgre3dで動作することです。 利用できるものがなければ、大学の論文から何かをコーディングすることを恐れません。

15 c++  ogre  procedural-generation 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Game Development Stack Exchangeで話題になるようにします。 11か月前に閉鎖されました。 私は多くのロギングライブラリを知っていますが、それらの多くをテストしませんでした。（GoogleLog、Pantheios、来るべきboost :: logライブラリ...） ゲーム、特にリモートマルチプレイヤーゲームやマルチスレッドゲームでは、最後にすべてのログを削除しても、ログはデバッグに不可欠です。 ログ（マルチプレイヤーおよびマルチスレッドおよび/またはマルチプロセス）を必要とするPCゲーム（コンソールではない）を作成していて、ロギング用のライブラリを探す十分な理由があるとしましょう（時間がない、または私の場合、正しく書く能力に自信がありません）。 私が必要だと仮定すると： 性能 使いやすさ（ストリーミングやフォーマットなどが可能） 信頼できる（漏れたりクラッシュしたりしないでください！） クロスプラットフォーム（少なくともWindows、MacOSX、Linux / Ubuntu） Wichロギングライブラリを使用することをお勧めしますか？ 現在、私はそのブースト::ログは最も柔軟なもの（！あなたも、リモートでにログインすることができます）だと思います、ではなく良好なパフォーマンスを持っているアップデートは、高パフォーマンスのためであるが、まだリリースされていません。Pantheiosはよく引用されますが、パフォーマンスと使用法の比較ポイントはありません。私は長い間自分のライブラリを使ってきましたが、マルチスレッドを管理していないので、十分に高速であっても大きな問題です。Google Logは興味深いようです。ただテストする必要がありますが、これらのライブラリなどをすでに比較している場合は、アドバイスが役に立つかもしれません。 ゲームは多くの場合、パフォーマンスが要求されますが、デバッグが複雑であるため、特定のケースでは明確な利点があるロギングライブラリを知っておくと便利です。

15 c++  software-engineering  performance 

実行時にプログラムで使用されているビデオカードメモリの量をプログラムで判断したい。具体的には、OpenGLを使用してWindowsマシンでそれを行う方法について疑問に思っていますが、他のプラットフォームでも同様に行う方法に興味があります。 プログラムの実行中にメモリ使用量を表示するユーティリティがあることは知っていますが、コードからその情報を照会できるようにしたいと考えています。

15 opengl  c++  windows  c 

Visual C ++ 2015とOpenGLでいくつかのゲームを作成しました。自分のマシンで実行しても問題はありませんでしたが、他のマシンで実行すると、いくつかのDLLが欠落していることがわかります。ファイルが見つからないという問題を回避できるように、次回はそれが発生しないことを確認する方法と、どのようなことを考慮する必要があるのか​​を知りたいですか？

15 c++  visual-studio 

Digesting Duckに示されているファネルアルゴリズムを使用して、ファネルの検出がどのように機能するかわかりません。 誰かが私に方法を明確に説明するか、ファンネルを検出する別の方法を提案できますか？

14 c++  algorithm  path-finding 

私は、部分的に惑星探査で構成されるゲームを設計しています。疑似ランダム生成を使用して、すべての詳細を保存するのではなく、ロードする必要があるときに定義済みのシードから再生成します。これは重すぎます。そのため、プレイヤーが行ったランダムシードと変更をファイルに保存します。 プレイヤーは、軌道から惑星を見ることができる必要があります（非常に低いレベルの詳細で、その後地面に降り、着陸している地域の詳細レベルをゆっくりと上げ、反対側にあるものを降ろします）プレイヤーの視界の外に出る惑星の 平面の地面でそれをしなければならなかった場合、正方形のチャンクシステムで簡単にできます。しかし、ここでの問題は、惑星が-ほとんど-球体であるということです。 それでは、正確なポイントの周りに地面の詳細（レリーフおよび接地されたオブジェクト）をロードする最良の方法は何でしょうか？ 私はすでに2つの解決策に取り組んでいますが、どちらにも弱点があります： 1.球体を正方形の塊に切断します。 プレーヤーが地面に十分に近づいたら、彼/彼女の位置から最も近い正方形の詳細を改善する必要があります。 十分でない場合でも、プレイヤーが地面にいるときや地面に本当に近づいているときに読み込むために、各正方形をサブ正方形にカットできます。 しかし、写真でわかるように、プレイヤーがポールに着地しようとすると問題があります：正方形は非常に細い長方形になり、最後の行では三角形になり、さらに多くの読み込みが必要になるという事実に加えて、世代が歪んで表示されます。 2.二十面体から始めます。 ここでは、プレイヤーが近づいているときに、プレイヤーの位置の周りの三角形のテッセレーションを増やすことができます。 しかし、私はプレイヤーの位置よりも近くに三角形を見つける方法を知りません。その場合、デカルト座標が役立つ可能性があると聞きましたが、使用方法はわかりません。 私はそのためにC ++ / OpenGLを使用しているので、ここで生成およびロードする主なものは、表面のレリーフと色/テクスチャを表す頂点です。

14 opengl  c++  procedural-generation  optimization  sphere 

OpenGL 3.3およびGLSLバージョン330で動作するスカイボックスを取得しようとしています。 ウェブ上のどこにも完全に最新のOGLスカイボックスチュートリアルが見つからなかったため、古いものを最新化しました（頂点などのglVertexAttribPointer()代わりに使用gl_Vertex）。それはほとんど動作していますが、2つの主要な詳細： スカイボックスは空の三角形に似ており、テクスチャはひどくゆがんで伸びています（それらはスターフィールドであると想定されていますが、黒の背景に線が描かれています）。これは、古いチュートリアルを完全に正しく移植しなかったためだと99％確信しています。 これが私のスカイボックスクラスです。 static ShaderProgram* cubeMapShader = nullptr; static const GLfloat vertices[] = { 1.0f, -1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f, -1.0f, -1.0f, -1.0f, 1.0f, -1.0f, -1.0f, -1.0f, -1.0f, 1.0f, -1.0f, -1.0f, 1.0f, 1.0f, -1.0f, 1.0f, -1.0f, 1.0f, 1.0f, -1.0f, 1.0f, 1.0f, 1.0f, -1.0f, 1.0f, 1.0f, -1.0f, …

14 c++  opengl  glsl  cubemap  skybox 

この質問が初めての場合は、以下の更新前の部分を最初に読んでから、この部分を読むことをお勧めします。 ただし、問題の統合は次のとおりです。 基本的に、衝突の順序と衝突グループが重要なグリッド空間分割システムを備えた衝突検出および解決エンジンがあります。一度に1つのボディを移動し、衝突を検出してから衝突を解決する必要があります。すべてのボディを一度に移動し、可能な衝突ペアを生成すると、明らかに高速になりますが、衝突の順序が尊重されないため、解像度が壊れます。一度に1つのボディを動かすと、ボディに衝突をチェックさせなければならず、^ 2の問題になります。グループをミックスに入れると、多くのボディで非常に速く非常に遅くなる理由を想像できます。 更新：私はこれに本当に一生懸命取り組みましたが、何も最適化することができませんでした。 Willによって記述された「ペインティング」の実装に成功し、グループをビットセットに変更しましたが、非常に小さなスピードアップです。 また、大きな問題を発見しました。私のエンジンは衝突順序に依存しています。 私はユニークな衝突ペア生成の実装を試みました。これは間違いなくすべてを高速化しますが、衝突の順序を破りました。 説明させてください： 私の元の設計（ペアを生成しない）で、これが起こります： 単一の体が動く 移動した後、セルを更新し、衝突したボディを取得します それが解決する必要があるボディとオーバーラップする場合、衝突を解決する つまり、ボディが移動して壁（または他のボディ）にぶつかった場合、移動したボディのみが衝突を解決し、他のボディは影響を受けません。 これが私が望む行動です。 物理エンジンでは一般的ではないことを理解していますが、レトロスタイルのゲームでは多くの利点があります。 通常のグリッド設計（一意のペアを生成）では、これが起こります： すべての体が動く すべてのボディが移動した後、すべてのセルを更新します 一意の衝突ペアを生成する 各ペアについて、衝突の検出と解決を処理します この場合、同時移動により2つのボディがオーバーラップする可能性があり、それらは同時に解決します。これにより、ボディは事実上「互いに押し合い」、複数のボディとの衝突安定性が損なわれます。 この動作は物理エンジンでは一般的ですが、私の場合は受け入れられません。 また、別の問題も発見しました。これは重大です（実際の状況では起こりそうにない場合でも）。 グループA、B、Wのボディを検討する AはWとAに衝突して解決します BはWとBに対して衝突して解決します AはBに対して何もしません BはAに対して何もしません 多くのAボディとBボディが同じセルを占有する場合があります-その場合、ボディ間で不必要な反復が多く、相互に反応してはなりません（または衝突を検出するだけで解決しない） 。 同じセルを占める100体の場合、100 ^ 100回の反復です！これは、一意のペアが生成されていないために発生しますが、一意のペアを生成できません。そうしないと、望ましくない動作が発生します。 この種の衝突エンジンを最適化する方法はありますか？ これらは尊重されなければならないガイドラインです： 衝突の順序は非常に重要です！ ボディは一度に1つずつ移動し、次に衝突を1つずつ確認し、移動後に1つずつ解決する必要があります。 ボディには3つのグループビットセットが必要です グループ：ボディが属するグループ GroupsToCheck：ボディが衝突を検出する必要があるグループ GroupsNoResolve：ボディが衝突を解決してはならないグループ 衝突を検出するだけで解決しない場合があります 事前更新： はじめに：このボトルネックを最適化する必要はないことを認識しています-エンジンは既に非常に高速です。しかし、楽しくて教育的な目的で、エンジンをさらに高速にする方法を見つけたいと思っています。 柔軟性と速度に重点を置いて、汎用C ++ 2D衝突検出/応答エンジンを作成しています。 そのアーキテクチャの非常に基本的な図を次に示します。 基本的には、メインクラスWorld所有している、の（メモリ管理）ResolverBase*、SpatialBase*およびvector<Body*>。 …

14 c++  collision-detection  performance  optimization  grid