syghの新フラグメント置き場

プログラミングTipsやコード断片の保管場所です。お絵描きもときどき載せます。

Vulkan SDK付属のGLSLコンパイラー

2016年2月にVulkanの正式仕様とSDKがリリースされ、その後NVIDIAAMDなど大手GPUベンダー各社からもPC向け正式ドライバーがリリースされ始めているので、そろそろ試してみることにしました。まずはシェーダーのコンパイラーまわりから入ります。ちなみにVulkan仕様とSDKは、最初の正式リリース以降かなり頻繁にリビジョンアップが続けられています。

Vulkan用GLSLコンパイラ

Vulkan SDKにはGLSLをコンパイルしてSPIR-Vを出力することのできるオフラインコンパイラー「glslangValidator」が付属します。

32bit版 (x86) は下記にインストールされます(Windows環境)。

%VK_SDK_PATH%/Bin32/glslangValidator.exe

64bit版 (x64) は下記にインストールされます。

%VK_SDK_PATH%/Bin/glslangValidator.exe

Visual Studio (Visual C++) の[カスタム ビルド ツール]でプロジェクトのビルド時にGLSLソースファイルからSPIR-Vバイナリを生成するとき、たとえば下記のように[コマンド ライン]の項目を設定します。

"$(VK_SDK_PATH)\Bin32\glslangValidator.exe" -V "%(Identity)" -o "$(OutDir)VkShaders\%(Filename).spv"

[出力ファイル]には「$(OutDir)VkShaders\%(Filename).spv」を指定します。[説明]には適当に「Now compiling GLSL source file to SPIR-V...」などを指定します*1
例として "VkShaders" サブフォルダーを挟んでいますが、このフォルダーはVisual Studioが勝手に生成してくれます。

なお、glslangValidatorはBOM付きUTF-8を扱えないので注意。BOMなしのUTF-8もしくはASCIIを使う必要があります。

#includeディレクティブ

GLSLは標準で #include ディレクティブをサポートしませんが、Google拡張とARB拡張は存在する模様。

#extension GL_GOOGLE_include_directive : enable
#extension GL_ARB_shading_language_include: enable

しかしVulkan SDK 1.0.13.0付属のglslangValidatorでGoogle拡張を有効にしても、実際に #include を使えるようにはなりませんでした。ARB拡張に至っては有効にすることすらできない模様。これのどこがリファレンスコンパイラーなのか……

なお、Googleは「glslc」と呼ばれるシェーダーコンパイラーを開発して公開している模様です。SPIR-Vにも対応しているらしい。試してはいませんが、こちらは #include が使えるものと思われます。

ちなみにGoogleのGLSLコンパイラー実装では、

#extension GL_GOOGLE_cpp_style_line_directive : enable

のようにして拡張を有効にすると、

#line 1 "test.frag"

のように #line ディレクティブの第2引数にファイル番号の数値ではなく任意文字列を使えるようになるらしいです。この拡張機能はVulkan SDK 1.0.13.0付属のglslangValidatorでも使える模様。
もともと #line はGLSLコンパイル時にエラー/警告メッセージから問題発生個所を特定するなどの目的でプログラマーがファイル番号や行番号を明示的に制御するための機能で、OpenGLではコンパイル対象となる複数のGLSLソース文字列をオンメモリで結合するAPI (glShaderSource) が用意されている関係上、仕方なく存在しているような変な機能なんですが、せっかくオフラインコンパイラーがあるのにVulkan開発でも #line なんぞを明示的に使わないといけない時点でナンセンス極まりないです。

ちなみにDirectXのHLSLには #include が完備されている*2ので、#line を使う必要はありませんが、コンパイルエラー発生時のエラーメッセージは標準C/C++に比べるとやはり分かりづらいです。
なお、HLSLの #line はC/C++同様、第2引数にファイル名(文字列)を指定できるようになっています。さすがですね。

#versionディレクティブ

glslangValidatorで #version 400 - #version 450 を指定したシェーダーをコンパイルすると、下記のような警告が出ます。

Warning, version 450 is not yet complete; most version-specific features are present, but some are missing.

要するにまだGLSL 4.xすなわちOpenGL 4.xの相当機能を完全に実装しきれていないらしい。#version 330 であれば警告は出ません。しかしこれではOpenGL 4.xアプリケーションを満足に移植できない可能性があります。なんとも情けない……
OpenGL 4.0で標準化されたシェーダーサブルーチン(Direct3D 11でいう動的シェーダーリンク)など、本質的にVulkanの仕様と相反する機能であれば使うことができないのも分かりますが、Vulkanと互換性のあるGLSL機能までも実装しきれていないのはダメすぎかと。こんなていたらくではだれも移植を始めてくれないでしょ……

HLSL互換機能

ちなみにVulkan SDK 1.0.13.0付属のglslangValidatorでは、-D オプションを付けることで、なんとHLSLが使えるようになる模様。確かSDK 1.0.5.0では -D オプションはまだ存在していなかったように思われます。Vulkanが要求している入力はSPIR-V中間表現であり、GLSLはあくまでフロントエンドでしかないため、別にHLSLが使えても不思議ではありませんが、もし本当にHLSLが使えるのであれば、多くの機能面で劣るGLSLは要らない子ですね*3

