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

データベースを必要とするリアルタイムのマルチプレイヤーゲームに取り組んでいます（プレイヤープロファイル、フレンド、ロック解除、ニュースなどの機能用）。これは標準のPCゲーム（ブラウザベースではない）であり、クライアントサーバーを使用します。建築。私はデータベースを使用するのが初めてであり、過去数日間、白熱した議論につまずいたとき、RDBMS対NoSQLのいくつかの研究を行ってきました。現在、私はNoSQLに傾いていますが、それぞれの使用法（RDBMSとNoSQL）を読んだ後、両方を使用したいと思っています。それは奇妙に思えるかもしれませんが、私の状況を説明させてください。 私のチームは、無制限のmySQLストレージと帯域幅を提供する共有Webホスティングパッケージを持っていますが、唯一の注意点は、一度に25の接続しか開けないことです（共有ホスティングルール）。ニュースの更新を投稿したり、コミュニティ機能（コメント、ファンアートのアップロードなど）をサポートしたりするために、これを自分のWebサイト（間違いなく通常の使用方法）で使用するつもりです。それはすべて大丈夫です-しかし！これは物事が面白くなるところです...私はゲーム内で私のウェブサイトに投稿されたこの同じ情報を表示したいです。これは、Webサイトとゲームの両方でmySQLを使用することを意味します。ニュースの投稿などに加えて、ゲーム内でチャットやサーバーリストなどに使用する予定です。私はその25接続ルールについてほとんど心配しています。 質問＃1を尋ねるに至ります：これは機能しますか？ これに加えて、NoSQLのパフォーマンスとリアルタイムゲームに適していることについて読みました（間違っている可能性があります。私はここに到達するために巨大なRDBMSとNoSQLのフレーム戦争を経験し、おそらく火傷します）。基本的に、すべてのゲームオブジェクトデータにMongoDBを使用します。 繰り返しになりますが、何らかのコンテキストを提供すると役立ちます。240MBのMongoDBパッケージを無料で提供するホスト（MongoLab）を見つけました。アップグレードが必要になるまで使用します。240MBを考えると、約60,000人のプレーヤーを保存できると計算しました（各プレーヤーが約4KBで、保存される可能性のある他のものを無視する場合）。記憶域、および将来的にもっとお金を払わなければならない場合（ゲームが成功する場合）は問題ではありません。私が現在すべてのゲームオブジェクトデータにMongoDBを使用する唯一の理由は、このゲームオブジェクトデータにアクセスする頻度（プレーヤーが殺されたとき、アイテムを拾ったとき、銃を撃ったときなど）のためです。また、単純なスキーマフリードキュメント（ゲームオブジェクトデータのマッピングを容易にする）も好きです。かつて、 私は自分のWebサイトで同じMongoDBを使用して、プレーヤーのプロファイル情報を表示するつもりです（完全な一貫性は気にしません。ゲーム内の更新からの遅延は問題ありません）。2番目の質問、質問2に進みます。これは良いアイデアですか、それとももっと良い方法がありますか？ このゲームは、次のような起動エクスペリエンスを備えています。 クライアントのログイン（MongoDB） クライアントは、チャットルーム（MySQL）のあるゲーム内のホームページにあります。 クライアントはサーバーリストに移動します（MySQL） クライアントはサーバーに接続して再生します サーバーはすべてのプレーヤーの更新を通信します（MongoDB） これは私がそれが機能すると想像した方法です。これはあなたによく見えますか、またはこの計画をどのように改善できるかについての提案がありますか？

12 multiplayer  performance  client-server  databases 

