音声の資源管理モジュールをつくるが、SEのみ。ストリーム再生とかBGMについてはまだサポートできていない。再生させること自体は1日くらいの作業だろうと思って放置しておいたのだが、考えてみれば当たり前のことだが、使うwavを全部メモリに読み込んでおくわけにもいかず、資源管理のポリシーの決定+その実装が必要なわけで。みくびっていた。

ゲームというシステムは、BGMをCDDAするとかいう例外を除いては、どんなリソースも頻繁にアクセスするものを一旦アクセスしやすい場所に置いて使用、保守し、時期や使用頻度や全体のサイズをみて開放するという操作が必ず必要になってくるんだなということに今ごろになってやっと気が付く。思えばそんなような機構を何回も作ってきていた。頭を合成したキャラクタのテクスチャの管理。画面に表示する文字の管理。オブジェクト用メッシュの管理。今回の音声。管理機構が自律的に開放しないものも数えればさらに増えてくる。もしかしたらジェネティックな実装によって全ての管理を型に依存せず一まとめにすることもできるかもしれない。まぁロマンチックではあるけれども、そうすべきかどうかはわからない。

DirectSoundのバッファを3Dに対応させて鳴らすと、なぜかバッファの一度目の再生ではきちんと鳴るが、以降そのバッファを使って再生させると0.02秒くらい前方から再生が始まる。DirectSoundか、ドライバか、どこに問題があるのかは不明。

音声管理モジュールに用意したnamespace内のstatic関数を呼ぶだけでなぜかメモリリークが発生。蓄積するものではなく何回アクセスしても一定量しかできないのでとりあえずほっとくことにする。

いつのまにかdirect3d_device->Reset()が失敗するようになっている。そのためウィンドウのリサイズをしようとすると落ちてしまう。現在原因究明中。

→原因というかなんなのか、D3DXMeshの内部のVertexBufferを一度でもSetStreamSourceすると未来のResetが失敗するようだ。こんな判明して知ることになっても別に何の得にもならない仕様だが、一見まともに動いてしまって、後々Resetする段になって不具合が出現するため、原因を発見するのにめちゃくちゃ時間がかかってしまった。結局この部分は昔の名残でD3DXMeshを使ってただけで実際にはVertexBufferにしか用がないのでVertexBufferを直接使うように修正した。