たとえば下記のような最小のHLSLピクセルシェーダーは、普通にコンパイルが通ることを確認しました。Direct3D 10以降のシステム値セマンティクスも使えるようなので、おそらくシェーダーモデル4.0相当の機能は使えるものと思われます。Direct3D 11およびシェーダーモデル5.0に関しては未検証ですが、GLSL 4.xのサポートすらできていないことを考えると怪しいです。

float4 main() : SV_Target0
{
  return float4(0,0,0,0);
}

ただしソースファイルの拡張子は、GLSLと同様のルールに従う必要があります(*.vert, *.frag など)。
また、今のところ #include も使えない模様。結局ただの劣化移植です。本家である fxc.exe には及びません。

結論

総論としては、やはりVulkanはSDKやドライバーを含めてまだまだ未成熟な模様です。実績および開発のしやすさでは、Direct3D 11/12とHLSLに軍配が上がるのは火を見るより明らか。特にせっかくのオフラインシェーダーコンパイラーの実装が現時点で微妙すぎるので、OpenGLから移行する気がまったく起こりません。あとVulkan API自体がDirect3D 12以上にローレベルなので、プログラミングの難易度も相当に高いです。

とはいえ、OpenGLでないがしろにされてきたシェーダーのオフラインコンパイルや、マルチスレッド・マルチGPU対応などに真面目に取り組んでいるVulkan APIの姿勢というか設計思想自体は評価できるので、開発環境も含めて今後の発展と進化に期待したいところです。Vulkanを用いて、Direct3D 11やOpenGL 4に近いインターフェイスを持つ上位ラッパーレイヤーを構築してくれれば、Direct3D/OpenGLからの移植も進むんじゃないでしょうか。あとC++バインディングが欲しい……

*1:[説明]の既定値は「Performing Custom Build Tools」となっているはずです。ここで指定した文字列がビルド時に出力ウィンドウに出力されるだけなので、指定は任意です。[コマンド ライン]にてechoコマンドを使ってもよいのですが、[説明]を使ったほうが楽です。

*2:HLSLはGLSLと違って登場当初からベンダー非依存のバイトコードをサポートしており、オフラインコンパイルが基本ですが、D3DCompilerランタイムAPIを使って実行時にコンパイルする場合も、ID3DInclude を利用することで #include が使えます。

*3:コンピュートシェーダーに関しては例外で、エクステンションまで含めると実はGLSLのほうがポテンシャルが高いです。

INIファイルでUnicodeを扱う

今更ですが今日はINIファイルのお話です。初めに断っておきますが、ぶっちゃけWindowsアプリケーションでレガシーなINIファイルを使うのはもうやめましょうWindowsアプリケーション設定の管理には、今後はレジストリXMLファイルなどを使うべきです。

そもそもINIファイルとは?

INIファイルは昔からWindowsアプリケーションの設定管理に使われている簡易テキストフォーマットで、テキストエディターでも簡単に閲覧・編集することができるうえにXMLと比べて構造がシンプルなため、いまだによく使われていますが、その歴史はWin16時代にまでさかのぼります。自分はMS-DOSを少し使っていたことがあるものの、Win16を使ったことはありませんが、Windowsアプリケーションを開発していると、どうしてもINIファイルのようにWin16時代から引きずられてきた負の遺産に直面せざるを得ないことが多々あります。特にWin9x時代あるいはそれ以前に開発された昔のアプリケーションをメンテナンスする場合には、互換性維持のため泣く泣くINIファイルを使い続けないといけないこともあります。

INIファイルでは、具体的には下記のようにレコードを1行ずつ記録していきます。セクションやキーは複数含むことができますが、階層構造は扱えません。キーと値をつなぐ「=」の前後の空白は無視されます。

[SectionName]
KeyName=Value
; This is a comment.

コメントはセミコロン「;」で始め、改行で終わります。セミコロンではなく「#」をコメント開始記号に使っている人がときどきいますが、マイクロソフト仕様のINIファイルでは通用しないので注意しましょう。詳しくはWikipediaなどを参照してください。

Comments (any line that starts with a semicolon) are stripped out and not returned in the lpReturnedString buffer.

Win32 APIでINIファイルを扱う場合、下記のような関数を使います。

ほかにも、複数のレコードを一括して読み書きするGetPrivateProfileSection/WritePrivateProfileSectionや、バイナリデータを16進数表記文字列で扱うGetPrivateProfileStruct/WritePrivateProfileStructなどもありますが、たいていはXXXString関数で事足りるでしょう。これらのAPIは、一部の引数にNULLを指定すると挙動が変わるなどかなり高機能ですが、ややモノリシックな感は否めません。もし互換APIを自前で書こうとすると、存外にかなり大変だと思います。

