連載 .NET&Windows Vistaへ広がるDirectXの世界 第1回 DirectXの真実 NyaRuRu2006/06/21 |
|
Windows Vistaの発売(2007年1月発売予定)が近づいてくるに伴い、同OSの新しいグラフィックス環境について一般利用者向けの記事もいくつか散見されるようになった。
それらの記事でたびたび目に付くのが、「Windows Vistaの描画は、DirectXをベースとしているので高速になる」という説明だ。確かにこの説明は、宣伝文句としてはインパクトがあるかもしれない。だが、もしあなたが開発者であれば、このような説明に納得すべきではない。DirectXは決して「定義上高速」なのではなく、特定のシナリオで性能を発揮するようにデザインされたライブラリにすぎないからだ。
この事実は、ゲーム開発者にはよく知られた話であるが、一般的なWindowsアプリケーションの開発者などにはあまり知られているとはいえない。実際にWindowsアプリケーション開発者の間で、DirectXに対する過剰な期待や楽観的な思い込みがしばしば見受けられるのが現状だ。
そこで本連載では、このように誤解の多い次世代のDirectXの真実を、Windowsアプリケーション開発者をターゲットに解説する。今回は3D描画APIとしてのDirectXの説明が中心となるが、本連載では次世代Windowsシステム上で動作するアプリケーションを構築するうえでぜひ知っておきたい「DirectXの世界」を紹介していく予定だ。また、C#やVBを使った具体的なDirectXプログラミングなどについても次回以降で解説していくつもりだ。
1. DirectXとは?
DirectXを知る前に、まずはこれまでのWindowsグラフィックスの歴史を簡単に振り返っておくことにしよう。
■Windowsグラフィックスの歴史
Windows OSの登場により、PCで一般的に利用されるOSは文字ベースのMS-DOSからグラフィカルなユーザー・インターフェイスを持つWindowsへ転換し、PCのグラフィックス環境は大きく変化した。これに伴い、画面の高解像度化や発色数の向上といった進化、ベクトル・フォントの使用などの先進機能がWindows OSに備わったわけだが、これは同時にハードウェア(特にビデオ・カード)性能への要求までも高めてしまった。
この当時は、ビデオ・カードの描画性能がPC使用時の快適さに直結していた時代である。まさに「快適にPCを使うため」という理由で、人々はビデオ・カード性能に大きな関心を寄せた。市場もそれに呼応して、「グラフィックス・アクセラレータ・カード」と呼ばれる製品が各社から発売され、描画性能や画質面で激しい競争が行われた。また単にハードウェアの性能だけでなく、ドライバの性能によっても描画性能が大きく異なり得るということが知られるようになると、ドライバ開発力が高いとされたメーカーに人気が集まるという現象も見られた。
一般的なWindowsアプリケーションについて見ると、Windowsの描画機能はGDI(Graphic Device Interface)と呼ばれる汎用的なAPI群を介して提供される。そして、このような形態が16 bits Windows時代から現在まで続いている。GDIはその後も幾度かAPIの追加や内部実装の改良が行われたものの、その基本設計は大きく変更されることなく10年以上の長きにわたりWindowsのデスクトップ描画を支えてきた。
一方、一般的なPCでの利用OSがほぼWindows一色となってくると、PCゲームのプラットフォームとしての役割もWindowsに求められるようになってきた。まずWindows 3.1時代にWinGという描画APIが登場する。これはメモリ上に構築した画像データを効率よく画面に表示するための仕組みで、あまり広くは普及しなかったものの、Windows 95以降のCreateDIBSection API*1などにその思想は受け継がれた。
*1 DIB(Device Independent Bitmap)を作成するためのAPI。DIBとはデバイスに依存しないフォーマットのビットマップ画像データのことで、Windowsのビットマップ描画処理ではこのDIBが標準的に利用されている。 |
そして1995年、Windows 95用にWindows Game SDKとして登場したのが、後にいうDirectX 1であった。
DirectX 1に含まれるDirectDrawは、ゲームを強く意識した機能を持つAPIセットだ。DirectDrawはMS-DOSベースのゲーム開発者をWindowsの世界に引き込むべく、GDIをバイパスしたハードウェアによる画像の矩形転送やパレット管理、フルスクリーン・モードによるモニタへの直接出力やモニタの垂直回帰中に完了する高速な画面切り替えをハードウェア非依存という形で再構築したものといえる。
従来のAPIと異なり、DirectXにはCOM(Component Object Model)の思想に基づいたバージョン管理が行われるという特徴がある。このことが後の頻繁なDirectXのAPIセットの更新を可能にした最大の要因といえるだろう。
そして翌1996年にはDirectX 2が登場する。これには、3D描画をサポートするDirect3Dと、3次元空間上のオブジェクト操作のためのフレームワークに相当するDirect3DRMが含まれていた。
その後、時代はコンシューマ・ゲーム機を巻き込んだ3Dゲーム・ブームに突入し、PC環境もこれに合わせて新しいバージョンのDirectXと新しいビデオ・カードが毎年のように登場した。それに伴いDirectXの主役もDirectDrawからDirect3Dに移っていく。2000年に登場したDirectX 8に搭載されたDirectX Graphicsは、「DirectDrawとDirect3Dの統合」といううたい文句とは裏腹に、3D描画APIによる描画機能を再構築したものであり、これは事実上DirectDrawの終わりを意味した。
また当初Windows 9xのみであったDirectXのサポートだが、Windows NT 4.0からはWindows NT系でもサポートが始まった。Windows NT 4.0でGDI*2とUSER*3の実装の多くが(ユーザー・モードから)カーネル・モードに移されたことには賛否両論あったが、DirectXのサポートを考えるとやはり必要な決断であったといえるかもしれない。
*2 Windowsの描画機能を提供するAPI群は、GDI関連の.DLLファイルに実装されている。 |
*3 ウィンドウやボタンなどのユーザー・インターフェイス機能を提供するAPI群は、USER関連の.DLLファイルに実装されている。 |
そしてWindows 2000以降、デスクトップ描画にも半透明効果が用いられるようになってくると、GDIの設計の古さは大きな問題となってきた。マイクロソフトはWindows 2000でGDIにアルファ・ブレンド描画を含むいくつかのAPIを追加し、レイヤ・ウィンドウと呼ばれる透過ウィンドウの仕組みをデスクトップ・ウィンドウ・マネージャに追加した。しかし近年になって3Dハードウェアに搭載された機能の多くは、はるか以前に設計されたGDIとは設計思想から異なるものであったため、GDIの機能を大幅に拡張することはできなかったのだ。
また同時期にGDI+と呼ばれる新しい描画ライブラリも公開されたが、当初提供されるといわれていたGDI+向けハードウェア・アクセラレーションはいまだに登場しておらず、依然としてGDI+はGDIをラップするソフトウェア・レンダラにとどまっている。
.NET Frameworkは描画ライブラリとしてGDI+のマネージ・ラッパーを標準に選んだため、Win32ウィンドウのラッパーである.NETのWindowsフォームもGDI+に強く依存することとなった。
このようなWindowsグラフィックスの状況は、Windows Vistaの登場により大きく状況が変化するだろう。VistaではDirectX 9レベルのハードウェア・アクセラレーションを活用した2つの新技術が投入される。
1つは、Windows Vistaに標準搭載される.NET Framework 3.0であり、これに含まれる「Windows Presentation Foundations」(以下WPF)がDirectXアクセラレーションを利用する。WPFは従来のWin32ウィンドウ・システムをトップレベル・ウィンドウにのみ使用し、それ以下の描画要素についてのメッセージングや描画処理はすべて自前で処理を行うプロセス・レベルのウィンドウ・システムであるが、この描画処理が「Media Integration Layer」(以下MIL)と呼ばれるアンマネージ・レイヤーを通してDirectX 9 API呼び出しに変換されている。また.NET Framework 3.0はWindows XP SP2へのバック・ポートが表明されており、現在公開されているWindows XP向けのベータ版では、すでにDirectX 9を使用した描画が実現されている。Windows Vista環境とWindows XP環境の違いとしては、Vistaに搭載されるDirectX 9.Lと呼ばれるDirectX 9の拡張版の存在があり、ClearType描画に特化したハードウェア・アクセラレーションや、プロセス間でのリソース共有による省メモリ効果は、Windows Vista Display Driver Model(以下WDDM、以前はLonghorn Display Driver ModelまたはLDDMと呼ばれていた)に対応した3Dハードウェアを搭載するWindows Vista環境でのみ実現されるものと予想される。
もう1つのVistaの新技術は「Desktop Window Manager」(以下DWM)で、GDIを利用した従来のアプリケーション描画をオフ・スクリーン画面にリダイレクトし、デスクトップ上のウィンドウ合成にDirectX技術を使用するというものだ*4。実際にはこのDWMの描画処理も前述のMILを通じて実現されている。また、Windows Aero*5の特徴でもあるガラス風のビジュアル・エフェクトもDWMによって実現されており、Win32 APIに新しく追加されるDWM APIによって制御される。MILをWPFの一部と見る立場では「DWMはWPF(の下位レイヤーであるMIL)を使用する」と表現されることがあるが、この場合.NET Frameworkで実装されたWPFのマネージ・ライブラリ層をDWMは必要としていないことに注意が必要である。
*4 実際にリダイレクト処理がどのように行われるかについては、Greg Schechter氏のBlog「Redirecting GDI, DirectX, and WPF applications」に詳しい。 |
*5 Windows AeroとはWindows Vistaに搭載される新しいユーザー・インターフェイスのことで、ウィンドウを半透明にすることで背景が透けて見えるようにした(いわば「ガラス風」の)視覚効果を採用している。 ※Windows Aeroの実行イメージについては、「@IT NewsInsight:MSが『Windows Vista』公開、『3DのUIで生産性が向上』」を参照されたい。 |
Windows Vistaでは、このように、クライアント領域の新しい描画モデルとしてのWPFと、従来のアプリケーションにも適応可能な新しいウィンドウ合成を可能にするDWMという2つの技術によってDirectX 9によるハードウェア・アクセラレーションの適用範囲が広がることとなる。さらにWDDMに対応した最近のハードウェアでは、MILを通じて自動的にDirectX 9.Lによるアクセラレーションが活用されるのだ。
■DirectXを使う理由、必要な場面
WindowsゲームのほとんどがDirectXを使用していることからも分かるように、ハイパフォーマンスを要求されるマルチメディア・アプリケーションにはDirectXが向いている。これらのアプリケーションではハードウェアの性能を効率よく引き出すことが必要だからだ。
このような視点で見ると、DirectXはライブラリ内でのパフォーマンス・ロスが極力生まれないよう、ハードウェアの薄いラッパーとして設計されていることが分かる。最大限の最適化を望む場合は、Win32の描画APIよりもDirectXの方が優れた解となるだろう。なお最近では、ゲーム以外でのDirectXの利用も広がっており、実際GoogleのPicasa2やGoogle Earthなどの例を挙げることができる。
またWin32 APIがOSのライフサイクルで変化していくAPIセットであるのに対し、DirectXはハードウェアの世代と同期したAPIセットであるといえる。先ほども述べたが、DirectXはCOMを用いたことで、旧バージョンのAPIセットを残したまま新しいAPIセットを提供できた。通常、新しいDirectXは最新のWindows OSだけでなくこれまでにリリースされた大半にインストールが可能であり、実際この意味ではOSごとに機能が細かく異なるWin32 APIに比べ、DirectXを用いた方がOS間の差異が少ないとさえいえる。
ゲーム開発では、しばしばDirectX上に適切なフレームワークを構築し、ゲーム本体はフレームワークに依存する3階層アーキテクチャがよく用いられる。フレームワーク層でDirectXとハードウェアの可変性を吸収することで、ハードウェアの効率的な利用とプログラム資産の再利用性の間のバランスを取るわけである。
ある特定ハードウェアを駆使するアプリケーションを長期間リリースし続ける場面では、ハードウェアの進化という可変性は必ずどこかで受け止めなければならない。その意味でフレームワークのサブシステムとしてDirectXを選択するメリットは大きいだろう。
INDEX | ||
.NET&Windows Vistaへ広がるDirectXの世界 | ||
第1回 DirectXの真実 | ||
1.DirectXとは? | ||
2.高速描画の裏事情(1) | ||
3.高速描画の裏事情(2) | ||
「.NET&Windows Vistaへ広がるDirectXの世界」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|