リソースマネージャー-彼らは良いですか？

私はこのようなことをソースコードで何度も見てきました[まあ、これはもっと私の擬似C ++のアイデアです]

typedef shared_ptr<Resource> ResourcePtr;// for ease  
ResourcePtr sound1 = resourceManager.Get<SoundResource>("boom.ogg");  
sound1->Play();  
ResourcePtr sprite = resourceManager.Get<Image>("sprite.png");

私はこのようなクラスがどれほど役に立つか、ただ疑問に思っていました：

• ロードされたメディアファイル
• それらをメモリに保存しました
• これはレベルの開始時に行いました-ロード画面。
• 掃除した

次のシステムを持つのではなく：

• リソースはエンティティのみによって保持されているか、緩やかです。
• メモリへの独自のロードを担当します。

最初は、そのような「マネージャー」です。私が感じる何かは、それが使用するのが間違っていることを示しています。ただし、ロードする必要のあるものすべてを探し回るのではなく、リソース名のベクトルのようなものを渡すことができます。

優れたリソースマネージャーは、ゲームの「エンジン」がどれだけ優れているか、そしてどれだけ柔軟であるかを決める鍵です。

低レベルのリソース管理に関する多くの問題を解決するだけでなく、リソースが一度だけ読み込まれ、既に読み込まれている場合は再利用されるようにするのにも役立ちます。

リソースシステムが適切に抽象化されている場合、基礎となる詳細はファイルシステム、physfsストレージ、sqlの間で注意が必要です。

リソースをリクエストするだけで、リソースが提供されます。

リソースIDなどを心配する必要はありません。

重複するリソースの競合処理など。

リソースマネージャにそれを分類させます。

設計方法に応じて-C ++がシーン管理クラスと友達になり、所有権が適切に処理されるようにします。

リソースプール

問題ない。

リソースのリリースを忘れましたか？

問題ない。

メモリ、ディスク、アーカイブ、ネットワークなど、どこにいてもリソースと同じインターフェイス。

問題ない。

ストリーミングしますか？

スレッディング？

リソース管理ハブにそれを任せてください。

また、リソースを使用する準備ができたときに通知されるので安心できます。

Ogre 3Dには非常に柔軟なリソース管理システムがありますが、他にも「外に」あると確信しています。

私は最近、私の場合に非常にうまく機能するリソースマネージャーを書きました。主な特徴：

• リソースは、などのストリングIDによって要求されますResourceManager::instance().getTexture("textures/player.png")。テクスチャIDは現在、ディスク上のファイルに直接マッピングされています。これは開発中に便利ですが、これは後でいくつかのアーカイブのルックアップに置き換えられます。

• リソースマネージャーは、リソースへのIDのマップを保持するため、既にロードされているリソースをリロードしません。

• 上記の呼び出しはTextureオブジェクトを返すのではなく、オブジェクトを返しResource<Texture>ます。呼び出し元はResource<Texture>、実際のテクスチャではなくオブジェクトを保存することが期待されています。はResource<Texture>、へのスマートポインターのように動作しTextureます。そのoperator*()リターンTextureオブジェクトそのもの。利点は、すべてのクライアントを更新する必要なく、実際のテクスチャを再ロードまたはアンロードできることです。

• リソースマネージャは、ディスク上のファイルが変更されたかどうかを定期的にチェックし、必要に応じてそれらをリロードします。これにより、テクスチャやシェーダーを変更して、ゲームを再起動することなく結果を確認できます。

• リソースは互いに依存する場合があります。すべてではありませんが、ほとんどのリソースはリソースに依存してFileいます。リソースとは、ロード元のファイルです。たとえば、モデルがテクスチャに依存している場合、テクスチャファイルがディスク上で変更されるたびにモデルが再ロードされます。

• リソースが見つからない場合、またはロードに失敗した場合、デフォルトのリソースがサイレントに置換されます。これにより、ゲームをクラッシュさせることなく、まだ作成していないリソースを使用できます。（計画された機能：GPGPUシェーダーなどの「必須」リソースを示します。これがないと、ゲームを適切に実行できません。）

• 参照カウントと未使用リソースのアンロードは簡単に追加できます。私のゲームはかなり小さいので、私はまだこれを必要としませんでした。

この機能リストは、はい、リソースマネージャーが良いことを示していると思います！

リソースマネージャーを使用する理由の1つは、リソースの共有です。たとえば、を呼び出すときresourceManager.Get("sprite.png")に、「sprite.png」が既にロードされている場合、リソースマネージャーは、新しいイメージを作成してディスクから再ロードするのではなく、既にロードされているスプライトリソースへのポインターを返すだけです。

リソースマネージャーはリソースをキャッシュすることもできるので、リソースへの最後の参照は削除されますが、リソースマネージャーは、近い将来に再びロードされた場合に備えてメモリに保持することを選択できます。リソースマネージャーは、リソースのすべてのメモリ管理を自動的に処理するようにプログラムされます。

最後に、非常に便利な機能は、ゲーム内でのリソースのリロードです。リソースマネージャーはすべてのゲームリソースへのハンドルを保持するため、すべてのリソースをディスクからリロードし、ゲームをリアルタイムで更新する機能を組み込むことができます。これは、ゲームで作業するアーティスト/デザイナーにとって非常に便利です。 。

別の利点は、キャッシングと参照カウントに加えて、依存関係（モデルaにはテクスチャbが必要ですか？yaで入手できます！）およびロード順序の問題（モデルaにはシェーダbが必要とするものを知る必要がありますか？ bモデルをロードする前に！）