なお、.NET FrameworkにはレガシーなINIファイルを扱うAPIは用意されていません。P/Invokeなどを利用して上記Win32 APIを使うか、自前でパーサーを書く必要があります。

INIファイルの欠点

INIファイルをWin32 APIで読み書きする場合、デフォルトではANSIマルチバイトエンコーディングが使われます。つまり、Windowsのシステムロケール設定(CP932/CP1252などのコードページ)に左右されることになります。例えば、日本語版WindowsではCP932 (Shift_JIS) が使われることになります。たとえUnicode対応のW系API関数(名前の末尾がWとなっている関数)を使って書き込んでも、ファイル出力する際にマルチバイト文字セット (MBCS) に強制変換されてしまいます。これは国際化対応が必要となるアプリケーションでは致命的な制約です。ANSIマルチバイトエンコーディングのテキストファイルでは、現在OSに設定されているシステムロケールに対応するANSIマルチバイト文字/文字列にマッピングできないようなUnicode文字/文字列を直接読み書きすることができないからです。セクション名・キー名はもちろん値の文字列もコメントもASCIIのみに限定する、あるいは読み書きの際に自前のエスケープやエンティティ参照・数値文字参照・パーセントエンコーディングを駆使する、という思い切った運用で回避するという方法もありますが……

しかし、実はUTF-16のBOMを持つテキストファイルをあらかじめ作成しておき、そのファイルに対して前述のWin32 APIでアクセスすると、UTF-16のINIファイルを直接扱うことができるようになります。このときW系関数を使えばUnicode文字/文字列を入出力できます。つまり、INIファイルでまともにUnicode文字/文字列を扱えるようになります。どうしてもINIファイルフォーマットを使い続けなければならない場合、UTF-16のINIは選択肢として検討してもよいでしょう。

そのほか、INIファイルでUTF-8エンコーディングを使う方法も一応あるのですが、これは制約の多い禁じ手です。説明と比較のため、UTF-16/UTF-8/ANSIのINIファイルをそれぞれ読み書きするC#サンプルプログラムを下記にアップロードしていますが、ANSI同様にUTF-8を使うのは避けたほうがよいでしょう。Win32 APIではなく自前でINIのパーサーを書くというのであれば、別にUTF-8を使ってもかまいませんが……

INIファイルの代替

INIファイルはすでに述べているようにレガシーな非推奨技術です。今後いきなりWin32 APIによるサポートが終了するといったことは考えられませんが、少なくとも積極的なサポートや技術革新はされないことくらいは肝に銘じておきましょう。
INIファイルの代替としては、レジストリXMLファイルがあります。

devblogs.microsoft.com

レジストリ

Windowsレジストリは大きく分けてシステムレジストリとユーザーレジストリの2つがあり、前者はオペレーティングシステム全体に影響を与えるため、書き換えには管理者権限(管理者特権)が必要となりますが、後者はWindowsログインユーザーごとにエントリが作成されるため、書き換えに特権は不要です。レジストリの実体は巨大なバイナリデータベースファイルの集合なので、バイナリデータも直接読み書きしやすいのが特徴です。文字列もUnicodeベースで標準的に管理されるため、INIファイルのような制限はありません。ただ、エンドユーザーがレジストリを編集するためには、起動に管理者特権が必要なレジストリエディター(regedit.exe)を使用しないといけないし、バックアップやレストアもファイルの単純コピーというわけにはいかないので、INIファイルほど気軽に扱えるものではないことは確かです。また、レジストリに依存してしまうと、Windows以外のプラットフォームにアプリケーションを移植する際にも問題となります。

XMLファイル

データ記述言語のデファクトスタンダードともいえるのがXMLです。XMLは主にWebで用いられることが多い技術ですが、MSXML/XmlLiteや.NET Framework/WinRTのようなマイクロソフト公式ライブラリによって標準サポートされているため、デスクトップアプリやUWPアプリでも扱いやすくなっています。Unicodeテキストの扱いも標準化されていますし、テキストフォーマットなので人間が直接編集するのにも困りません。バックアップやレストアもファイルの単純コピーで実施できるため、エンドユーザーにとっても扱いやすいです。欠点としてはXML自体がかなり巨大な仕様であるため、単純なアプリケーション設定を管理する方法としてはややオーバースペック気味であること、また特にDOMパーサーが重めであることが挙げられます。

汎用スクリプト言語/データ記述言語

そのほかの代替手段としては、Lua/Squirrel/Python/IronPythonといった汎用スクリプト言語や、JSONのようなデータ記述言語の処理系をアプリケーションに組み込んでしまうという方法も挙げられます。組み込みにはそれなりに手間がかかりますが、これらの言語は柔軟性が高く、スクリプト中で可変長配列データや改行を含むRaw文字列などを扱いやすいため、場合によってはINIやXMLよりも設定ファイルフォーマットとして適していることがあります。

※2021-08-15追記:
Windows 8以降のWinRTでは、Windows.Data.Jsonが利用できます。.NET FrameworkにはJSONのサポートがありませんが、.NET Coreでは3.0以降でSystem.Text.Jsonがサポートされています。

