ゲームエンジンのアセットを識別しますか?


12

ロードされたアセットを特定したいのですが、どちらを選択すべきかわかりません。2つのオプションがあります。

  • 名前(文字列)

    • これはunordered_map(O(1))を使用すると最も簡単で高速ですが、整数を使用する場合よりもずっと遅くなります。
    • コードで簡単に理解できます。
  • 整数

    • 最速。
    • コードでは理解できません。

文字列はそれほど安全でも高速でもないことを知っていますが、それはそれほど悪いのでしょうか、それともAAAタイトルで悪いとみなされるだけですか?整数を使用するために列挙を作成できましたが、実行時にファイルからシーン、アセットなどをロードすると、列挙を使用できません。実行時に生成されたこれらの整数を読みやすくする方法はありますか?

この問題にはインターネット全体にいくつかのスレッドがあることは知っていますが、どの場合にこれが重要であるかはわかりませんでした。


10
両方を実装しないのはなぜですか?文字列バージョンは、Dictionary <string、int>に接続し、Dictionary <int、Asset>を呼び出します。コード内の文字列ベースのレイヤーを回避することもできますが、ユーザー操作には文字列ベースのレイヤーを使用します。
Krythic 16

2
2番目の@Krythicのポイント。コードが速度のために整数を好む場合は、コードに整数を使用させます。ユーザーが読みやすい文字列を好む場合は、ユーザーに文字列を使用させます。2は非常に喜んで共存することができます(そして、あなたはあなたが選択のリリースで完全にオーバーヘッドをスキップしたい場合は、ビルドのみ開発に文字列バージョンをコンパイルすることができます)
DMGregory

わずかに異なるコンテキストでの同じ問題:アイテム実装の異なる方法-違いは何ですか?
フィリップ

回答:


19

両方をサポートできます。

多くの場合、整数または類似の高速比較キーでアセットを参照する方が実行時に効率的ですが、設計時では名前で参照する方が効率的であるenemy_bullet_casing_sound場合があり72910613ます。

整数キーを使用してリソースを直接検索し、可能な限りコード内でこの整数を使用します(整数の実際の値を変数に入れることができるため、作業が容易になります)。(リソースに直接ではなく)名前からその整数キーへのマッピングを提供し、アセットへの名前付き参照が発生するたびにそのマッピングを使用して、実際の整数キーを解決し、アセットを見つけます。

名前ベースのルックアップを使用すると、データファイルの操作がはるかに簡単になり、名前をより高速なキーにマッピングすると、必要な場所でより高速な整数型キーのすべての重要な利点が保持されます。


私の場合:オブジェクトのマテリアルを変更したいので、新しいマテリアルの名前を付けてリクエストを送信します。(文字列)その後、グラフィックスシステムでは、<string、pointer>順序付けられていないマップで検索が行われ、オブジェクトのマテリアルのポインターは新しいポインターに置き換えられます。だから私の場合、整数に変換する必要はありませんか?(これをポインターに変換し、頻繁に使用するアルゴリズムではポインターを使用するため、時々使用するのは文字列のみです。)
Tudvari

または、可能な場合はどこでもポインターの代わりに整数IDを使用する必要がありますか?(したがって、マテリアルなどのヘッダーファイルを含める必要はありません。)たとえば、レンダラーコンポーネントは、グラフィックエンジンで直接使用できる使用済みマテリアルのポインターを格納するようになりましたが、Material.hを含める必要があります。 。ただし、レンダラーコンポーネントに整数のみを格納する場合、Material.hを含める必要はありませんが、ポインターの配列で整数ベースの検索を行う必要があります。後者の方が良いと思います。それは...ですか?これをリファクタリングする必要がありますか?
トゥドヴァリ16

1

私のプロジェクトでは、コンパイル時に一意の(希望!)番号に変換されたハッシュ文字列を使用します。したがって、たとえばテクスチャなどのリソースが必要な場合は、単に呼び出します

MngTexture->get(hash("my_texture"))

そして、私は単純なエンティティシステムフレームワークを作成しており、ファイルからコンポーネントデータをロードする必要があるため、データを格納するためにjsonのような単純な言語を作成しましたが、コンパイル可能です(単語と文字を数字から数字に、文字列からハッシュ値に変換します) 。したがって、たとえば、ID hash( "my_texture")のテクスチャをデータファイルの "ball.PNG"にリンクする場合、次のようになります。

|my_texture| = "ball.PNG"

どこ|| 内部の単語をハッシュするようコンパイラーに指示する演算子です。

したがって、基本的には、実際のコードとコンポーネントをロードするためのストリームであるファイルの両方で、コンパイル時にintにマップされる文字列を使用します(したがって、オーバーヘッドはありません)。ハッシュをコンパイル時に計算するために、単にグーグルでググってください、それは5-10行のコードの単純な関数です。

もちろん、ファイルから文字列をロードして実行時にハッシュすることができます。この場合、アルゴリズムが文字列から整数を作成してくれるので、自分で辞書を書く必要はありません。メモリーの局所性のために、hasingは少なくともマップ内の検索と同じくらい速いと思います(長さが数バイトの文字列をループしているだけです)。

これが役立つことを願っています。


0

文字列によるオブジェクトの識別は最適ではなく、intははるかに効率的です。便宜上、intへの文字列の文字列テーブル(またはディクショナリ)を維持して、設計時およびデバッグ時に役立ちます。

ただし、コアゲームコード内では、整数ID(または読みやすい列挙型)でのみオブジェクトを参照することをお勧めします。これにより、文字列テーブルを個別のアセットとして簡単に分割できます。コアゲームコードがこの文字列テーブルに依存していない場合、リリースされたゲームから削除してメモリを大幅に節約できます-モバイルゲームで作業していて、ダウンロードサイズをできるだけ小さくしたい場合の重要な考慮事項可能。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.