Textureコンストラクタ vs TextureLoader

放置しすぎて、このまま放置を続けた方が本来あるべき姿のような気もするけど、折角書く気になったのだから捨て置くのももったいない。という訳で何か最近気づいた事を適当に書いてみる。

最近ようやくやる気が復活してきたので、例の(?)DirectXのラッパライブラリを見直している。Managed DirectXってなんかどうも捨てられてるっぽい(November 2007以降ではSDKからManaged用のドキュメントが削除されるとか......XNAってのが主流なのか?)し、既存のラッパライブラリをC++ .NETからいじった方が色々と楽そうな気もするけど、無下にするのも忍びないし、ま、一回くらい自力でラッパライブラリ作る経験があったって罰は当たらないだろうという事で継続する事にする。しかし、企画した時から2年以上経っているんだなあ。無為に過ごすと時って凄く速く過ぎ去るもので。少年老いやすく学成りがたしとはよく言ったものだ。

ま、それはともかく。Microsoft.DirectX.Direct3D.Textureのコンストラクタでストリームから画像を読み込むと、とんでもなく時間がかかりませんか?

Device device;
Stream source;

this.texture = new Texture( device, source, Format.Unknown, Pool.Managed );

みたいな事をやると。いや勿論、いつでも遅いという訳では無いのです。ただ、これやると、デバッガでデバッグしようとすると破壊的に遅くなる。物的には何も破壊しないけれど、デバッグ付きで実行しようとする気を決定的なまでに殺いでくれる。このコンストラクタ一回呼び出しただけで数秒かかるんじゃやってられない。

コード見直すに当たって、これも解消できたらいいなあと思って代替手段を探していた時、そう言えばTextureLoaderっていうのもあったなあと思って、それっぽく書き直してみた。

Device device;
Stream source;

// 実際にはFilter.Linearが使えるかどうかCaps見てやんないと駄目だろうけど
this.texture = TextureLoader.FromStream( device, source, 0, 0, 1,
  Usage.None, Format.Unknown, Pool.Managed, Filter.Linear, Filter.Linear, 0 );

あっさり改善されました。

......。

ひょっとしてTextureコンストラクタってMicrosoftの罠?

TextureLoaderは名前空間こそDirect3Dだけど、Direct3DXのアセンブリに入ってるのでどれか一つ参照に追加しないとならない。まあ一番古いのを使えばいいか。

今度はMP3に浮気中。MP3って、Ogg VorbisやFLACみたいにリファレンスエンコーダ/デコーダが無かったから敬遠していたけど、MP3ファイルを一々WAVEやOgg Vorbisに直してから使うの面倒くさいなあ、と思い始めて、いっその事対応する予定と相成りました。問題はどのデコーダを使うか......。エンコーダならLAMEが有名らしい事は知ってるんだけど、デコーダは何が有名なのかな。mpg123? メモリ上のデータをデコードするmpg123_decodeの仕様は気に入らないけど、代わりにread/seekを置き換えるmpg123_replace_reader使えば何とか綺麗にできそうだ。