結論

繰り返しになりますが、INIファイルはもうやめましょう

あの、キョーマさん……?


【DimensionW】「あの、キョーマさん……?」イラスト/sygh[sai] [pixiv]

2016年に入ってもう2か月ほど経ちますが、ようやく今年初めての更新になります。「DimensionW」から、百合崎ミラちゃん。このくらいだったらR18タグ付ける必要はないかな……と。DimensionW面白いですね。OPはなんだコレ!?って感じなんですがEDと対になっていて、双方ともめちゃくちゃよく動きます。

今期は面白いアニメが多くて取捨選択に苦労しました。SFは基本観る人ですが、ゲームやライトノベルからアニメ化される作品よりもコミックからアニメ化される作品のほうが好きかもしれません。DimensionWは攻殻機動隊に通じるものがあり、情報化社会に一石を投じるテーマが主軸になっています。アニメ第4話と第5話は難解で、たぶん1回観ただけでは伏線を見逃してしまうと思います。そもそもお風呂シーン→異空間転送→タオル1枚で逃走→鎖で拘束、の流れがインパクトありすぎて話が頭に入ってこないのも一因なんですが……

ちなみにDimensionWではおそらくもうひとつの空間軸を百合崎博士が発見・Wと定義し、コイルによって空間をねじ曲げることで「可能性」という名のエネルギーを取り出すという設定なんだと思いますが、実は我々の世界はすでにX, Y, Zに時間軸tを含めた4次元空間であり、理系人間的には「第4の次元」というのは普通時間軸tを指します。実際「可能性」というのは時間にも深い関わりがあるので、SF的にもかなり興味深い設定だと思います。

自作MetasequoiaプラグインをGitHubで公開しました

かつて2007年~2008年頃、こっそり自分のためだけに開発したMetasequoiaプラグインソースコードがHDDの肥やしになっていたので、Gitの練習も兼ねてGitHubに移管・オープンソース化しました。ライセンスはMITです。

今回ソースコードを公開したのは下記のプラグインです。すべてUV編集関係のミニツールになります。

プラグイン 機能概要
SyghMQUV2SVG.dll UV展開図をSVGファイルとして出力
SyghMQUVBBox.dll UVを境界ボックスベースで数値入力変形
SyghMQUVImplant.dll UVをオブジェクト間で移植
SyghMQUVMatrix.dll UVをSRT行列ベースで数値入力変形
SyghMQUVSelectUtil.dll UV選択操作のユーティリティ

Metasequoia 3/4用のビルド済みバイナリ(32bit/64bit)は下記からダウンロードできます。ヘルプ・取説としてテキストファイルも同梱しています。
github.com

とはいえ、オリジナルはC++を使い始めてまだ2年かそこらのときに書いたコードであり、今改めて見直すとそれはもうひどい有様でとても人様に見せられるレベルではなかったので、Visual C++ 2013とMFCを使って最大限書き直しました。VC2015はCRTに致命的なバグを抱えているため*1、今回は見送っています*2。公開したソースコードはいずれも規模がとても小さいので、MFC標準DLLやC++11規格の入門としては良い教材になるかもしれません。MFC自体すでに枯れた技術で、真新しさや面白みはほとんどありませんが……

なお、今回の公開はあくまでソースコードの共有とメンテナンスが目的です。リポジトリのreadmeやWikiにも記載しているように、新機能の開発に関しては今後行なう予定はありません。理由は察してください。

Metasequoiaの今後

Metasequoiaに関しては3DCGを始めた学生の頃からお世話になっていました。直感的なモデリングに特化したツールで、比較的安価であるにもかかわらずプラグインによる拡張性が高く、果てはボーンやモーフによるアニメーションまでMetasequoia上で実現する強烈なプラグインKeynote」が出現したことにより、当時のホビーCG界隈は最高潮に達していたのではないでしょうか。現役ゲームデザイナーによるHow-to本も多数出版されていたと記憶しています*3。ただ、Metasequoia 4の開発ロードマップをめぐってその後Keynoteの開発者mqdl氏との軋轢が深まるなど、今は全体的に活気がなくなっているような印象を受けます。これまでユーザー開発者から提供・公開されていたおなじみのプラグインも、32bit版Metasequoiaでしか使えず、64bit版Metasequoiaに対応するためにはプラグインの64bit化が必要となるにもかかわらず、一向に64bit対応が進んでいないどころかMetasequoiaプラグイン開発自体が縮小傾向にあるように思えてなりません。かつてプラグインを公開していたサイトが閉鎖されてしまったケースも多々あります。
また、プラグインSDK配布ページに記載されている下記の1文が、さらにプラグイン開発者離れを加速させてしまっているように思います。

「作成したプラグインは自由に配布することができますが、Metasequoia本体 (Standard/EXなど全エディションを含む) に搭載された機能と競合することを目的とした等価なプラグインを作成して配布することを禁止します。」

