menu
 
バージョン
2024.1.4.8780

2024.1.4.8780

2023.1.12.8706

2022.1.18.8567

2021.1.14.8108

2019.2.15.7667

2019.1.11.7296

2018.1.11.6987

2017.2.10.6745

2017.1.9.6501

2016.2.6.6153

2015.1.9.5624


menu_open
警告:このページでは、一部の保護された情報が表示されません。
あなたが特定プラットフォームのライセンスを所有しているユーザであれば、最初にログインしてください。
Wwise SDK 2024.1.4
メモリマネージャ

Wwiseサウンドエンジンのすべてのモジュールは、AK::MemoryMgr インターフェイスを介してメモリにアクセスします。サウンドエンジンクライアントによって、このインターフェイスの初期化および終了が行われます。

デフォルト実装は、静的ライブラリ(AkMemoryMgr.lib)としてSDKで提供されています。このライブラリを使うには、クライアントは、 AkModule.h ヘッダを含めて、 AK::MemoryMgr::Init の初期化関数をコールする必要があります。

AkMemoryMgr.libとその他ライブラリの使用に関する詳細は ビルド構成 を参照してください。

初期化

デフォルト実装では、デフォルトの初期化設定を AK::MemoryMgr::GetDefaultSettings を使い取得できます。

デフォルトメモリアロケータの使用

デフォルトでは、すべてのメモリは組み込みAkMemoryArenasを使用してWwiseによって割り当てられます。組み込みAkMemoryArenasは、それぞれ「AkMemSettings::memoryArenaSettings」配列を使用して個別に設定できます。AkMemoryArenasは最大4つ設定できます。

  • 「AkMemoryMgrArena_Primary」:ほとんどのメモリカテゴリで使用されるデフォルトのAkMemoryArena。
  • 「AkMemoryMgrArena_Media」:メモリアロケーションで使用されるAkMemoryArena。通常はSoundBankのロードでMediaメモリカテゴリに移動します。
  • 「AkMemoryMgrArena_Profiler」:メモリアロケーションで使用されるAkMemoryArena。ProfilerおよびMonitor Queueメモリカテゴリに移動します。このAkMemoryArenaはReleaseビルド構成には存在しません。
  • 「AkMemoryMgrArena_Device」:デバイス固有のメモリアロケーションを処理するために使用されるAkMemoryArena。これはオーディオ処理でデバイス固有のメモリを使用する特定のプラットフォームにのみ存在します。つまり、「AK_DEVICE_MEMORY_SUPPORTED」が定義されているプラットフォームです。

ゲームエンジンに組み込む場合、AkMemoryArenaごとに以下のコールバックを実装することを推奨します。これらのコールバックは、AkMemoryArenaが必要に応じてメモリの範囲を取得または解放する際に使用されるためです。

  • 「AkMemoryArenaSettings::fnMemAllocSpan」
  • 「AkMemoryArenaSettings::fnMemFreeSpan」

「AkMemoryArenaSettings::uMemReservedLimit」を使用して、それぞれのAkMemoryArenaで予約するメモリ量の上限を設定することもできます。

AkMemoryArenaに関するその他の設定については、 AkMemoryArenasの設定と調整 を参照してください。

カスタムメモリアロケータの使用

すべてのメモリアロケーションでAkMemoryArenaを無効にして、カスタムアロケータを使用するには、次のコールバックをすべて上書きします。

上記のアロケーション関数が「AkMemType_Device」ビットを尊重し、ビットが設定されたらデバイスメモリを返すことが重要です。

info注釈: カスタムメモリアロケータを使用する場合は、WwiseでAkMemoryArenasをプロファイリングすることはできません。

デバッグの設定

追加のランタイムデバグ機能を有効にするには、以下の設定を使います:

これは、カスタム実装で、好きなだけのメモリデバグ機能を定義できるようにする不透明な値です。デフォルトの実装で、2つのレベルが提供されます。

  • Level 1は基本的なランタイムメモリデバグを有効にし、これに含まれるのは、アロケーションごとの FILELINE のキャプチャ、アロケーションごとのcallstackのトラッキング(可能な場合)、シャットダウン時の詳細なリーク報告、そして非常に軽いインテグリティチェックなどです。開発中にデフォルトで実行できるほど、軽いものです。
  • Level 2はstompアロケータの使用を有効にして各アロケーションでバーチャルメモリの個別のページを使い、out of boundsで発生する書き込みをトラップしようとします。これは、非常に遅くてリソース負荷の高いモードなので、開発中にデフォルトで有効にするのは避け、メモリストンプの原因を探し出そうとするときに限り使うことを、推奨します。

全てのアロケーションをファイルにダンプするには、以下を使います(必ず、 AkMemSettings::uMemoryDebugLevel を1として、Releaseコンフィギュレーションでないものを使ってください):

備考: サウンドエンジンが、 AK::IAkStreamMgr::CreateStd() を使って書き込み用のストリームを開きます。Stream Managerのデフォルト実装を使用している場合は、ファイルを開く処理は、Low-Level IOインターフェースの AK::StreamMgr::IAkLowLevelIOHook::BatchOpen() を実装した時に実行されます。

デバッグ用にアロケーションをトラッキングするには、以下の設定を使用します(Releaseコンフィギュレーションでは、これらは呼び出されません)。

上記のデバッグ関数はアロケーション関数を置き換えるものではなく、各種メモリアロケーションイベントの通知コールバックです。

詳細については、以下のセクションを参照してください:

メモリマネージャのオーバーライド

クライアントは、 AK::MemoryMgr のインターフェースのカスタム化された実装を提供することができます。 AkMemoryMgr.h で定義されている関数は、すべて実装してください。 AkModule.h で定義された AK::MemoryMgr ネームスペースの関数は、メモリマネージャのデフォルト実装のためのものなので、実装する必要はありません。

「AkMemSettings」のさまざまなアロケーション関数をオーバーライドする時と同様に、新しいAK::MemoryMgrの実装をプログラミングする時は、ビットが設定されたらデバイスメモリを返すことで、AkMemType_Deviceビットを尊重することが重要です。デバイスのメモリアロケーションは、一部のプラットフォームでしか使われていなく、具体的なパラメータに準拠する必要があるので、詳しくはプラットフォーム別のセクションを参照してください。


このページはお役に立ちましたか?

サポートは必要ですか?

ご質問や問題、ご不明点はございますか?お気軽にお問い合わせください。

サポートページをご確認ください

あなたのプロジェクトについて教えてください。ご不明な点はありませんか。

プロジェクトを登録していただくことで、ご利用開始のサポートをいたします。

Wwiseからはじめよう