タグ付けされた質問 「performance」

OpenGLバージョン3以降では、クライアント側レンダリングの使用が不要になりました。即時モードは廃止され、頂点配列は非推奨のようです。代わりに、私が正しく理解していれば、VBOは頂点をレンダリングする主な方法です。 すべてを均一にレンダリングする方法の背後にあるロジックを見ていますが、VBOには頂点配列に大きなマイナス面がないのですか？一般に、VBOは1 MBを超えるデータを含む大きなバッファーであると考えられていました。小さいジオメトリがたくさんあるシーンがある場合はどうなりますか？多数のノードを持つシーングラフがあり、各ノードには独自の変換などが必要です。各ノードは個別に削除したり、個別に追加したりすることもできます。以前は頂点配列を使用していました。したがって、最初の質問は、VBOに切り替えた場合、各オブジェクトにVBOを割り当てる必要があるため、シーングラフオブジェクトのオーバーヘッドが大きくなるかどうかです。 もう1つの懸念は、レンダリングするジオメトリが非常に動的になる可能性があることです。最悪の場合、すべてのジオメトリを一定期間フレームごとに再送する必要がある場合があります。この使用例では、VBOのパフォーマンスは頂点配列よりも劣りますか、それともVBOは頂点アレイと同じくらい機能しますが、それ以上は機能しませんか？ したがって、より簡潔な形式で、私の質問は次のとおりです。 1）VBOの割り当て/割り当て解除にかなりのオーバーヘッドがありますか（つまり、バッファーをセットアップするだけの行為です）。 2）フレームごとにCPUからデータを更新する場合、これは頂点配列を使用した場合よりも大幅に悪化する可能性がありますか？ そして最後に、私は知りたい： 3）上記の質問のいずれかに対する答えが「はい」の場合、なぜVBOよりも有利なレンダリングの他のモードを非推奨にするのですか？これらの潜在的な割り当てコストなどを軽減するために使用するはずのテクニックなど、ここに欠けているものはありますか？ 4）これらの質問への回答は、使用しているOpenGLバージョンによって大幅に変わりますか？パフォーマンスの高い方法でVBOを使用してコードをOpenGL 3または4の上位互換にリファクタリングすると、同じ手法がOpenGL 2でうまく機能する可能性が高いか、特定の手法がOpenGL 3ではるかに高速になる可能性があります+およびOpenGL 2を使用する他のユーザー スタックオーバーフローについてこの質問をしましたが、このサイトが私の質問に適している可能性があることに気付いたので、ここに再投稿しています。

21 opengl  performance  vbo 

前の質問で書かれたすべてを読みました。ダブルバッファリングで理解していることから、プログラムは、完成した図面がコピーまたはスワップされるまで待ってから次の図面を開始する必要があります。トリプルバッファリングでは、プログラムに2つのバックバッファがあり、そのようなコピーに関係しないものですぐに描画を開始できます。 ただし、3番目のバッファを利用できる状況にある場合、トリプルバッファリングでは、モニタが更新できるよりも速くフレームを描画していることを示唆しません。そのため、実際にはより高いフレームレートは得られません。それでは、トリプルバッファリングの利点は何ですか？

20 opengl  performance  double-buffering 