ほかの3DCGソフトウェアと比べるのはどうかとも思うのですが、このように(たとえ機能が競合したとしても)プラグイン開発に制限を課したり禁止したりするなど聞いたことがありません。プラグインによるクラッキングなどの違法行為や特許侵害は論外ですが、正当な手段と目的で開発されたプラグインを、機能が競合するからといって排除しようとするなど愚の骨頂です。せめて適用対象をもっと明確にしていただきたいところですが、議論は一向に進んでいないようです。何が怖いかというと、せっかくオープンソース化したソフトウェアが鶴の一声で公開停止を余儀なくされるというのは個人的にも痛いし、またそれ以上にそういった理不尽であいまいな規制はソフトウェアの健全な発展に悪影響を及ぼすことが予想されるからです*4

Metasequoiaはその後もバージョンアップを重ね、レイトレーシングやボーン/モーフまでをも独自に実装するなど、これまでプラグインによって実現されてきた機能を着実にネイティブ実装しつつあるようですが、このまま行くとコミュニティ総体としては先細りになってしまうのではないかと危惧しています。すでに現在のMetasequoiaは、2010年頃までのメインユーザー層が想定していた方向性とは違う向きに舵を切りつつあるように思います。ユーザーが欲しがっている(ように見える)ものをただ与えることがクリエイターやエンジニアの仕事なわけではないことは確かですし、個性全開でがむしゃらに突っ走った結果が最終的にユーザーのニーズにマッチして成功するという例は往々にして存在しますが、あえて余計な機能の追加をすることなくシンプルであり続ける、そして足らないものはコミュニティに任せる、というのも一つの選択肢なのではないか、と自分は思います。

閑話休題。とりあえず自分は今後どうするのかというと、LightWaveを持っているんだからさっさと使いこなせるようにがんばります。Metasequoia向けに実装したこのプラグインも、せっかくなのでLightWaveプラグインとして実装し直してみようかと考えています。

*1:Visual Studio 2015 / 2017 で発生する可能性がある _snscanf_s 関数の問題について | Microsoft Docs

*2:VC2015で導入されたUniversal CRTにおけるバグが原因で、MFCDDXが正常に機能しません。Windows SDK 8.1を利用し、CRTをスタティックリンクするという条件の両方に該当する場合、VC2015以降は使わないほうがよいです。

*3:Keynoteでのアニメーションは、まるで日曜大工の道具で人が住む家を建てるようなものです。無償のプラグインに依存しすぎるということは、プラグイン開発者の気分次第で開発が停滞・終了したときに技術が廃れたり陳腐化したりする危険性もあり、できれば避けるべきバッドノウハウなのですが、使い慣れたツール上で制約を乗り越えながら別次元の高度な機能を実現すること自体は素晴らしいチャレンジだと思います。

*4:同様に、ソフトウェア特許というものに対しても自分は懐疑的というよりむしろ反対派です。かつて松下電器産業がアイコン特許(笑)を傘にジャストシステムワープロソフト「一太郎」を訴えた問題がありましたが、当時所属していた研究室の助教授は「松下はナンセンス極まりないね」と強く批判していました。

bashでGitのファイル名を一括置換

Git for Windowsインタラクティブシェル(コマンドラインインターフェイス)として付属するbashで、文字列置換を使ってgit mvを一括実行してみよう、という話です。

例えば

./Projects/MyClass1.cpp
./Projects/MyClass1.h
./Projects/MyClass2.cpp
./Projects/MyClass2.h
……

というように命名されたファイルがGit管理下に多数存在したとして、これらを

./Projects/MyInternalClass1.cpp
./Projects/MyInternalClass1.h
./Projects/MyInternalClass2.cpp
./Projects/MyInternalClass2.h
……

というように一括でリネームしたいとき、1つ1つgit mvしたり、TortoiseGitなどのGUIフロントエンドからいちいちファイル名を置換したりするのは気が遠くなるくらい退屈な作業です。

そういうときはbashでループを書きます。

for i in $(find . -iname "MyClass*"); do git mv "$i" "${i/MyClass/MyInternalClass}"; done

実行前に確認してみたいときはechoを入れてみます。

for i in $(find . -iname "MyClass*"); do echo git mv "$i" "${i/MyClass/MyInternalClass}"; done

さらに複雑な置換をするには正規表現を使うとよいでしょう。

Visual Studio 2015とD3DCompiler

Visual Studio 2015でビルドした、DirectX 11.1を使ったMFC/WPF混合アプリ (.NET 4.5.2) をWindows 7エクスプローラーから起動すると、起動直後に勝手に終了する現象が出ました*1
しかし、終了時にWindowsからクラッシュエラーのタスクダイアログも表示されないし、イベントログにも何も記録が残りません。
Windows 8.1では普通に起動します。また、Windows 7でも、Visual Studio 2015 IDEからデバッグ実行した場合は普通に起動します。

調査

まずPowerShell経由で起動して、終了コードを取得してみました。

$result = Start-Process -FilePath "<DX11AppName>.exe" -PassThru -Wait
Write-Host $result.ExitCode.ToString("X8")