これはMMOのパフォーマンスに関連していますが、質問は帯域幅に関するものです。これはCPUの負荷に関するものです。 node.jsとwebGLを使用して簡単なFPSを作成しました。これは非常にシンプルで、MIDI MazeのBuddyMazeクローンによく似ています。ほとんど何も起きていません。全員が2次元（高さなし）で動き、単純な発射体を発射し、壁にぶつかります。 今、サーバーに複数の接続を行い、すべてのプレイヤーが円を描くように高速で射撃する場合、サーバーがコアを使い果たして速度が低下する前に、ゲームで約15〜20人のプレイヤーを獲得できます。これは、サーバーで30 fpsで実行している場合です。10 fpsでは、約25-30の接続が得られます。これはかなり悪いことです。ゲームにはすぐにもっと多くのことが必要になるからです。これを実現するためには、より多くのプレイヤーにフィットさせる必要があります。 私の兄弟は、同僚のTF2サーバーに関する統計情報をいくつか指摘しました。彼のサーバーは私たちのサーバーよりもスペックが低いですが、TF2を実行します。明らかに毎秒500ティック、コアあたり36ユーザーという非常に複雑なゲームです。また、現在、使用する帯域幅よりもはるかに多くの帯域幅を消費していますが、それ以上下げることはまだ試みていません。 これはどのように可能ですか？サーバーのパフォーマンスをこの程度まで向上させるには、どのようなトリックがありますか？私が知っているいくつかのことは次のとおりです。 サーバーのフレームレートを下げ、クライアントの位置を補間します。いくつかの利点が得られましたが、明らかにTF2サーバーはこれを気にしません。 クライアントでの衝突検出などの高価なことを行い、サーバーで頻繁にそれを検証します。私はまだこれを引っ越していません、今夜にしましょう。それでも、私はそのような大きな利益を期待していません。 計算を最小限に抑えるために、競技場を地域（四分木）に分けます。この機会はまだありません。 node.jsはTF2が使用しているものよりもかなり遅く、この種の高強度タスクには適さない可能性があるという残念な可能性を検討しました。 それはすべてサーバー構成の魔法ですか？ それでは、サーバー上で最低限必要なことだけを行いながら、完璧なゲーム体験を維持するための業界の他のトリックは何ですか？「CPU時間を節約するためにクライアントを延期する」と「クライアントを信頼しない」との間に大きな矛盾があります。 更新 プロファイリングは、私がこれまでに発見した唯一のマントラです。コードにいくつかのタイミング関数をすばやくラップし（ありがとう、FP！）、予期しないことを発見しました。データをクライアントにブロードキャストする行為は、実行時間のほぼすべてを占めています。具体的には、その約90％です。さらにテストを行ったところ、この時間はクライアントの数とデータのサイズの両方に依存していることが判明しましたが、データのサイズに大きく依存しています。ユーザー数が20人の場合、全データの代わりに「{}」のみを送信することで、ブロードキャスト時間を90％に24ミリ秒から2ミリ秒以上に短縮しました。ただし、ユーザーが5人のみの場合、ブロードキャストには約0.5ミリ秒かかります。したがって、ここでいくつかの最適化を行う必要があることは明らかです。 最初の最も明らかな改善点は、見通しの確認です。これにより、データを気にする人の数と、関係者に送信されるデータの量の両方が減少します。私が試すことができるこの分野には、ブロードキャスト操作のコストを最小限に抑えることに焦点を当てた他のトリックがありますか？

12 performance  client-server  first-person-shooter 

なぜアクセスするために、ユニティ使用リフレクションを行うMonoBehaviourようなメッセージ法Awake、Update、Start、...？ リフレクションを使用するのは遅いのではないでしょうか？なぜ他のアプローチを利用しないのTemplate Methodですか？MonoBehaviour基本クラスでメソッドを抽象として定義し、サブクラスにそれを実装させるだけです。

12 unity  c#  performance 

頂点またはフラグメントシェーダーがレンダリングパイプラインのボトルネックになっているかどうかを確認する方法を知りたいのですが。 OpenGLコマンド間のクロックチェックポイントを取得するためにターゲットを使用glQueryCounterすることについて読みましたGL_TIMESTAMPが、これらは異なるタイプのシェーダーを区別しません。 たとえば、GPUの1つのフレームのレンダリングに8ミリ秒かかった場合、頂点シェーダーに7ミリ秒かかり、フラグメントシェーダーに1ミリ秒かかったと言えますか？