私のゲームループがシステムの許す限り高速で実行されたときに、害が生じる可能性があるかどうか疑問に思っていましたか？ 現在、ナノ秒単位で経過時間を測定することで、問題なく事前定義された速度でゲームロジックとレンダリングロジックを実行するループがあります。実際、私がループ内で行うロジックは、毎秒一定量の呼び出しに合わせてクロックされます。 ループ自体は、私のマシンでは1秒間に約1,170万のループに達するのと同じくらい高速で実行されます。 ループ（単純な擬似コード）： while(!isGameOver){ if(canPollInputs){ pollInputs() } while(canStepLogic){ stepLogic() } if(canRender){ render() } } 私の質問は、基本的に、その単純なループが、制御された速度で実行されていない場合、システムに害を及ぼすことができるかどうかです。 編集：つまり、ロジックは1秒に30回（30 tps）で実行され、レンダラーは60 fpsで実行され、入力を1秒に100回ポーリングしています。 。ただし、ループ自体は調整されません。 編集：Thread.sleep()たとえば、メインループを1秒あたり250ループまでスロットルすると、削減につながりますが、ループは目的の250ではなく、1秒あたり約570ループで実行されます（デスクトップマシンにいるときにコードを追加します。） 編集：ここで、物事を明確にするために動作するJavaゲームループに行きます。また、自由に使用できますが、あなたのものではありません;） private void gameLoop() { // Time that must elapse before a new run double timePerPoll = 1000000000l / targetPPS; double timePerTick = 1000000000l / targetTPS; double timePerFrame = …

19 java  game-design  performance  game-loop 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Game Development Stack Exchangeで話題になるようにします。 閉じた3年前。 すべてのプログラミング言語には、他よりも推奨されるオペコードのセットがあります。ここでそれらを速度の順にリストしようとしました。 ビット単位 整数の加算/減算 整数の乗算/除算 比較 制御フロー フロートの加算/減算 フロート乗算/除算 高性能コードが必要な場合は、C ++をアセンブリで手作業で最適化して、SIMD命令またはより効率的な制御フロー、データ型などを使用できます。したがって、データ型（int32 / float32 / float64）または使用される動作（*、+、&）、CPUレベルの性能に影響を与えます。 CPUでの単一の乗算は加算よりも遅いですか？ MCU理論では、オペコードの速度は実行にかかるCPUサイクルの数によって決定されることを学びます。では、乗算に4サイクルかかり、加算に2サイクルかかるということですか？ 基本的な数学および制御フローのオペコードの速度特性は正確に何ですか？ 2つのオペコードの実行に同じサイクル数が必要な場合、両方のパフォーマンスコードはパフォーマンスの向上/損失なしで互換的に使用できますか？ x86 CPUのパフォーマンスに関して共有できるその他の技術的な詳細は歓迎します

19 c++  performance  optimization 

私はとの主な違いを理解texelFetchしてtexture、その詳細についていくつか質問があります： んtexelFetchパフォーマンスの低下が関与？キャッシュなどを使用しないなど？ 使用時に互換性がtexelFetchありますか？textureGL_NEAREST

18 opengl  textures  performance 

私はObjective-CとC ++でのプログラミングにはかなり自信がありますが、Objective-Cの方が使いやすく、本質的に柔軟性と動的性が高いと感じています。 iOSでゲームを書くためにObj-Cの代わりにC ++を使用する場合の長所と短所は何ですか？むしろ、C ++と比較してObj-Cの使用に既知の問題はありますか？ 例えば、私は疑いのObj-Cは、C / C ++で書かれたコードと比較してパフォーマンスの問題があるかもしれません。

18 c++  ios  performance  objective-c 

最近、私は自分のフレームワークのためにエンティティシステムを調査し、実装しています。私は見つけることができるほとんどの記事、reddits、およびそれについての質問を読んだと思います。 ただし、全体的なC ++の動作、エンティティシステムを実装する言語、およびユーザビリティの問題についていくつかの疑問が生じました。 したがって、1つのアプローチは、エンティティにコンポーネントの配列を直接格納することです。これは、データを反復処理するときにキャッシュの局所性を損なうため、実行しませんでした。このため、コンポーネントタイプごとに1つの配列を作成することにしました。そのため、同じタイプのすべてのコンポーネントがメモリ内で連続しており、迅速な反復に最適なソリューションになります。 しかし、実際のゲームプレイ実装のシステムからコンポーネント配列を繰り返し処理する場合、ほとんどの場合、一度に2つ以上のコンポーネントタイプを使用しています。たとえば、レンダリングシステムはTransformとModelコンポーネントを一緒に使用して、実際にレンダリング呼び出しを行います。私の質問は、これらのケースでは一度に1つの連続した配列を直線的に反復していないので、この方法でコンポーネントを割り当てることによるパフォーマンスの向上をすぐに犠牲にするのですか？C ++で2つの異なる連続した配列を繰り返し、各サイクルで両方のデータを使用する場合、問題がありますか？ 私が質問したい別のことは、コンポーネントまたはエンティティへの参照をどのように保持する必要があるかです。コンポーネントがメモリに配置される方法の性質は、配列内の位置を簡単に切り替えることができるか、配列が拡張またはコンポーネントポインターまたはハンドルが無効のままになります。フレームごとに変換や他のコンポーネントを操作したいことがよくあり、ハンドルまたはポインターが無効な場合は、フレームごとに検索するのが非常に面倒なので、これらのケースをどのように処理することをお勧めしますか？

18 c++  performance  entity 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Game Development Stack Exchangeで話題になるようにします。 2年前に閉店しました。 大学のプロジェクトのために、コンピューターグラフィックスを再び取り上げようとしています。以前のプロジェクトでは、FTGLと呼ばれるライブラリを使用しましたが、かなり重いと感じたため、満足できませんでした（多くのレンダリングテクニックを試しましたが、テキストレンダリングはあまりうまくスケールしませんでした）。 私の質問は、これのための良い効率的なライブラリはありますか？そうでない場合、高速だが見栄えの良いテキストを実装する方法は何でしょうか？いくつかの用途は次のとおりです。 フローティングオブジェクト/キャラクターラベル 対話 メニュー HUD 編集：できればフォントもロードできます

17 textures  rendering  performance  fonts  text 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Game Development Stack Exchangeで話題になるようにします。 4年前に閉鎖されました。 （これはゲームプログラミングそのものではありませんが、歴史上、すべての大規模なゲームがこれらのことを心配していると言っていても、これを早めに最適化しないように言われると確信しています） さまざまなC ++標準ライブラリ実装間のパフォーマンス、特にメモリ使用量の違いをまとめたドキュメントはどこにありますか？一部の実装の詳細はNDAによって保護されていますが、STLportとlibstdc ++とlibc ++とMSVC / Dinkumware（vs. EASTL？）との比較は非常に役立つようです。 特に、次のような質問に対する答えを探しています。 どのくらいのメモリオーバーヘッドが標準コンテナに関連付けられていますか？ 仮に宣言されただけで動的割り当てを行うコンテナがある場合、どのコンテナですか？ std :: stringはコピーオンライトを行いますか？短い文字列の最適化？ロープ？ std :: dequeはリングバッファーを使用しますか？

16 c++  performance  memory-efficiency 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 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 

そこには多くのMinecraftクローンがあり、私は自分の実装に取り​​組んでいます。テレインレンダリングの原則は、全世界を固定サイズのチャンクでタイリングして、ローカライズされた変更の労力を減らすことです。 Minecraftでは、現在のところ、チャンクサイズは16 x 16 x 256です。また、クローンでは、常に2のべき乗のチャンクサイズを見ました。 その理由はありますか、おそらくパフォーマンスやメモリに関連していますか？2のべき乗はバイナリコンピューターで特別な役割を果たすことを知っていますが、チャンクサイズとは何の関係がありますか？

15 performance  data-structure  minecraft-modding  memory 

*私の知る限り、Unity3D for iOSはMonoランタイムに基づいており、Monoには世代別のマーク＆スイープGCしかありません。 このGCシステムは、ゲームシステムを停止するGC時間を避けられません。インスタンスプーリングはこれを減らすことができますが、完全にではありません。CLRの基本クラスライブラリでインスタンス化を制御できないためです。これらの隠された小さくて頻繁なインスタンスは、最終的に不確定なGC時間を発生させます。完全なGCを定期的に強制すると、パフォーマンスが大幅に低下します（実際、Monoは完全なGCを強制できますか？） では、パフォーマンスを大幅に低下させずにUnity3Dを使用する場合、このGC時間をどのように回避できますか？

15 unity  performance 

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

15 c++  software-engineering  performance 

この質問が初めての場合は、以下の更新前の部分を最初に読んでから、この部分を読むことをお勧めします。 ただし、問題の統合は次のとおりです。 基本的に、衝突の順序と衝突グループが重要なグリッド空間分割システムを備えた衝突検出および解決エンジンがあります。一度に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 

最近、手続き的に生成された太陽系で行われるゲームに取り組み始めました。少し習熟した後（Scala、OpenGL 2 ES、Libgdxのいずれとも動作していなかった）、基本的な技術デモを行って、プロシージャルにテクスチャリングされた単一の惑星を回ります。 私が直面している問題は、テクスチャ生成のパフォーマンスです。私がやっていることの簡単な概要：惑星は球体に変形された立方体です。各側にanxn（たとえば256 x 256）テクスチャが適用され、フラグメントシェーダーに送信される1つの8n xnテクスチャにバンドルされます。最後の2つのスペースは使用されず、幅が2の累乗であることを確認するためにのみ存在します。テクスチャは現在、ペーパー「Simplex」にリンクされた2012年版のシンプレックスノイズアルゴリズムの更新を使用してCPU上で生成されていますノイズを分かりやすくする。アルゴリズムのテストに使用しているシーンには、惑星と背景の2つの球体が含まれています。どちらも6オクターブの3Dシンプレックスノイズで構成されるグレースケールテクスチャを使用するため、たとえばテクスチャサイズとして128x128を選択した場合、ノイズ関数の呼び出しは128 x 128 x 6 x 2 x 6 =約120万回になります。 地球に最も近いのは、スクリーンショットに表示されているものです。ゲームの目標解像度は1280x720であるため、512x512のテクスチャを使用することを好みます。もちろん、実際のテクスチャは基本的なノイズよりも複雑になります（日光に基づいたフラグメントシェーダとスペキュラマスクにブレンドされた昼と夜のテクスチャがあります。大陸のノイズ、地形の色の変化が必要です。 、雲、街の明かりなど）そして、我々は512 x 512 x 6 x 3 x 15 = 7000万のノイズが惑星だけを呼び出すようなものを見ている。最後のゲームでは、惑星間を移動するときにアクティビティが発生するため、移動中にバックグラウンドでテクスチャを計算できるため、5秒または10秒、場合によっては20秒の待機が許容されます。 テストシーンに戻ると、PCのパフォーマンスはそれほど悪くはありませんが、最終結果が約60倍悪化することを考えると、依然として遅すぎます。 128x128 : 0.1s 256x256 : 0.4s 512x512 : 1.7s これは、パフォーマンスに重要なすべてのコードをJavaに移動した後です。Scalaでそうするのはずっと悪かったからです。ただし、携帯電話（Samsung Galaxy S3）でこれを実行すると、より問題のある結果が生成されます。 128x128 : 2s 256x256 : 7s 512x512 : 29s …

14 textures  performance  procedural-generation  perlin-noise