結果は「C0000135」となりました。
調べてみると、どうもこのコードはWindows OSの場合「Unknown Hard Error」で、アプリケーションの場合「Unable To Locate Component」らしいです。

DLL依存関係が怪しいと感じたのでDependency Walkerで調べてみたところ、D3DCompiler_47.dll勝手にリンクされていました。

Windows 7の場合、Visual Studio 2012や2013/2015をインストールしても、System32やSysWOW64にはD3DCompiler_46.dllやD3DCompiler_47.dllはインストールされません。これらは「DirectXエンドユーザーランタイム」にも含まれていません。
Windows SDKDirectX SDKが統合されたWindows SDK 8.0以降では、D3DCompilerのランタイムは

%ProgramFiles(x86)%\Windows Kits\8.0\bin\x86
%ProgramFiles(x86)%\Windows Kits\8.0\bin\x64
%ProgramFiles(x86)%\Windows Kits\8.1\bin\x86
%ProgramFiles(x86)%\Windows Kits\8.1\bin\x64
%ProgramFiles(x86)%\Windows Kits\10\bin\x86
%ProgramFiles(x86)%\Windows Kits\10\bin\x64

といった場所にインストールされます。スタンドアロンのHLSLシェーダーコンパイラーであるfxc.exeと同じ場所です。ただし、ARM版やARM64版のDLLは存在しないようです。
Visual Studio IDEからの起動時には、この場所にパスを通すのでDLL解決できるんですが、エクスプローラーからの起動時にはDLL解決できなくて強制終了させられる模様。

Windows 8の場合、D3DCompiler_46.dllは標準コンポーネントとしてシステムフォルダーにインストールされていません。また、Windows 8のストアアプリでは、D3DCompilerの使用が認められていませんでした。
Windows 8.1の場合、Windows 8.1版のD3DCompiler_47.dllが標準インストールされています。
Windows 10の場合、Windows 10版のD3DCompiler_47.dllが標準インストールされています。
また、Windows 8.1ストアアプリおよびWindows 10ユニバーサルWindowsプラットフォーム (UWP) アプリでは、D3DCompilerの使用が認められるようになりました。
このため、Windows 8.1あるいはWindows 10でD3DCompiler_47.dllを利用する場合、デスクトップアプリでもストアアプリでも、同DLLをアプリに同梱する必要はありません。

ちなみに、Windows SDK 8.1に含まれるD3DCompiler_47.dllのバージョンは「6.3.9600.16384」です。
一方、Windows SDK 10 (10.0.10240.0) に含まれるD3DCompiler_47.dllのバージョンは「10.0.10240.16384」です。
ファイルサイズも異なるし、SDK 10版のほうはDirectX 12/11.3 API対応(シェーダーモデル5.1対応)が追加されているので、前方互換性はありません。さらに、システムフォルダーにインストールされているD3DCompiler_47.dllは、Windows Updateか何かで更新されているらしく、SDK同梱版とは末尾のパッチ番号(リビジョン番号)が微妙に異なるようです。ていうかこれまで通り新しいWindows 10バージョンではファイル名のナンバリングを更新しろよ……

結論

DirectX 11を使ったデスクトップアプリケーションをビルドし、Windows 7/Windows 8.x向けにも配布する場合、DLL依存関係には十分注意したほうがよさそうです。
D3DCompiler_47.dllをリンクした場合、Windows SDK 8.1/10に含まれる同DLLをアプリケーションに同梱する必要があります。D3DCompilerランタイムはレジストリ登録を必要とするCOMライブラリではなく、ただのC言語形式関数がエクスポートされているだけのDLLみたいです。つまりシステムに影響を与えることなく、アプリごとのプライベートアセンブリとして同梱できます。
もちろんDirectX 12/11.3はWindows 7/Windows 8.1にはバックポートされないので、当然それらの機能を使った場合はアウトですが、DirectX 11.1までの機能しか使わず、またD3DCompilerを明示的にリンクしない場合でも、VS2015ではD3DCompilerが勝手にリンクされることがある模様。かなり迷惑な仕様変更です。ちなみにx86/x64版のD3DCompiler (lib/dll) はSDKに同梱されていますが、ARM/ARM64版に関しては*.libのみで、*.dllは同梱されていません。

通例、アーリーバインドしたDLLの解決ができない場合は、アプリ起動時に「DLLが見つからない」という旨のエラーメッセージが出るはずなんですが、今回はメッセージが表示されることなく勝手に終了してしまい、イベントも記録されなかったこと、そしてWindows 8.1には同名のD3DCompiler_47.dllが存在し、エクスプローラーから実行してもDLL解決だけはできるようになっていたことが、エラー原因の発見の遅れにつながりました。