11 opengl  shaders  performance  profiling 

グラフィックスを扱うとき、私はしばしば多くの時期尚早な最適化を行う傾向があります。私が常に従おうとするいくつかの原則があります。 D3Dコンポーネントの数を最小限に抑えます。（レンダリング状態、バッファー、シェーダーなど） どうしても必要な場合にのみコンポーネントをバインドします。（まだバインドされていないなど） コンポーネントをできる限り専門化します。（必要なBindFlagsのみを設定するなど） これにより、作成されたコンポーネントと現在のパイプライン状態を管理するための非常に手の込んだラッパーを構築することになりました。これは私の貴重な開発時間の多くを消費するだけでなく、複雑さをさらに大きくします。 そして最悪の事態： 場合、それがすべてトラブルに値するかどうかさえ知りません。 私の最適化の考慮事項のいくつかは、すでに下位レベルで実装されている可能性があり、それらを複製しているだけで、CPUの時間をさらに浪費しています。パフォーマンスへの影響は無視できるため、他の考慮事項は完全に不要な場合があります。 だから私の質問は： 上記のガイドラインのうちどれが有効で、どの程度遵守する必要がありますか？ GPUは状態の変化をどのように処理しますか？ 使用されていない状態を変更するとどうなりますか？（アクティブな間は、描画呼び出しは行われません。） さまざまな異なるコンポーネントをバインドするための実際のパフォーマンスペナルティは何ですか？ 他にどのようなパフォーマンスの考慮事項を行う必要がありますか？ 実際の制限に達するまでは、パフォーマンスについて気にしないでください。それは明らかに実用的な見地からは真実ですが、私は主に理論に興味があります。どういうわけか、最適なグラフィックスフレームワークを構築するという衝動と闘う必要がありますが、通常の「時期尚早の最適化講義」ではそれを実現できないと思います。 コンポーネントの管理 現在、SlimDXをマネージラッパーとして使用して、DirectX 11アプリケーションをC＃で作成しています。これは非常に低レベルのラッパーであり、私の現在の抽象化はその上に構築されています。 Direct3D抽象化を使用する場合、いくつかの明らかな利点があります。環境の設定、シェーダーの読み込み、定数の設定、メッシュの描画は、はるかに簡単で、使用するコードが大幅に少なくなります。また、ほとんどのコンポーネントの作成と破棄を管理するため、どこでも自動的に再利用でき、メモリリークをほぼ完全に回避できます。 通常、すべてのグラフィックコンポーネントとリソースをどのように管理しますか？ 以下の私の例と同様のことを行うマネージラッパーを推奨できますか？ これが私の現在の実装例です。インターフェースにとても満足しています。私のニーズに対して十分な柔軟性があり、使用および理解が非常に簡単です。 // Init D3D environment var window = new RenderForm(); var d3d = new Direct3D(window, GraphicsSettings.Default); var graphics = new GraphicsManager(d3d.Device); // Load assets var mesh = GeometryPackage.FromFile(d3d, "teapot.gp"); …

11 directx  performance 

私はネイティブフラッシュレンダリングBitmapDataとカスタムフレームバッファーの構築についてSOを読んでいて、答えのいくつかは少し矛盾していたので、私は疑問に思いました： 一般に、カスタムビットマップバッファールートを使用するのがベストプラクティスですか、それともレンダリングをフラッシュエンジンに任せるのがベストですか？ MovieClipスプライトではなくベクターアニメーション（s）を使用している場合、それによって上記の答えが変わりますか？ もしそうなら、スプライトベースのアニメーションを使用することがベストプラクティスですか？ （違いが出る場合は、Flash 10を対象としています）