2018-02-07追記:
GitHubに登録する前の過去のソースコード履歴を調べてみたところ、開発環境をちょうどVS2013からVS2015に更新する少し前に、D3DCompilerを使ってシェーダーリフレクション機能をテストするコードを書いていたんですが、その際にd3dcompiler.libを明示的にリンクしており、テストが終わってもそのまま無効化するのを忘れていたことが原因だったようです。少なくともVS2015の仕様変更ではなかった模様。お騒がせしました。普段からD3DXやD3DCompilerを使わないように注意していたんですが……
なお、.NET 4.7ではWPFがD3DCompiler_47.dllに依存するようになったらしく、Windows 7の場合は.NET 4.7本体をインストールする前に、KB4019990をインストールしておくか、最新のWindows Updateを適用しておく必要があるようです。依存コンポーネントがあるならば.NETのインストーラーが自動でインストールするべきだと思うんですが。また、.NET 4.7のWPFには潜在的な不具合が多々あるようです。.NET 4.7.1で問題が解消されているかどうかは不明です。

*1:Windows 7 SP1はIE10/IE11などと同時にインストールされるPlatform UpdateプログラムKB2670838を適用することで、DirectX 11.1 APIを使用できるようになります。

XAudio2とMedia FoundationでMP3/WMA再生

経緯

以前、DirectXの学習を兼ねて開発していたゲームエンジンC++で様々なDirectX APIを直接叩いていました)では、効果音 (SE) の再生にXACT3を、BGMの再生にDirectShowを使っていました。本当はBGMにもXACT3を使ってもよかったのですが、MP3/WMAフォーマットの音楽ファイルを直接ストリーム再生したかったのでDirectShowを使っていました。ちなみにMIDIを扱っていた頃は、SE/BGMともに知る人ぞ知る太古のAPI、DirectMusicを使っていました*1

ですが、Windows 8で導入されたWindowsストアアプリ(のちのWindows 10におけるユニバーサルWindowsプラットフォームアプリ)ではXACT3もDirectShowも使えなくなりました。デスクトップアプリではともに一応使えますが、Windows SDK 8.0以降ではXACT3は廃止されてしまっています。

Microsoftが推奨している新しいオーディオ系の代替APIはいくつかあります。これらはデスクトップアプリでもWindowsストアアプリでもほぼ同様に使えます。一部はXboxとも共通のAPIとなっています。

  • Windows Core Audio (Windows Vista以降における新しいオーディオ基盤)
  • XAudio2 (DirectSoundの後継)
  • Media Foundation (DirectShowの後継)

Core AudioにはWASAPIと呼ばれる、高音質な排他モードをサポートするライブラリも含まれています。しかしゲームエンジンに使うのであれば、同時発音の処理は必須であり、たとえ音質を犠牲にしてもミキシング機能をとる必要があるため、結局XAudio2を使わざるを得ないようです。

最初に候補として検討したのは「DirectX Tool Kit (DirectXTK, DXTK) for Audio」です。DXTK AudioはXAudio2を使ったXNAライクの簡易音声再生補助ライブラリなのですが、どうもこのライブラリはWAVフォーマット (RIFF) にしか対応していないようです。DXTK AudioはまたWaveBank (xwb) にも対応しているのですが、XACT3やXNAで使用可能だったXMA/xWMA圧縮フォーマットには対応していません。つまりXACT3/XNA時代の資産はほとんど使えないといっても過言ではないでしょう。尺が比較的短いSEの再生には使えますが、BGMの再生となるとやや微妙です。また、ポーリングベースではなくイベントベースで実装されていることにも注意が必要です。

XAudio2は、実はWMA (xWMA) 圧縮フォーマットのオーディオデータをデコードする機能を標準で備えているようです。旧DirectX SDK June 2010に付属するxWMAEncode.exeなどを使えば、ゲーム用途におけるBGMファイルのサイズ問題は一応クリアできるでしょう。ただし、Windows 8.xに標準搭載されているXAudio2 v2.8では、xWMAはサポートされていません。Windows 10に標準搭載されているXAudio2 v2.9では、xWMAのサポートが復活しているようですが、xWMAを使い続けるのはどうも微妙な感じがします。

Media Foundation

かつてのDirectShowのように、MP3/WMAフォーマットのメディアファイルを直接ストリーム再生できるようにするには、それらのフォーマットに対応したデコーダーが必要となります。そこで出番となるのが、Media Foundation。やはりDirectShowの後継だけあって、MFが出てくるのは必然ともいえます。

MSDN Magazineに、WindowsストアアプリでXAudio2とMedia Foundationを使ってストリーム再生をするサンプル(C++/CX)が掲載されていました。

ただしこのMSDNサンプルは、オーディオプレイヤーの3大必須機能(Play/Pause/Stop)を実装していないうえにメモリやリソースの寿命管理がgdgdで、とても流用できるような類のものではありません。
まずデスクトップアプリ向けに書き直し、その後で改めてストアアプリ向けに再移植してみました。

サンプルコードは下記2つのソリューション&プロジェクトを含んでいます。DXTK (2015-08-18版) も比較を兼ねてお試しで使っているので、それぞれの環境に合わせたビルドが必要になります。

  1. MFCベースのデスクトップアプリ。ビルドにはVisual Studio 2015 Pro/Community以上が必要。
  2. Windows 8.1用のストアアプリ。ビルドにはVisual Studio 2013 Pro/Community以上が必要。

https://sygh-jp.github.io/content_hosting/my_program_ss/MyMfcDXTKAudioTest1_ss_2015_09_23a.png
https://sygh-jp.github.io/content_hosting/my_program_ss/MyWin81DXTKAudioTest1_ss_2015_09_23a.png

Windows 8.1ストアアプリではなく、Windows 10向けのUWPアプリにしてもよかったんですが、まだまともなWindows 10開発環境を準備できていないので今回はあきらめました。フルスクリーンだと上下左右の余白が寂しい感じです。
デスクトップ版はWindows SDK 10を使っていますが、ターゲット環境をWindows 10に設定していないため、XAudio2 v2.9 (XAudio2_9.dll) ではなくv2.8 (XAudio2_8.dll) がリンクされます。Windows 7あるいはそれ以前のWindowsで動かすためには、旧DirectX SDK June 2010を使ってビルドし、XAudio2 v2.7 (XAudio2_7.dll) をリンクする必要があります。
※2016-03-17追記:
SharpDX 3.0.2を使ったWPFサンプルも追加しました。XAudio2 v2.7が使われるため、DirectX SDK June 2010もしくはエンドユーザーランタイムを導入すればWindows 7でも実行できます。今回はC++版のクラス設計をほぼそのまま移植しているため、一部C#らしくないコードになっていますが意図的なものです。
※2018-02-26追記:
Windows 10向けUWPアプリのサンプル (VS2015) も追加しました。Windows 8.1ストアアプリとほぼ同じです。

なお音声サンプルとして、「魔王魂」さんからダウンロードさせていただいたフリー素材を使用しています。音声ファイルの利用は下記サイトの利用規約に従ってください。

コードの二次利用は自由ですが、自己責任でお願いします。仮に損害が発生したとしても、当方は一切の責任を負いません。
なお、とるに足らないテスト用アプリではありますが、コレをこのままストアに提出することは絶対にやめてください。コレはあくまでサンプルコードです。そのまま提出してもたぶん審査で落ちるだけだと思いますが、もしコレをベースにして似たようなアプリを作成する場合、必ず何らかの独自機能をきちんと付加した上で、Package.appxmanifestのPublisherとPublisherDisplayNameをきちんと更新してください。この約束が守られていないアプリを発見した場合、しかるべきところに通報させていただきます。

C++/CX

簡単のため、ストアアプリ版のコードではMVVMは使っていません。MFC同様にコードビハインドを書いているだけなので、対比は楽だと思います。そのほか、ストアアプリ版はバックグラウンド再生にも対応させていないので、アプリが非アクティブになると再生が一時停止します。
しかし久しぶりにC++/CXを使ったんですが、PPL(特に例外処理)がめんどくさすぎて途中死にそうになりました。C++/CX版PPL (WinRT版PPL) は通常のC++版PPL (デスクトップ版PPL) と違って、C#のasync/awaitのようにタスク完了時に呼び出し元スレッドへのコンテキストの復帰を行なってくれるんですが、例外処理はどのみち煩雑すぎです。タスクチェーンの仕組みもよく考えられているとは思うんですが、やはり記述性や可読性の向上のためにresumable/awaitが欲しいところです。Visual C++ November 2013 CTPやVisual Studio 2015では実験的にresumable/awaitが実装されていますが、/awaitコンパイルオプション(/sdlや/RTCと共存できない*2*3)を明示的に指定する必要があったりして、まだ完成にはほど遠いようです。また、C#のasync/awaitとは違い、GUIアプリケーションのイベントハンドラーを気軽に(同期的に)書けるようになるという類のものではありません。やはりGUIフロントエンドはC#で記述するのが今のところベストだと思います。

ちなみにSharpDXにもXAudio2とMedia Foundationのローレベルなラッパーがあるのですが、リソース寿命管理や例外処理のことを考えると、世代別GCベースのC#から参照カウントベースのCOMコンポーネントを使うのはかなりしんどいです。Javaと違ってC#はある程度ローレベルな記述も可能な言語ではありますが、COMに関してはやはりC++のほうが親和性が高いです。DirectX全般にも該当しますが、もしC#でCOMコンポーネントを扱いたい場合、C++/CLIC++/CXでラップして、独自の上位レベルI/Fを公開するライブラリを作成したほうがかえって効率的だと思います。

*1:単純に音楽ファイルを再生するだけであれば、WinMMやMCI (Media Control Interface) 関数、WMP (Windows Media Player) コンポーネント、あるいはWPF/WinRTのような上位レベルAPIを利用するのが簡単なのですが、ゲーム開発で利用するとなるとパフォーマンス上の理由からDirectXファミリー一択になります。

*2:/sdlに関してはVisual Studio 2015 Update 2で改善されたようです。Visual Studio 2015 Update 2 | Microsoft Docs

*3:/RTCに関してはVisual Studio 2017で改善されたようです。Visual Studio 2017 15.0 リリース ノート | Microsoft Docs