11 flash  optimization  sprites  performance 

Vector3をVector2に変換する最も効率的で最速の方法は何ですか？ 鋳造： Vector2 vector2 = (Vector2)vector3; 新しいVector2の初期化： Vector2 vector2 = new Vector2(vector3.x, vector3.y); または私が知らない別の方法はありますか？

11 unity  c#  performance 

基本的なシステム、コンポーネント、エンティティのアプローチから始めます。 コンポーネントのタイプに関する情報だけから集合（この記事から派生した用語）を作成しましょう。これは、エンティティにコンポーネントを1つずつ追加/削除するのと同じように、実行時に動的に行われますが、タイプ情報のみを対象としているため、より正確に名前を付けましょう。 次に、それらすべての集合を指定するエンティティを作成します。エンティティを作成すると、その組み合わせは不変です。つまり、その場で直接変更することはできませんが、ローカルコピーへの既存のエンティティの署名を（コンテンツとともに）取得し、適切に変更して、新しいエンティティを作成できます。それの。 ここで重要な概念について説明します。エンティティが作成されると、それは常にassemblage bucketというオブジェクトに割り当てられます。つまり、同じ署名のすべてのエンティティが同じコンテナ（例：std :: vector）に置かれます。 現在、システムは関心のあるすべてのバケットを反復処理し、その仕事をしています。 このアプローチにはいくつかの利点があります。 コンポーネントは少数（正確にはバケット数）の連続したメモリチャンクに格納されます-これによりメモリの使いやすさが向上し、ゲーム全体の状態をダンプするのが簡単になります システムはコンポーネントを線形的に処理します。つまり、キャッシュの一貫性が向上します。さようなら辞書とランダムメモリジャンプ 新しいエンティティの作成は、アセンブリをバケットにマッピングし、必要なコンポーネントをそのベクトルにプッシュバックするのと同じくらい簡単です エンティティの削除は、std :: moveを1回呼び出して最後の要素を削除された要素と交換するのと同じくらい簡単です。現時点では順序は関係ないためです。 完全に異なるシグネチャを持つ多くのエンティティがある場合、キャッシュコヒーレンシの利点はある程度減少しますが、ほとんどのアプリケーションでは発生しないと思います。 ベクトルが再割り当てされると、ポインターの無効化にも問題があります。これは、次のような構造を導入することで解決できます。 struct assemblage_bucket { struct entity_watcher { assemblage_bucket* owner; entity_id real_index_in_vector; }; std::unordered_map<entity_id, std::vector<entity_watcher*>> subscribers; //... }; そのため、ゲームロジックの何らかの理由で、新しく作成されたエンティティを追跡したいときはいつでも、バケット内にentity_watcherを登録し、エンティティを削除中にstd :: moveする必要がある場合は、そのウォッチャーをルックアップして更新しますそれらreal_index_in_vectorを新しい値に。ほとんどの場合、これはエンティティの削除ごとに1回の辞書検索を課します。 このアプローチには他に不利な点はありますか？ なぜ明白なのに、なぜ解決策がどこにも言及されていないのですか 編集：コメントが不十分であるため、「回答に答える」ために質問を編集しています。 静的なクラスの構築を回避するために特別に作成された、プラグ可能なコンポーネントの動的な性質を失います。 私はしません。多分私はそれを十分に明確に説明しなかった： auto signature = world.get_signature(entity_id); // this would just return …

11 architecture  performance  entity-system  entity-component 

たとえば、Bootcampを搭載したMac Miniでは、Team Fortress 2はOSXでは約20fps、Windowsでは約80fpsで動作します。これは一般的なケースのようです。どうしてこれなの？

11 performance  windows  macos 

最近、ゲームに地形を生成する最良の方法について考えている問題に悩まされています。別のプロジェクトでは、通常はハイトマップを使用したため、すべてのコアワークは使用されたエンジンに基づいていましたが、地形には正確に描画する必要がある数百万の特定のポリゴンがあるため、これは実行できません。また、それらの多くはYベクトルから解析できません（ポリゴンが下に隠れているため）。つまり、ハイトマップはここでは役に立ちません。この場合、COLLADAオブジェクトを使用する必要がありました。 誰かがBlenderのようなソフトウェア内でモデルを手動で分割するように言ったが、残念なことに、これらの地形は別のソフトウェアのチャンクで作成され、ゲームに読み込まれるため、これも不可能である（それはアイデアだ）。したがって、これは毎回手動でスライスすることを余儀なくされる大きな仕事になるでしょう。 したがって、この問題を1週間解決して、このメッシュ、つまり地形をカメラのフラストラムに応じて手続き的にロードする方法について1週間研究してきました。これにより、可能な限りパフォーマンスを節約できます。手続き型メッシュの生成に関する多くのドキュメントに出くわしましたが、メッシュを八分木にマッピングすることで問題を解決できると思います。これは少なくとも私にとっては大きな仕事であり、それが私がここにいる理由です。なぜなら、私は経験豊富な人々から聞く前に間違った道をたどるリスクを冒したくないからです。 要するに、私には何百万もの頂点とインデックスがあり、それらが一緒になって地形を形成していますが、明らかな理由により、それらを同時に描画することはできません。何らかの手続きが必要です。大きなメッシュを地形として扱うために、それを行うための最良の方法は何ですか？それに関する具体的な本はありますか？それを実装する最良の方法はありますか？ どんな間違いでもすみません、私はこの分野の初心者です。

10 opengl  3d  performance  terrain  octree 

DirectXとOpenGLの両方のコンピューティングシェーダーが利用可能になったことで、ラスタライズパイプラインを経由せずに多くのアルゴリズムを実装し、代わりにGPUで汎用コンピューティングを使用して問題を解決できるようになりました。 一部のアルゴリズムでは、これは本質的にラスター化ベースではないため、これは直感的な標準的な解決策になり、ラスター化ベースのシェーダーはGPUパワーを活用するための回避策のように見えました（簡単な例：ノイズテクスチャを作成します。ここでクワッドをラスター化する必要はありません） ）。 両方の方法で実装できるアルゴリズムが与えられた場合、通常のルートを使用する場合と比較して、計算シェーダーを使用する場合に比べて一般的な（潜在的な）パフォーマンス上の利点はありますか？注意が必要な欠点はありますか（たとえば、実行時にシェーダーの計算を切り替えるために、ある種の異常なオーバーヘッドがあります）？ 2つを選択するときに考慮すべき他の利点または欠点はおそらくありますか？

10 performance  gpgpu 

複数のライトで高速ライティングを実装するにはどうすればよいですか？ プレイヤーを拘束したくありません。彼は無制限の数を配置でき、場合によっては重なっている（ポイント）ライトをレベルに配置できます。 問題は、ライティングの計算に必要な動的ループを含むシェーダーが非常に遅くなる傾向があることです。 コンパイル時にシェーダーをn回コンパイルすることが可能である場合、nはライトの数であるという考えがありました。コンパイル時に数値nがわかっている場合は、ループを自動的に展開できます。これは、異なる数のライトで同じシェーダーのnバージョンを生成することは可能ですか？ 実行時に、レベルのどの部分にどのシェーダーを使用するかを決定できます。

10 xna  shaders  performance  hlsl  lighting 

ハードウェアのインスタンス化を実行しようとしていますが、奇妙なパフォーマンスの問題が発生しています。平均フレームレートは約45ですが、非常に不安定です。 窓付き SynchronizeWithVerticalRetrace = false IsFixedTimeStep = false PresentationInterval = PresentInterval.Immediate 下の画像は測定したタイミングを示しています（を使用Stopwatch）。一番上のグラフはDrawメソッドで費やされた時間で、一番下のグラフは終了からDraw開始までの時間ですUpdate スパイクはほぼ正確に1秒間隔であり、常に通常の時間の2、3、4、または5倍です。スパイクの直後のフレームにはまったく時間がかかりません。ガベージコレクタではないことを確認しました。 私は現在、100万のインスタンスを持つ12個の三角形と36個の頂点で構成されるメッシュを三角形リストとしてインスタンス化しています（最適ではないことを知っていますが、テスト用です）。インスタンス化の描画呼び出しを250インスタンスの小さな部分にバッチ処理すると、問題は軽減されますが、CPU使用率が大幅に増加します。上記の実行は、描画呼び出しごとに10000インスタンスです。これは、CPUではるかに簡単です。 全画面でゲームを実行すると、下部のグラフはほとんど存在しませんが、Drawメソッドで同じ問題が発生します。 これはPIX内での実行ですが、まったく意味がありません。一部のフレームではレンダリングが行われていないようです... 何か考え、これを引き起こしている可能性がありますか？ 編集：要求に応じて、レンダーコードの関連部分 A CubeBufferが作成および初期化され、次にキューブで満たされます。キューブの量が特定の制限を超えると、新しいものCubeBufferが作成されます。各バッファは、1回の呼び出しですべてのインスタンスを描画します。 一度だけ必要な情報はstatic（頂点、インデックスバッファー、頂点宣言です。これまでのところ違いはありません）。テクスチャは512x512です ドロー（） device.Clear(Color.DarkSlateGray); device.RasterizerState = new RasterizerState() { }; device.BlendState = new BlendState { }; device.DepthStencilState = new DepthStencilState() { DepthBufferEnable = true }; //samplerState=new SamplerState() { AddressU = TextureAddressMode.Mirror, …

10 xna  performance 

この質問は少しトリッキーですが、私はそれを明確にするように努めます。 私がオンラインゲーム（MMOスケールではない）を構築しているとしましょう。しかし、それは信頼できるサーバーアプローチで可能な限り多くのプレイヤーをサポートします。AIシミュレーションの敵がたくさんいる本当に大きな世界が欲しいです。 スペースを分割して処理の必要がないものを処理しないことにより、サーバーのCPUを節約するいくつかの戦略を知っています。ロードタイムと小さなトランジションを必要とする地域ですでに世界を分割しています。ローカルで（単独で、または数人の友人と一緒に）プレイするときにゲームプレイの品質を維持することが重要だと思います。プレイヤーが1つまたは2つ以上のリージョンにいるとは思わない。 問題は、リージョンがかなり大きくなり、一度に多くのNPCをシミュレートできることです。プレイヤーの経験に影響を与えずにこれをどのように処理しますか？地域ごとに1つのサーバーなどのアプローチは、この表には含まれていません。 私は主に敵の大群、さらには平和なNPCを保持するためのデータ構造を探しています。質問を完成させるために、車両が存在するため、リージョン内を移動するのがかなり速く、エリアを間引く「タイミング」に影響を与えることに注意してください。

10 multiplayer  performance  data  architecture  space-partitioning 

パーティクルシステムのオブジェクトプールをJavaで実装するつもりでしたが、ウィキペディアでこれを見つけました。言い換えると、JavaやC＃などのマネージ言語ではオブジェクトプールを使用する価値がないとあります。これは、C ++などの非マネージ言語では数百の操作に比べて、割り当てには数十の操作しか必要ないためです。 しかし、誰もが知っているように、すべての命令はゲームのパフォーマンスを損なう可能性があります。たとえば、MMO内のクライアントのプール：クライアントがプールに入ったり出たりする速度が速すぎません。しかし、粒子は一秒間に数十回更新される可能性があります。 問題は、マネージ言語でパーティクル（具体的には、死んですぐに再作成されるもの）のオブジェクトプールを使用する価値があるかどうかです。

10 performance  design-patterns  particles