DirectX に関してよくあるご質問

そして、 x64 技術は市場で広く利用されています。 過去数年間に販売された新しい CPU の大部分と、AMD と Intel から開発されているほぼすべてのプロセッサ ラインは x64 対応です。 Windows XP Professional x64 Edition では、2005 年 4 月にリリースされた x64 の OS 対応テクノロジが導入されました。 x64 エディションでは、新しい世代の 64 ビット ネイティブ ドライバーが必要であるため、この最初のリリースは OEM 配布に限定されていました。

Windows Vista では、Windows ベースのコンピューターを購入するときに 32 ビット版または 64 ビット 版を自由に選択でき、Windows Vista のライセンスは OS の 32 ビット版と 64 ビット 版の両方で有効です。 さらに、多くの 64 ビット ドライバーが用意されており、デバイスの製造元は、Windows 認定プログラムの一部として 32 ビットと 64 ビットの両方のネイティブ ドライバーを提供する必要があります。

これらの要因はすべて、64 ビット エディションの Windows の展開を大幅に増やす要因となります。 新しいコンピューターが 2 GB を超える物理 RAM で出荷を開始すると、32 ビット オペレーティング システムを使用するインセンティブが大幅に減少し、64 ビット エディションが優先されます。 64 ビット テクノロジでは 32 ビット ネイティブ コードが完全にサポートされていますが、新しい 64 ビット メモリ領域を最大限に活用するには 64 ビット ネイティブの実装が必要です。 すべての 32 ビット アプリケーションには、最小出荷要件として 64 ビット互換性が必要であり、その要件を満たすことが Windows Vista 互換性のベースライン要件です。 非互換性は、通常、Windows 3.1 オペレーティング システム用に設計された 16 ビット コードを使用するか、32 ビットと 64 ビットの両方のネイティブ フォームで提供されていないドライバーをインストールすることによって発生します。

64 ビット テクノロジの詳細については、「ゲーム開発者向けの 64 ビット プログラミング」を参照してください。

パフォーマンスと機能セットの 2 つの理由ではもう気にする必要はありません。

ゲームに必要な最小 CPU 速度が 1.2 GHz 以上 (ハイ パフォーマンス タイトルの場合は一般的) の場合、対象となるコンピューターの大部分は Windows XP を実行します。 CPU 速度が 1.2 GHz を超えるコンピューターが販売されるまでに、Windows XP はほぼすべての製造元によって既定のオペレーティング システムとしてインストールされていました。 つまり、Windows XP には、今日のゲーム開発者が次のような機能を利用する必要がある多くの機能があります:

• マルチタスクの改善 - ビデオ、オーディオ、ゲームのエクスペリエンスが向上し、スムーズになります。
• より安定したビデオ ドライバー モデル - デバッグが容易になり、ゲームプレイがスムーズになり、パフォーマンスが向上します。
• ネットワークの構成が容易で、マルチプレーヤー ゲームに簡単にアクセスできます。
• ハード ドライブからの DMA 転送が既定でサポートされています。その結果、アプリケーションの読み込みがスムーズになり、読み込みが高速化されます。
• Windows エラー報告 - OS、ドライバー、アプリケーションの安定性が向上します。
• Unicode のサポート - ローカライズの問題を大幅に簡略化します。
• セキュリティと安定性が向上し、コンシューマー エクスペリエンスが向上します。
• 最新のハードウェアのサポートが強化されました。そのほとんどで Windows 98 ドライバーが使用されなくなりました。
• メモリ管理が改善されました。その結果、安定性とセキュリティが向上します。
• NTFS ファイル システムが改善されました。障害耐性が高く、セキュリティ機能を使用してパフォーマンスが向上します。

もう心配ありません。 ｢ゲーム開発者は引き続き Windows 95、Windows 98、または Windows ME 用のゲームを公開する必要がありますか?」に記載されている理由に加えて、Windows 2000 には次の機能はありません:

• Windows XP では、ハイパースレッド、マルチコア、x64 などの高度なプロセッサ機能がサポートされています。
• Windows XP では、アプリケーションのバージョン管理の競合を大幅に軽減するサイド バイ サイド コンポーネントがサポートされています。
• Windows XP では、悪意のあるプログラムを防ぎ、デバッグを支援する、実行不要のメモリ保護がサポートされています。
• Windows XP では、高度な AGP および PCI Express ベースのビデオ カードのサポートが強化されました。
• Windows XP では、高速ユーザー切り替え、リモート デスクトップ、リモート アシスタンスがサポートされており、製品サポート コストの削減に役立ちます。
• (DirectX Developer SDK の) PIX などのパフォーマンス ツールでは、Windows 2000 はサポートされなくなりました。

つまり、Windows 2000 はコンシューマー オペレーティング システムとして設計または販売されることはありませんでした。

Windows Vista ファミリには、次の 5 つのエディションが含まれています:

• Windows Vista Home Basic
• Windows Vista Home Premium
• Windows Vista Business
• Windows Vista Enterprise
• Windows Vista Ultimate

Home Basic と Home Premium はコンシューマー向けのバージョンで、Family Safety (旧称: 保護者による制限) などの機能を備え、Home Premium にはメディア センターが含まれています。 Business と Enterprise は、ドメイン参加やリモート デスクトップ/ターミナル サービスなどの機能を備えた、企業に重点を置いたエディションです。 Ultimate エディションは、コンシューマー エディションと企業エディションの両方のすべての機能を 1 つのバージョンに結合します。 すべてのエディションは 32 ビット (x86) と 64 ビット (x64) の両方のエディションで提供され、ユーザーは両方のプラットフォームで同じ商品 ID を自由に使用できます。

各エディションの基盤になるテクノロジは同じであり、DirectX ランタイムやその他のコンポーネントのバージョンもすべて同じです。 ただし、エディションにはゲームに関して若干の違いがあります:

• ゲーム エクスプローラーはすべてのエディションに存在しますが、[スタート] メニューの [ゲーム] ショートカットは Home Basic、Home Premium、Ultimate でのみ使用できます。 ゲーム エクスプローラーは、すべてのエディションで引き続きあります ([スタート] をクリックし、[すべてのプログラム] をポイントし、[ゲーム] をクリックします)、および IGame エクスプローラー インターフェイスは、すべてのエディションで機能します。
• Windows に含まれるゲームは、Business および Enterprise では既定では使用できませんが、管理者が有効にすることはできます。
• Family Safety とゲームのレーティングは、ビジネスやエンタープライズの動作に対して表示または影響を与えるものではありません。また、ドメインに参加している場合 Ultimate では無効になります。

ユーザー アカウント制御の設定は、すべてのエディションで同じ既定値になりますが、Business、Enterprise、Ultimate のドメインのグループ ポリシー設定によってオーバーライドできます。 たとえば、ポリシー設定のユーザー アカウント制御: 標準ユーザーに対する昇格プロンプトの動作は、セキュリティを強化するために多くのビジネス設定で [昇格要求を自動的に拒否する] ように設定することもできます。また、そのような環境では、多くのユーザーは常に標準ユーザーとして実行され、管理者として実行することさえ選択できません。 従来のセットアップの検出または要求された実行レベルを "requireAdministrator" として指定するマニフェストを持つことにより、管理者権限を必要とするプログラム (インストーラーなど) は、このような状況では常に起動に失敗します。 その他のポリシー設定 (ユーザー アカウント制御など): Authenticode を使用して実行可能ファイルに署名しない場合、署名および検証された実行可能ファイルのみを昇格させ、インストーラーが機能しないようにすることもできます。

これらの種類のポリシー変更は、Windows Vista の任意のエディションに適用できますが、ドメインに参加しているコンピューターで適用される可能性が高くなります。

Window 7 ユーザーのほとんどには、ホーム ユーザー向け Windows 7 Home Premium、またはビジネス ユーザーと開発者向けの Windows 7 Professional の 2 つのエディションのいずれかが含まれる可能性があります。 大企業の場合、ボリューム ライセンスの Windows 7 Enterprise エディションがあり、Windows 7 のすべての機能が含まれています。Windows 7 Ultimate は、そのエディションと同等の製品版です。

Windows 7 Starter Edition は、世界中の OEM で利用でき、ネットブック、超低電力ノートブック コンピューターと共に展開される予定です。 Windows 7 Home Basic は、新興市場でのみ使用できます。

Windows 7 のすべてのエディション (Starter Edition を除く) は 32 ビット (x86) と 64 ビット (x64) の両方のバージョンで使用でき、Windows 7 のすべてのリテール パッケージには両方のバージョンのメディアが含まれています。 Windows Vista と同様に、ユーザーはどちらのプラットフォームでも同じ製品識別子を自由に使用できます。

さまざまなエディションの基になるテクノロジは同じであり、すべてのエディションに同じバージョンの DirectX ランタイムとその他のコンポーネントがあります。 ゲーム機能に関していくつかの違いがあります:

• ゲーム エクスプローラーはすべてのエディションに存在しますが、[スタート] メニューの [ゲーム] ショートカットは Windows 7 Professional および Enterprise では既定では非表示になっています。 [スタート] メニューには [ゲーム エクスプローラー] が引き続き表示され ([すべてのプログラム] をクリックしてから [ゲーム] をダブルクリック)、ゲームの直接ショートカットをユーザーが有効にすることができます。
• Windows に含まれるゲームは、Windows 7 Professional および Enterprise では既定では使用できませんが、管理者が有効にすることはできます。
• Family Safety とゲームのレーティングはすべてのエディションで利用できますが、オペレーティング システムがドメインに参加すると、Windows 7 Professional、Enterprise、Ultimate では無効になります。 Windows Vista Ultimate と同様に、ドメインに参加しているコンピューターでこの機能を再び有効にすることができます。

ユーザー アカウント制御 (UAC) 設定は、Windows Vista と同様に、Windows 7 Professional、Enterprise、Ultimate エディションのグループ ポリシー設定の影響を受ける可能性があります。 詳細については、「Windows Vista のさまざまなエディションの違いについて」を参照してください。DirectX アプリケーションに与える影響

不正解です。 DirectX 10 を搭載した Windows Vista には、Windows XP SP2 (DirectX 9.0c) のランタイムに基づく更新された DirectX ランタイムが含まれており、新しい Windows ディスプレイ ドライバー モデル (WDDM) と新しいオーディオ ドライバー スタックを操作するための変更、およびオペレーティング システムのその他の更新プログラムが含まれています。 Direct3D 9 に加えて、Windows Vista では、正しいビデオ ハードウェアとドライバーが存在する場合、Direct3D9Ex と Direct3D10 の 2 つの新しいインターフェイスがサポートされています。

これらの新しいインターフェイスは WDDM テクノロジに依存しているため、以前のバージョンの Windows では使用できません。 Windows Vista の DirectX テクノロジに加えられたその他のすべての変更は、新しいバージョンの Windows にも固有です。 DirectX 10 という名前は、DirectX SDK (XACT、XINPUT、D3DX) に付属する多くのテクノロジがこのバージョン番号に含まれていないという点で誤解を招きます。 したがって、DirectX ランタイムのバージョン番号を全体として参照すると、9.0c であっても、その意味の多くが失われています。 Windows Vista の DirectX 診断ツール (DXdiag.exe) は DirectX 10 を報告しますが、これは実際には Direct3D 10 のみを指します。

DirectX 11 は Windows 7 に組み込まれており、Windows Vista の更新プログラムとして利用できます (https://go.microsoft.com/fwlink/p/?linkid=160189 を参照してください)。 これには、Direct3D 11 API、DirectX グラフィックス インフラストラクチャ (DXGI) 1.1、10Level9 機能レベル、Windows Advanced Rasterization Platform (WARP) 10 ソフトウェア レンダリング デバイス、Direct2D、DirectWrite、10Level9 および WARP 10 をサポートする Direct3D 10.1 API の更新プログラムが含まれています。

前の質問 (DirectX 10 は Windows XP で使用できますか?) で説明したのと同じ理由で、Direct3D 11 および関連 API は Windows XP では使用できません。

DirectShow は、2005 年 4 月の時点で DirectX SDK から削除されました。 DirectShow のヘッダー、ライブラリ、ツール、サンプルは、Windows ソフトウェア開発キット (旧称 Platform SDK) で取得できます。 DirectX SDK の DirectSetup は引き続き DirectShow のシステム コンポーネントの再配布をサポートしており、最新のコンポーネントは、Microsoft Windows XP Service Pack 2、Windows XP Professional x64 Edition、Windows Server 2003 Service Pack 1、および Windows Vista のオペレーティング システムに既にインストールされています。

新しい WDDM をサポートするために、主な変更が行われました。 新しいドライバー モデル、Direct3D 9 への影響、および 2 つの新しいグラフィックス インターフェイスである Direct3D 9Ex と Direct3D 10 の詳細については、「Windows のグラフィックス API」を確認してください。 Windows 7—Direct3D 11、Direct2D、DirectWrite、DXGI 1.1、および更新された Direct3D 10.1—用の新しいグラフィックス API は、Windows Vista の更新プログラムとして使用できます (https://go.microsoft.com/fwlink/p/?linkid=160189 を参照してください)。

Windows Vista Service Pack 1 には、DirectX ランタイムの更新バージョンが含まれています。 この更新プログラムは、Direct3D 10.1 を含むように Windows Vista のサポートを拡張し、オプションの新しいハードウェア機能を公開します。 (Direct3D 10.1 をサポートできるハードウェアはすべて、Direct3D 10 のすべての機能も完全にサポートしています)。

DirectSound が更新され、マルチチャネル ソフトウェア バッファーをサポートする新しい Windows Vista オーディオ ドライバー スタックの機能が公開されました。 Direct3D 保持モード API が Windows Vista から完全に削除されました。 DirectPlay Voice も削除され、DirectPlay の NAT ヘルパーと DirectInput のアクション マッパー UI も削除されました。 Windows Vista では、Visual Basic 6.0 用の DirectX 7 および DirectX 8 インターフェイスのサポートは利用できません。

Windows 7 には、Windows Vista にある DirectX ランタイム コンポーネントがすべて含まれており、Direct3D 11、DXGI 1.1、10Level9 機能レベル、WARP10 ソフトウェア デバイス、Direct2D、DirectWrite、および 10Level9 と WARP10 をサポートするための Direct3D 10.1 の更新プログラムが追加されています。 詳細については、「Windows のグラフィックス API」を参照してください。

他のすべてのコンポーネントは Windows Vista と同じですが、タイムスタンプ付き MIDI に関連するコア DirectMusic API に対する 64 ビット (x64) ネイティブ サポートが追加されています。 DirectMusic のパフォーマンス レイヤーは非推奨のままであり、アプリケーションの互換性のために Windows 7 上の 32 ビット アプリケーションでのみ使用できます。 Windows Vista では、DirectMusic の 64 ビット ネイティブ サポートは利用できません。

まず、リファレンス ラスタライザーを使用して結果を確認します。 次に、最新の WHQL 認定バージョンの IHV ドライバーで結果を確認します。 D3DENUM_WHQL_LEVEL フラグを渡す IDirect3D9 インターフェイスの GetAdapterIdentifier() メソッドを使用して、WHQL の状態をプログラムで確認できます。

インクルード パスが正しく設定されていない可能性があります。 Microsoft Visual C++ を含む多くのコンパイラには以前のバージョンの SDK が含まれているため、インクルード パスで標準コンパイラのインクルード ディレクトリが最初に検索されると、ヘッダー ファイルが正しくないバージョンになります。 この問題を解決するには、最初に Microsoft DirectX のインクルード パスとライブラリ パスを検索するようにインクルード パスとライブラリ パスが設定されていることを確認します。 SDK の dxreadme.txt ファイルも参照してください。 DirectX SDK をインストールし、Visual C++ を使用している場合、インストーラーは必要に応じてインクルード パスを設定できます。

使用するさまざまな GUID は、1 回だけ定義する必要があります。 DIRECTX ヘッダー ファイルを含める前に INITGUID シンボルを #define すると、GUID の定義が挿入されます。 したがって、これは 1 つのコンパイル 単位に対してのみ発生することを確認する必要があります。 この方法の代わりに、すべての DirectX GUID の定義を含む dxguid.lib ライブラリにリンクすることもできます。 このメソッド (推奨) を使用する場合は、INITGUID シンボルを #define しないでください。

不正解です。 DirectX インターフェイスは COM インターフェイスです。 つまり、番号の大きいインターフェイスが、対応する番号の小さいインターフェイスから派生する必要はありません。 したがって、DirectX オブジェクトに対して別のインターフェイスを取得する唯一の安全な方法は、インターフェイスの QueryInterface メソッドを使用することです。 このメソッドは、すべての COM インターフェイスが派生する必要がある標準の IUnknown インターフェイスの一部です。

異なるバージョンの異なるコンポーネントを自由に混在させることができます。たとえば、DirectInput 8 と Direct3D 9 を同じアプリケーションで使用できます。 ただし、通常、同じアプリケーション内で同じコンポーネントの異なるバージョンを混在させることはできません。たとえば、DirectDraw 7 と Direct3D 9 を混在させることはできません (DirectDraw は DirectX 8 の時点で Direct3D にサブスム化されているのと実質的に同じコンポーネントであるため)。 ただし、同じアプリケーションで Direct3D 9 と Direct3D 10 を同時に使用する場合など、例外があります。これは許可されています。

はい。これらのバージョンの Direct3D を同じアプリケーションで一緒に使用できます。

戻り値は、オブジェクトの現在の参照カウントになります。 ただし、COM 仕様では、これに依存する必要はないことが示されており、値は一般にデバッグ目的でのみ使用できます。 他のさまざまなシステム オブジェクトが、作成した DirectX オブジェクトへの参照を保持している可能性があるため、予期しない値が発生する可能性があります。 このため、別のコンポーネントがまだ参照している場合でもオブジェクトが解放される可能性があるため、参照カウントが 0 になるまで Release を繰り返し呼び出すコードを記述しないでください。

COM インターフェイスが参照カウントされるため、問題はありません。 ただし、DirectX の一部のバージョンでは、インターフェイスのリリース順序に関する既知のバグがいくつかあります。 安全のために、可能な場合は逆の作成順序でインターフェイスをリリースすることをお勧めします。

スマート ポインターは、ポインター機能をカプセル化するように設計された C++ テンプレート クラスです。 特に、COM インターフェイス ポインターをカプセル化するように設計された標準のスマート ポインター クラスがあります。 これらのポインターは、キャストではなく QueryInterface を自動的に実行し、AddRef と Release を自動的に処理します。 それらを使用する必要があるかどうかは、主に好みの問題です。 コードに複数の AddRefs と Releases を含むインターフェイス ポインターのコピーが多数含まれている場合、スマート ポインターを使用すると、コードがきちんとしてエラーが発生しにくくなることが考えられます。 それ以外の場合は、それらを使用せずに実行できます。 Visual C++ には、"comdef.h" ヘッダー ファイルで定義されている標準の Microsoft COM スマート ポインターが含まれています (ヘルプでcom_ptr_t を参照してください)。

DirectX アプリケーションのデバッグに関する最も一般的な問題は、DirectDraw サーフェイスがロックされている間にデバッグを試行することです。 この状況により、Microsoft Windows 9x システムで "Win16 ロック" が発生し、デバッガー ウィンドウが描画できなくなる可能性があります。 通常、サーフェスをロックするときに D3DLOCK_NOSYSLOCK フラグを指定すると、これを排除できます。 Windows 2000 では、この問題は発生しません。 アプリケーションを開発するときは、デバッグ バージョンの DirectX ランタイム (SDK のインストール時に選択) を使用して実行すると便利です。このランタイムは、パラメーターの検証を実行し、デバッガーの出力に役立つメッセージを出力します。

SUCCEEDED マクロと FAILED マクロを使用します。 DirectX メソッドは、複数の成功コードと失敗コードを返すことができるため、簡単です:

== D3D_OK

そうでなければ、同様のテストで常に十分というわけではありません。

しないでください。 Alt + TAB、リモート デスクトップ接続、高速ユーザー切り替え、保護者による制御の使用制限、その他多くのイベントなど、多くのことが発生する場合に、ゲームはタスクの切り替えをグレースフルに処理できる必要があります。

同時に、キーボード中心の制御スキームでゲームを誤って切り替える 2 つの一般的な原因は、Windows ロゴ キーを押し、Shift キーを使用してアクセシビリティ機能 StickyKeys をアクティブ化してしまうことです。 機能を無効にしてこれらのケースに対処するには、「ゲームでショートカット キーを無効にする」で説明されている手法を参照してください。

Microsoft Press 出版の Dale Rogerson 著『Inside COM』は、優れた COM 概要を記載しています。 COM の詳細については、Longman 出版の Don Box 著『Essential COM』 の書籍も強くお勧めします。

マネージド コードは、.NET Framework 共通言語ランタイム (CLR) によって実行が管理されるコードです。 これは、ネイティブに実行されるコードとランタイムの間の協力のコントラクトを指します。 このコントラクトは、実行のどの時点でも、ランタイムが実行中の CPU を停止し、現在の CPU 命令アドレスに固有の情報を取得できることを規定しています。 クエリ可能である必要がある情報は、一般に、レジスタやスタック メモリの内容などのランタイム状態に関連します。

コードを実行する前に、IL はネイティブ実行可能コードにコンパイルされます。 また、このコンパイルはマネージド実行環境 (より正確には、マネージド実行環境をターゲットにする方法を認識するランタイム対応コンパイラ) によって行われるため、マネージド実行環境によりコードの実行内容が保証されます。 トラップや適切なガベージ コレクション フック、例外処理、タイプ セーフ、配列境界、インデックス チェックなどを挿入できます。 たとえば、このようなコンパイラでは、ガベージ コレクターがバックグラウンドで別のスレッドで実行され、アクティブな呼び出し履歴を常に移動し、すべてのルートを見つけて、すべてのライブ オブジェクトを追跡できるように、スタック フレームとすべてが正しくレイアウトされます。 さらに、IL にはタイプ セーフという概念があるため、実行エンジンはタイプ セーフの保証を維持し、セキュリティ ホールにつながるプログラミング ミスのクラス全体を排除します。

アンマネージド ワールドとは対照的に、アンマネージド実行可能ファイルは基本的にバイナリ イメージ (x86コード) であり、メモリに読み込まれます。 プログラム カウンターはそこに置かれ、それを OS は最後に知ることになります。 メモリ管理やポート I/O などの保護は行われますが、システムはアプリケーションの実行内容を実際に把握していません。 そのため、アプリケーションの実行時に何が起こるかを保証することはできません。

たくさんあります。 ただし、強くお勧めする 2 つを次に示します:

• Charles Petzold 著『Programming Windows』 (Microsoft Press)
• Jeffrey Richter 著『Programming Applications for Windows』 (Microsoft Press)

Microsoft では、すべてのシステム DLL に対して削除されたシンボル (その他もいくつか) を公開しています。 これらにアクセスするには、Visual Studio 内のプロジェクト設定のシンボル パスに次のコードを追加します:

srv*https://msdl.microsoft.com/download/symbols

シンボルをローカルにキャッシュする場合は、次の構文を使用します:

srv*c:\cache*https://msdl.microsoft.com/download/symbols

c:\cache はシンボル ファイルをキャッシュするためのローカル ディレクトリです。

Direct3D に関する質問

Direct3D に関する一般的な質問

この主題に関する標準的な書籍は、Foley, Van Dam 等著『Computer Graphics: Principles and Practice』です。これは、ジオメトリ、ラスタライズ、ライティング技術の数学的基礎を理解したい人にとって貴重なリソースです。 comp.graphics.algorithms Usenet グループの FAQ にも役立つ資料が含まれています。

一概には言えません。 Direct3D には、完全に機能するソフトウェア頂点処理パイプライン (カスタム頂点シェーダーのサポートを含む) があります。 ただし、ピクセル レベルの操作にはエミュレーションは提供されません。アプリケーションでは、適切なキャップ ビットをチェックし、ValidateDevice API を使用してサポートを決定する必要があります。

パフォーマンス アプリケーションについてはエミュレートしません。 ドライバーの検証にはリファレンス ラスタライザーが用意されていますが、その実装はパフォーマンスではなく精度のために設計されています。 Direct3D では、プラグイン ソフトウェア ラスタライザーがサポートされています。

カラー キー設定は直接サポートされていません。代わりに、アルファ ブレンドを使用してカラー キーをエミュレートする必要があります。 これを容易にするために、D3DXCreateTextureFromFileEx() 関数を使用できます。 この関数は、キーの色パラメーターを受け取り、指定された色を含むソース画像のすべてのピクセルを、作成されたテクスチャ内の透明な黒のピクセルに置き換えます。

はい。 Direct3D ジオメトリ パイプラインには、プロセッサの種類に応じていくつかの異なるコード パスがあり、3DNow! によって提供される特別な浮動小数点演算が利用されます。 または Pentium III SIMD 命令を使用できます。 これには、カスタム頂点シェーダーの処理が含まれます。

アルファ値が特定のしきい値以下のピクセルを除外できます。 この動作は、renderstates ALPHATESTENABLE、ALPHAREF、ALPHAFUNC を使用して制御します。

ステンシル バッファーは、z バッファーと同様に、ピクセル単位の情報の追加バッファーです。 実際には、z バッファーのビットの一部に存在します。 一般的なステンシル/z バッファー形式は、15 ビット z および 1 ビット ステンシル、または 24 ビット z および 8 ビット ステンシルです。 多角形がレンダリングされるときに、ステンシル バッファーの内容に対して単純な算術演算をピクセル単位で実行できます。 たとえば、ステンシル バッファーをインクリメントまたはデクリメントしたり、ステンシル値が単純な比較テストで失敗した場合にピクセルを拒否したりできます。 これは、フレーム バッファーの領域をマークアウトし、マークされた (またはマークされていない) 領域のみをレンダリングする効果に役立ちます。 良い例は、シャドウ ボリュームなどのボリューム効果です。

これと他のボリューム ステンシル バッファー効果の鍵となるのは、ステンシル バッファーと z バッファーの間の相互作用です。 シャドウ ボリュームがあるシーンは、3 つのステージでレンダリングされます。 まず、z バッファーを使用して、シャドウのないシーンが通常どおりにレンダリングされます。 次に、ステンシル バッファーで次のように影がマークされます。 シャドウ ボリュームの前面は非表示のポリゴをン使用して描画され、z テストは有効になっていますが、z 書き込みが無効になり、z テストに合格するたびにステンシル バッファーがインクリメントされます。 シャドウ ボリュームの背面も同様にレンダリングされますが、代わりにステンシル値がデクリメントされます。

次に、1 つのピクセルについて考えてみましょう。 カメラがシャドウ ボリューム内にないと仮定すると、シーン内の対応するポイントに対して 4 つの可能性があります。 カメラからポイントまでのレイがシャドウ ボリュームと交差しない場合、シャドウ ポリゴンは描画されず、ステンシル バッファーはゼロのままです。 それ以外の場合、ポイントがシャドウ ボリュームの前にある場合、シャドウ ポリゴンは z バッファーアウトされ、ステンシルは再び変更されませんメイン。 ポイントがシャドウ ボリュームの背後にある場合、背面と同じ数の前面シャドウ面がレンダリングされ、ステンシルは 0 になり、デクリメントされた回数だけインクリメントされます。

最後の可能性は、ポイントがシャドウ ボリューム内にあるということです。 この場合、シャドウ ボリュームの背面は z バッファーアウトされますが、前面はバッファー処理されないため、ステンシル バッファーは 0 以外の値になります。 結果として、シャドウに存在するフレーム バッファーの一部のステンシル値が 0 以外になります。 最後に、実際に影をレンダリングするために、シーン全体がアルファ ブレンドポリゴンセットで洗い流され、0 以外のステンシル値のピクセルにのみ影響します。 この手法の例は、DirectX SDK に付属している "シャドウ ボリューム" サンプルで確認できます。

これは、Direct3D 9 のドキュメントで完全に説明されています。 ただし、要約すると、テクセルに正しく合わせるためには、スクリーン座標を 1 ピクセルの -0.5 だけ偏らせる必要があるということです。 ほとんどのカードがテクセルアラインメント ルールに適切に準拠するようになりましたが、古いカードやドライバーには準拠していないものもあります。 このような場合に対処するには、問題のハードウェア ベンダーに連絡し、更新されたドライバーまたは推奨される回避策を要求することをお勧めします。 Direct3D 10 では、このルールは保持されなくなりました。

デバイスの作成時に D3DCREATE_PUREDEVICE フラグを使用して、純粋なデバイスを作成します。 純粋なデバイスでは、現在の状態 (状態の変更中) は保存されないため、多くの場合、パフォーマンスが向上します。このデバイスには、ハードウェア頂点処理も必要です。 純粋なデバイスは、通常、開発とデバッグが完了したときに使用され、最適なパフォーマンスを実現する必要があります。

純粋なデバイスの欠点の 1 つは、すべての Get* API 呼び出しをサポートしていないということです。つまり、純粋なデバイスを使用してパイプラインの状態を照会することはできません。 これにより、アプリケーションの実行中にデバッグが困難になります。 純粋なデバイスで無効になっているすべてのメソッドの一覧を次に示します。

• IDirect3DDevice9::GetClipPlane
• IDirect3DDevice9::GetClipStatus
• IDirect3DDevice9::GetLight
• IDirect3DDevice9::GetLightEnable
• IDirect3DDevice9::GetMaterial
• IDirect3DDevice9::GetPixelShaderConstantF
• IDirect3DDevice9::GetPixelShaderConstantI
• IDirect3DDevice9::GetPixelShaderConstantB
• IDirect3DDevice9::GetRenderState
• IDirect3DDevice9::GetSamplerState
• IDirect3DDevice9::GetTextureStageState
• IDirect3DDevice9::GetTransform
• IDirect3DDevice9::GetVertexShaderConstantF
• IDirect3DDevice9::GetVertexShaderConstantI
• IDirect3DDevice9::GetVertexShaderConstantB

純粋なデバイスの 2 つ目の欠点は、冗長な状態の変更をフィルター処理しないことです。 純粋なデバイスを使用する場合、アプリケーションはレンダー ループの状態変更の数を最小限に減らす必要があります。これには、状態が複数回設定されないように、状態の変更のフィルター処理が含まれる場合があります。 このトレードオフはアプリケーションによって異なります。フレームあたり 1,000 を超える Set 呼び出しを使用する場合は、非純粋デバイスによって自動的に実行される冗長性フィルタリングを利用することを検討する必要があります。

すべてのパフォーマンスの問題と同様に、純粋なデバイスでアプリケーションのパフォーマンスが向上するかどうかを知る唯一の方法は、アプリケーションのパフォーマンスを純粋デバイスと非純粋デバイスと比較することです。 純粋なデバイスは、API の CPU オーバーヘッドを減らすことでアプリケーションを高速化する可能性があります。 ただし、次のことに注意してください。 一部のシナリオでは、純粋なデバイスがアプリケーションの速度を低下させます (冗長な状態の変更によって引き起こされる追加の CPU 処理が必要なため)。 どの種類のデバイスがアプリケーションに最適か不明で、アプリケーションの冗長な変更をフィルター処理しない場合は、非純粋デバイスを使用します。

列挙は、IDirect3D9 インターフェイスのメソッドを使用して、アプリケーションによって単純なイテレーションを通じて実行できます。 GetAdapterCount を呼び出して、システム内のビデオ カードの数を確認します。 GetAdapterMonitor を呼び出して、アダプターが接続されている物理モニターを決定します (このメソッドは HMONITOR を返します。このメソッドは、Win32 API GetMonitorInfo で使用して物理モニターに関する情報を確認できます)。 特定のディスプレイ アダプターの特性を判断するか、そのアダプターに Direct3D デバイスを作成することは、GetDeviceCaps、CreateDevice、またはその他のメソッドを呼び出すときに、D3DADAPTER_DEFAULT の代わりに適切なアダプター番号を渡すのと同じくらい簡単です。

Direct3D 9 の時点で、> 2 つの同時テクスチャしかサポートできないカードの検証が強化されました。 特定のアルファ モジュレート操作を使用する場合、以前のカードには 3 つのテクスチャ ステージしか使用できません。 ユーザーが 3 つのステージを使用する最も一般的な用途は、浮き出しのバンプマップです。それでも、D3D9 でこれを行うことができます。

高さフィールドはアルファ チャネルに格納する必要があり、ライトの貢献度を調整するために使用されます。つまり:

// Stage 0 is the base texture, with the height map in the alpha channel
m_pd3dDevice->SetTexture(0, m_pEmbossTexture );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_TEXCOORDINDEX, 0 );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_COLOROP,   D3DTOP_MODULATE );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_COLORARG1, D3DTA_TEXTURE );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_COLORARG2, D3DTA_DIFFUSE );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_ALPHAOP,   D3DTOP_SELECTARG1 );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_ALPHAARG1, D3DTA_TEXTURE );
if( m_bShowEmbossMethod )
{
 // Stage 1 passes through the RGB channels (SELECTARG2 = CURRENT), and 
 // does a signed add with the inverted alpha channel. 
 // The texture coords associated with Stage 1 are the shifted ones, so 
 // the result is:
 //    (height - shifted_height) * tex.RGB * diffuse.RGB
   m_pd3dDevice->SetTexture( 1, m_pEmbossTexture );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_TEXCOORDINDEX, 1 );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_COLOROP, D3DTOP_SELECTARG2 );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_COLORARG1, D3DTA_TEXTURE );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_COLORARG2, D3DTA_CURRENT );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_ALPHAOP, D3DTOP_ADDSIGNED );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_ALPHAARG1, D3DTA_TEXTURE|D3DTA_COMPLEMENT );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_ALPHAARG2, D3DTA_CURRENT );

   // Set up the alpha blender to multiply the alpha channel 
   // (monochrome emboss) with the src color (lighted texture)
   m_pd3dDevice->SetRenderState( D3DRS_ALPHABLENDENABLE, TRUE );
   m_pd3dDevice->SetRenderState( D3DRS_SRCBLEND,  D3DBLEND_SRCALPHA );
   m_pd3dDevice->SetRenderState( D3DRS_DESTBLEND, D3DBLEND_ZERO );
}

このサンプルは、他の古いサンプルと共に、現在の SDK リリースでは出荷されなくなり、今後の SDK リリースでは出荷されません。

ジオメトリ (頂点) 処理

Direct3D は、1 つ以上の頂点ストリームからパイプラインの処理部分に供給される各頂点をアセンブルします。 頂点ストリームが 1 つしかないということは、頂点が 1 つのソースから取得される古い DirectX 8 より前のモデルに対応しています。 DirectX 8 では、異なる頂点コンポーネントが異なるなソースから取得される場合があります。たとえば、1 つの頂点バッファーで位置と法線を保持し、2 つ目の頂点バッファーはカラー値とテクスチャ座標を保持できます。

頂点シェーダーは、1 つの頂点を処理するためのプロシージャです。 これは、D3DX ユーティリティ ライブラリによって Direct3D が受け入れるトークン ストリームに組み込まれた、単純なアセンブリに似た言語を使用して定義されます。 頂点シェーダーは、入力として 1 つの頂点と定数値のセットを受け取ります。頂点の位置 (クリップ空間) と、必要に応じて、ラスタライズで使用される色とテクスチャ座標のセットを出力します。 カスタム頂点シェーダーがある場合、頂点コンポーネントには Direct3D によってセマンティクスが適用されなくなり、頂点は、作成した頂点シェーダーによって解釈される単なる任意のデータであることに注意してください。

不正解です。 頂点シェーダーは、変換された頂点位置のクリップ空間に同種の座標を出力します。 パースペクティブ分割とクリッピングは、シェーダーの後に自動的に実行されます。

頂点シェーダーは頂点を作成または破棄できません。これは一度に 1 つの頂点で動作し、1 つの未処理の頂点を入力として受け取り、1 つの処理された頂点を出力します。 そのため、既存のジオメトリの操作 (デフォメーションの適用、またはスキニング操作の実行) には使用できますが、実際には新しいジオメトリを生成することはできません。

不正解です。 いずれかを選択する必要があります。 カスタム頂点シェーダーを使用している場合は、頂点変換全体を実行する必要があります。

はい。 Direct3D ソフトウェア頂点処理エンジンは、驚くほど高いパフォーマンスを備えたカスタム頂点シェーダーを完全にサポートしています。

ハードウェアで頂点シェーダーをサポートできるデバイスは、サポートされている頂点シェーダーのバージョン レベルを示すために、D3DCAPS9::VertexShaderVersion フィールドに入力する必要があります。 特定のレベルの頂点シェーダーをサポートするデバイスは、そのレベル以下の仕様を満たすすべての有効な頂点シェーダーをサポートする必要があります。

少なくとも 96 個の定数レジスタをサポートするには、vs 1.0 の頂点シェーダーをサポートするデバイスが必要です。 デバイスは、この最小数を超える数をサポートし、D3DCAPS9::MaxVertexShaderConst フィールドを使用してこれを報告できます。

この状況の通常の例は、面ごとに異なるテクスチャを使用するキューブです。 残念ながら、答えはいいえです。現時点では、頂点コンポーネントのインデックスを個別に作成することはできません。 複数の頂点ストリームがある場合でも、すべてのストリームに同じインデックスが付けられます。

ソフトウェア ジオメトリ パイプラインを使用する場合、Direct3D は最初に、インデックスの作成時の "オンデマンド" に変換するのではなく、送信した範囲内のすべての頂点を変換します。 高密度にパックされたデータ (つまり、ほとんどの頂点が使用されている) の場合、これは、特に SIMD 命令が使用可能な場合に、より効率的です。 データがまばらにパックされている (つまり、多くの頂点が使用されない) 場合は、冗長な変換が多くなりすぎないようにデータを再配置することを検討する必要があります。 ハードウェア ジオメトリ アクセラレーションを使用する場合、頂点は通常、必要に応じて必要に応じて変換されます。

インデックス バッファーは頂点バッファーと非常によく似ていますが、違うところは DrawIndexedPrimitive 呼び出しで使用するためのインデックスが含まれていることです。 可能であれば、頂点バッファーと同じ理由で、生のアプリケーション割り当てメモリではなくインデックス バッファーを使用することを強くお勧めします。

不正解です。 D3DCAPS9::MaxVertexIndex フィールドをチェックして、デバイスでサポートされる最大インデックス値を決定する必要があります。 D3DFMT_INDEX32 型のインデックス バッファーをサポートするには、この値が 2 から 16 乗 -1 (0xffff) を超える必要があります。 さらに、一部のデバイスでは 32 ビット インデックスがサポートされますが、最大インデックス値が 2 から 32 乗 -1 (0xffffffff) までサポートされていることに注意してください。この場合、アプリケーションはデバイスの報告する制限を尊重する必要があります。

x64 用に最適化されたソフトウェア頂点パイプラインがありますが、IA64 には存在しません。

パフォーマンス チューニング

パフォーマンスを最適化する際に確認する重要な領域を次に示します:

Direct3D は、プリミティブの大規模なバッチ用に最適化されています。 1 回の呼び出しで送信できるポリゴンが多いほど、より優れています。 経験則として、プリミティブ呼び出しごとに平均 1,000 個の頂点を目指します。 そのレベルを下回ると、おそらく最適なパフォーマンスが得られない可能性があり、それを超えると、リターンが減少し、コンカレンシーに関する考慮事項と競合する可能性があります (以下を参照してください)。

レンダリング状態の変更は、特にテクスチャを変更する場合に、コストの高い操作になる可能性があります。 このため、フレームごとに行われる状態変更の数を最小限に抑える必要があります。 また、頂点バッファーまたはインデックス バッファーの変更を最小限に抑えるようにします。

他の処理と同時にレンダリングを実行するように調整できる場合は、システムパフォーマンスを最大限に活かせます。 この目標は、renderstate の変更を減らすという目標と競合する可能性があります。 状態の変更を減らすためのバッチ処理と、同時実効性を実現するためにデータを早めにドライバーにプッシュすることのバランスを取る必要があります。 ラウンドロビン方式で複数の頂点バッファーを使用すると、同時実行性に役立ちます。

デバイスにテクスチャをアップロードすると、帯域幅が消費され、頂点データとの帯域幅の競合が発生します。 そのため、コミット テクスチャ メモリをオーバーしないようにすることが重要です。そのため、キャッシュ スキームでは各フレームに過剰な量のテクスチャがアップロードされます。

アプリケーションによって割り当てられたメモリのプレーン ブロックではなく、常に頂点バッファーとインデックス バッファーを使用する必要があります。 少なくとも、頂点バッファーとインデックス バッファーのロック セマンティクスでは、冗長なコピー操作を回避できます。 一部のドライバーでは、頂点バッファーまたはインデックス バッファーは、ハードウェアによるアクセスに最適なメモリ (ビデオまたは AGP メモリ内など) に配置される場合があります。

これらは DirectX 7.0 で導入されました。 これらは、一連の状態変更 (照明、マテリアル、マトリックスの変更を含む) をマクロに記録するメカニズムを提供し、1 回の呼び出しで再生できます。 これには 2 つ利点があります。

• 多くの呼び出しではなく 1 つの呼び出しを行うことで、呼び出しのオーバーヘッドを削減できます。
• 対応するドライバーは、状態の変更を事前に解析して事前コンパイルできるため、グラフィックス ハードウェアへの送信がはるかに高速になります。

状態の変更は引き続きコストがかかりますが、状態マクロを使用すると、少なくとも一部のコストを削減できます。 1 つの Direct3D デバイスのみを使用します。 複数のターゲットにレンダリングする必要がある場合は、SetRenderTarget を使用します。 複数の 3D ウィンドウでウィンドウ化されたアプリケーションを作成する場合は、CreateAdditionalSwapChain API を使用します。 ランタイムは 1 つのデバイス用に最適化されており、複数のデバイスを使用する場合は速度が大きく低下します。

実際のデータで遭遇するメッシュの多くは、複数のポリゴンで共有される頂点を特徴としています。 パフォーマンスを最大化するには、変換され、バス経由でレンダリング デバイスに送信される頂点の重複を減らすことが望ましいです。 単純な三角形リストを使用しても頂点の共有が実現せず、最適な方法が最も少なくなることは明らかです。 次に、ストリップとファンを使用するか (多角形間の特定の接続関係を意味する)、インデックス付きリストを使用するかのどちらかを選択します。 データが自然にストリップとファンに分類される場合は、ドライバーに送信されるデータを最小限に抑えるため、これらは最も適切な選択肢です。 ただし、メッシュをストリップとファンに分解すると、多くの場合、多数の個別の部分が生成され、多数の DrawPrimitive 呼び出しが行われることを意味します。 このため、最も効率的な方法は、通常、三角形リストで 1 つの DrawIndexedPrimitive 呼び出しを使用することです。 インデックス付きリストを使用するもう 1 つの利点は、連続する三角形が 1 つの頂点のみを共有している場合でも利点が得られるということです。 要約すると、データが自然に大きなストリップやファンに分類される場合は、ストリップまたはファンを使用します。それ以外の場合は、インデックス付きリストを使用します。

IDirect3DDevice9::GetAvailableTextureMem は、AGP を含む使用可能メモリの合計を返します。 ビデオ メモリの容量を前提にリソースを割り当てるのは、あまり良いアイデアとは言えません。 たとえば、カードが統合メモリ アーキテクチャ (UMA) で実行されている場合、またはテクスチャを圧縮できる場合はどうでしょうか? 思っていたよりも多くの空き領域が存在する可能性があります。 リソースを作成し、"メモリ不足" エラーのチェックしてから、テクスチャにスケール バックする必要があります。 たとえば、テクスチャの上位ミップレベルを削除できます。

1. D3DUSAGE_DYNAMIC と D3DUSAGE_WRITEONLY の使用フラグと D3DPOOL_DEFAULT プール フラグを使用して頂点バッファーを作成します。 (ソフトウェア頂点処理を使用している場合は、D3DUSAGE_SOFTWAREPROCESSING も指定します)。
2. I = 0.
3. 状態 (テクスチャ、レンダーステートなど) を設定します。
4. バッファーにスペースがあるかどうかを確認します。つまり、I + M <= N などです。 (M は新しい頂点の数です)。
5. [はい] の場合は、D3DLOCK_NOOVERWRITE を使用して VB をロックします。 これにより、Direct3D とドライバーは頂点を追加し、以前にバッチ処理した頂点を変更しないことを示します。 そのため、DMA 操作が進行中の場合は、中断されません。 [いいえ] の場合は、11 に進みます。
6. I において M 頂点を塗りつぶします。
7. ロック解除します。
8. Draw[Indexed]Primitive を呼び出します。 インデックスのないプリミティブの場合は、StartVertex パラメーターとして I を使用します。 インデックス付きプリミティブの場合は、インデックスが頂点バッファーの正しい部分を指していることを確認します (これを実現するには、SetIndices 呼び出しの BaseVertexIndex パラメーターを使用するのが最も簡単な場合があります)。
9. I += M.
10. 3 に進みます。
11. わかりました。スペースが不足しているので、新しい VB から始めましょう。 DMA 操作が進行中である可能性があるため、同じものを使用したくはありません。 D3DLOCK_DISCARD フラグを使用して同じ VB をロックすることで、Direct3D とドライバーに通信します。 つまり、「もう古いポインターは使い終わったし、古い内容なんてどうでもいいから、新しいポインターを欲しい」ということです。
12. I = 0.
13. 4 (または 6) に移動します。

Direct3D 9 の時点では、頂点ストリーム宣言は単なる DWORD 配列ではなく、D3DVERTEXELEMENT9 構造体の配列になりました。 ランタイムは、追加のセマンティック情報と使用法情報を使用して、頂点ストリームの内容を頂点シェーダー入力レジスタ/変数にバインドします。 Direct3D 9 の場合、頂点宣言は頂点シェーダーから切り離されるため、ランタイムはシェーダーに必要なデータのみをバインドするため、異なる形式のジオメトリを持つシェーダーを簡単に使用できます。

新しい頂点宣言は、固定関数パイプラインまたはシェーダーで使用できます。 固定関数パイプラインでは、SetVertexShader を呼び出す必要はありません。 ただし、固定関数パイプラインに切り替えて、以前に頂点シェーダーを使用した場合は、SetVertexShader(NULL) を呼び出します。 これが完了したら、SetFVF を呼び出して FVF コードを宣言する必要があります。

頂点シェーダーを使用する場合は、頂点シェーダー オブジェクトで SetVertexShader を呼び出します。 さらに、SetFVF を呼び出して頂点宣言を設定します。 これは FVF で暗黙的な情報を使用します。 SetVertexDeclaration は、FVF では表現できない頂点宣言をサポートしているため、SetFVF の代わりに呼び出すことができます。

D3DX 画像ファイル ローダー関数は、BMP、TGA、JPG、DIB、PPM、DDS ファイルをサポートします。

ID3DXFont::DrawText 関数を使用する場合の一般的な間違いは、色パラメーターにゼロ アルファ コンポーネントを指定することです。結果として、テキストが完全に透明 (つまり非表示) になります。 完全に不透明なテキストの場合は、カラー パラメーターのアルファ成分が完全に飽和するようにします (255)。

DirectX 8.1 SDK では、特に D3DXSaveSurfaceToFile() と D3DXSaveTextureToFile() という 2 つの関数が D3DX ライブラリに追加されました。 これらの関数は、イメージを BMP 形式または DDS 形式でファイルに保存することをサポートします。 以前のバージョンでは、サーフェスをロックして画像データを読み取り、ビットマップ ファイルに書き込む必要があります。 ビットマップを格納する関数の記述については、「画像の格納」を参照してください。

また、GDI+ を使用してさまざまな形式でイメージを保存することもできますが、アプリケーションで追加のサポート ファイルを配布する必要があります。

Microsoft 上位レベル シェーダー言語 (HLSL) をゲーム エンジンに組み込むには、次の 3 つの方法があります:

• シェーダー ソースを頂点またはピクセル シェーディング アセンブリ (コマンド ライン ユーティリティ fxc.exe を使用) にコンパイルし、実行時に D3DXAssembleShader() を使用します。 これにより、DirectX 8 ゲームでも HLSL のパワーを活用できます。
• D3DXCompileShader() を使用して、シェーダー ソースをトークン ストリームと定数テーブル 形式にコンパイルします。 実行時にトークン ストリームと定数テーブルを読み込み、デバイスで CreateVertexShader() または CreatePixelShader() を呼び出してシェーダーを作成します。
• 起動して実行する最も簡単な方法は、効果ファイルで D3DXCreateEffectFromFile() または D3DXCreateEffectFromResource() を呼び出して D3DX Effects システムを利用することです。

2006 年 12 月の DirectX SDK 以降では、Direct3D 10 用に開発された新しい HLSL コンパイラが Direct3D 9 ターゲットに対して有効になりました。 新しいコンパイラでは、ps_1_x ターゲットはサポートされておらず、すべての Direct3D HLSL シェーダーの既定のコンパイラになりました。 下位互換性のフラグを使用して、ps_1_x ターゲットを強制的に ps_2_0 ターゲットとしてコンパイルできます。

レガシ コンパイラを使用するアプリケーションは、実行時にフラグを指定するか (コンパイラ フラグを参照してください)、または fxc を使用するときにスイッチを指定することで、引き続きこれを行うことができます。

D3DXCreateEffect を使用して ID3DXEffect を作成し、GetPassDesc を使用して D3DXPASS_DESC を取得します。 この構造体には、頂点シェーダーとピクセル シェーダーへのポインターが含まれています。

ID3DXEffectCompiler::GetPassDesc を使用しないでください。 このメソッドから返される頂点シェーダー ハンドルとピクセル シェーダー ハンドルは NULL です。

ノイズの組み込み関数は、Ken Perlin によって定義されたパーリン ノイズを生成します。 HLSL 関数は現在、現在のハードウェアがメソッドをネイティブにサポートしていないため、テクスチャ シェーダーのテクスチャを塗りつぶすためにのみ使用できます。 テクスチャ シェーダーは、読み込み時に手続き的に定義されたテクスチャを生成するのに役立つヘルパー関数である D3DXFill*Texture() 関数と組み合わせて使用されます。

実行するデバイスに最適な HLSL プロファイルを決定する文字列を返す D3DXGetPixelShaderProfile() 関数と D3DXGetPixelShaderProfile() 関数を使用できます。

定数テーブルへのアクセスに使用される ID3DXConstantTable インターフェイスを使用します。 この表には、高度な言語シェーダーと効果で使用される変数が含まれています。

はい。プライベート データを設定するには、SetPrivateData を呼び出します (pReal は D3D テクスチャ オブジェクト、pSpoof はラップされたテクスチャ オブジェクト)。

hr = pReal->SetPrivateData(IID_Spoof, &pSpoof, 
            sizeof(IDirect3DResource9*), 0)));

ラップされたポインターを検索するには:

    IDirect3DResource9* pSpoof;
    DWORD dwSize = sizeof(pSpoof);
    hr = pReal->GetPrivateData(IID_Spoof, (void*) &pSpoof, &dwSize);

顔属性を定義した後、メッシュを最適化していない可能性があります。 属性を指定してから ID3DXMesh::DrawSubset() を呼び出す場合、このメソッドは、要求された属性を含むすべての顔に対してメッシュの検索を実行する必要があります。 さらに、レンダリングされた顔はランダム アクセス パターンである可能性が高いため、頂点キャッシュは使用されません。 サブセットの顔属性を定義した後、ID3DXMesh::Optimize メソッドまたは ID3DXMesh::OptimizeInPlace メソッドを呼び出し、D3DXMESHOPT_ATTRSORT 以上の最適化メソッドを指定します。 最適なパフォーマンスを得る場合は、D3DXMESHOPT_VERTEXCACHE フラグを使用して最適化する必要があることに注意してください。このフラグを使用すると、頂点の順序が変更され、頂点キャッシュの使用率が最適になります。 D3DX メッシュに対して生成される隣接配列には、面ごとに 3 つのエントリがありますが、3 つのエッジすべてに隣接する面がない面もあります。 これはどのようにエンコードされますか? 隣接する面がないエントリは、0xffffffffとしてエンコードされます。

PRT は、Summer 2003 SDK 更新プログラムに追加された D3DX の新機能です。 これにより、グローバル イルミネーション、ソフト シャドウ、サブサーフェススキャッターなどの複雑なライティング シナリオをリアルタイムでレンダリングできます。 SDK には、テクノロジをゲームに統合する方法のドキュメントとサンプルが含まれています。 PRT デモ サンプルと LocalDeformablePRT Sample サンプルでは、頂点ごとおよびピクセルごとの照明シナリオにシミュレーターを使用する方法を示します。 このトピックとその他のトピックの詳細については、Peter Pike Sloan の Web ページを参照してください。

Direct3DDevice9::CreateRenderTarget を使用してマルチサンプリング レンダー ターゲットを作成します。 シーンをそのレンダー ターゲットにレンダリングした後、StretchRect をそのシーンからレンダー ターゲット テクスチャに変換します。 オフスクリーン テクスチャに変更を加えた場合 (ぼかしやブルームなど)、表示する前にバック バッファーにコピーし直します()。

デバッグ DirectX ランタイムがインストールされている可能性があります。 ランタイムのデバッグ バージョンでは、初期化されていないバッファーでバグを開発者がキャッチできるように、バッファーに静的な情報が格納されます。 作成後に DirectSound バッファーの内容を保証することはできません。特に、バッファーがゼロ アウトされているとは想定できません。

実際のパラメーターの変更が DirectX 8 ですぐに行われるとは限りません。 効率を高める目的で、DirectSound は、バッファーが再生される前に、再生カーソルから開始して、バッファー内の 100 ミリ秒のサウンド データを処理します。 この前処理は、次のすべての呼び出しの後に行われます:

IDirectSoundBuffer8::SetCurrentPosition
IDirectSoundBuffer8::SetFX
IDirectSoundBuffer8::Stop
IDirectSoundBuffer8::Unlock

DirectX 9 の時点で、Just-In-Time 効果を処理する新しい FX 処理アルゴリズムがこの問題に対処し、待機時間を短縮しました。 アルゴリズムが IDirectSoundBuffer8::Play() 呼び出しに追加され、書き込みカーソルのすぐ前に効果を処理する追加のスレッドが追加されました。 そのため、パラメーターはいつでも設定でき、期待どおりに動作します。 ただし、再生バッファーでは、再生カーソルと書き込みカーソル (およびもう少しのパディング) の間のオーディオが既に処理されているため、パラメーターの変更が読み上げられる前に小さな遅延 (通常は 100 ミリ秒) が発生することに注意してください。

DirectSoundEnumerate() を使用して使用可能な DSound デバイスを一覧表示する必要がない場合は、アプリケーションを dsound.lib にリンクせず、代わりに COMs CoCreateInstance(CLSID_DirectSound...) を介して使用し、Initialize(NULL) を使用して DSound オブジェクトを初期化します。 DirectSoundEnumerate() を使用する必要がある場合は、LoadLibrary("dsound.dll") を使用して dsound.dll を動的に読み込むことができます。GetProcAddress("DirectSoundEnumerateA/W") と GetProcAddress("DirectSoundCreateA/W") などを使用してそのメソッドにアクセスします。

DirectSound ヘルプ ファイルで質問に対する回答が見つからない場合は、マルチ チャンネル オーディオ データと WAVE ファイルに関する詳細な情報が記載された良い記事があります。

DirectSound 9.0 では、バッファーを複製するときに、重複するバッファーで IDirectSoundBuffer8 インターフェイスを取得できるようになりました。これにより、AcquireResources メソッドにアクセスできるようになります。 これにより、バッファーを DSBCAPS_LOCDEFER フラグとハードウェア リソースに関連付けることができます。 その後、Play() を呼び出す前に、このバッファーに EAX パラメーターを設定できます。

さまざまなバージョンの DirectSound、コア Windows オーディオ スタック、およびカーソル位置の通知を信頼できないオーディオ ドライバーには、いくつかの微妙なバグがあります。 通知が適切に動作することがわかっている既知のハードウェア/ソフトウェア構成を対象としている場合を除き、カーソル位置通知は避けてください。 位置追跡の場合、GetCurrentPosition() はより安全な手法です。

各バッファーの GetCurrentPosition() 呼び出しごとにシステム呼び出しが発生し、システム呼び出しは DSound の CPU フットプリントの大きなコンポーネントであるため、最小化する必要があります。 NT (Win2K および XP) では、ソフトウェア バッファー (および一部のデバイスのハードウェア バッファー) のカーソルは 10 ミリ秒単位で移動するため、GetCurrentPosition() を 10 ミリ秒ごとに呼び出すのが理想的です。 5 ミリ秒ごとよりも頻繁に呼び出すと、パフォーマンスが低下します。

オーディオ コードのパフォーマンスを向上させるには、いくつかの操作を行うことができます:

• GetCurrentPosition をあまり頻繁に呼び出さないでください。 各バッファーの GetCurrentPosition() 呼び出しごとにシステム呼び出しが発生し、システム呼び出しは DSound の CPU フットプリントの大きなコンポーネントであるため、最小化する必要があります。 NT (Win2K および XP) では、ソフトウェア バッファー (および一部のデバイスのハードウェア バッファー) のカーソルは 10 ミリ秒単位で移動するため、GetCurrentPosition() を 10 ミリ秒ごとに呼び出すのが理想的です。 5 ミリ秒ごとよりも頻繁に呼び出すと、パフォーマンスが低下します。

• オーディオには、別の低いフレーム レートを使用します。 今日では、多くの Windows ゲームは 1 秒あたり 100 フレームを超える可能性があり、ほとんどの場合、同じフレームレートで 3D オーディオパラメータを更新する必要はありません。 オーディオを 2 番目または 3 番目のグラフィックス フレームごと、または 30 ミリ秒ごとに処理すると、オーディオ品質を低下させることなく、アプリケーション全体でオーディオ呼び出しの数を大幅に減らすことができます。

• 3D オブジェクトに DS3D_DEFERRED を使用します。 ほとんどのオーディオ カードはパラメーターの変更にすぐに応答し、特にリスナーの位置や向きを変更すると、1 つのフレームで大きく変化する可能性があります。 これにより、オーディオ カード/CPU は多くの不要な計算を実行するため、もう 1 つの迅速かつ普遍的な最適化は、いくつかのパラメーターの変更を延期し、フレームの最後にそれらをコミットすることです。

  または少なくとも、バッファーに対する個々の Set3DParamX 呼び出しではなく、 SetAllParameters を使用します。

  同様に、個々の Set3DParamX 呼び出しではなく、少なくとも 3D バッファーで SetAllParamenters 呼び出しを使用する必要があります。 可能な限り、システム呼び出しを最小限に抑えるようにしてください。

• 冗長な呼び出しを行わなわず、再生呼び出しのリストを保存して並べ替えます。 多くの場合、1 つのオーディオ更新フレームには、新しいサウンドを再生するための 2 つの要求があります。 要求が到着した時点で処理される場合は、最初の新しいサウンドを開始し、2 番目の要求されたサウンドをすぐに置き換えることができます。 これにより、冗長な計算、不要な再生呼び出し、不要な停止呼び出しが発生します。 リストを並べ替え、再生を開始する必要がある音声のみが実際に再生されるように、新しいサウンドの再生要求のリストを格納することをお勧めします。

  また、各サウンド ソースの 3D および EAX パラメーターのローカル コピーを格納する必要があります。 パラメーターを特定の値に設定する要求が行われた場合は、値が実際に最後の値セットと異なるかどうかを確認チェック。 そうでない場合は、呼び出しを行う必要はありません。

  オーディオ カード ドライバーは、おそらくこのシナリオを検出し、(同じ) 計算をもう一度実行しませんが、オーディオ呼び出しは (リング遷移を介して) オーディオ ドライバーに到達する必要があり、これは既に低速な操作です。

オーディオをバッファーにストリーミングするときは、書き込み後カーソル (AWC) と再生前カーソル (BPC) の 2 つの基本的なアルゴリズムがあります。 AWC はグリッチを犠牲にして待機時間を最小限に抑えますが、BPC は逆です。 通常、ストリーミング サウンドに対話型の変更がないため、この種の待機時間はゲームや同様のアプリケーションにとってほとんど問題ではないので、BPC はより適切なアルゴリズムです。 AWC では、ストリーミング スレッドが実行されるたびに、ループ内のデータが書き込みカーソルを超えて最大 N ミリ秒 (通常は N=40 など) までバッファーに "トップアップ" されます (Windows スケジューリング ジッターを可能にします)。 BPC では、常にできるだけ多くのデータをバッファーに書き込み、再生カーソルまで入力します (または、再生カーソルの進行状況を誤って報告するドライバーを許可するには、おそらく 32 バイト前)。

BPC を使用してグリッチを最小限化し、ゲームがテスト ハードウェアでグリッチにならない場合でも、バッファーを 100 ミリ秒以上使用すると、そこにあるコンピューターでグリッチが発生します。

一部のハードウェア (Play() 呼び出しが特定のオーディオ カードで長い時間がかかる) の場合は、起動時の待ち時間 (上記のストリーミング待ち時間とは異なる) が問題になる可能性があります。 この待ち時間を本当に短くしたい場合は、ツイッチの音 (銃のショットや足跡など) の便利なトリックは、一部のバッファーを常にループして無音で再生することです。 ツイッチ音を再生する必要がある場合は、フリー バッファーを選択し、その書き込みカーソルがどこにあるかを確認し、書き込みカーソルのすぐ後のバッファーにサウンドを入れます。 一部のオーディオ カードは、サポートされていることがわかっている遅延プロパティの QuerySupport に失敗します。 回避策はありますか? プロパティの非遅延バージョンに対して QuerySupport を実行するだけで、遅延設定を使用できます。 最新のオーディオ カード ドライバーもこの問題を解決する可能性があります。

Windows Media Encoder 9 シリーズのドキュメントを参照してください。

DirectSound は MP3 デコードをネイティブにサポートしていません。 (DirectShow フィルターの ACM コーデックを使用して) ファイルを事前にデコードすることも、DirectShow 自体を使用するだけで、デコードを行うことができます。その後、結果の PCM オーディオ データを DirectSound バッファーにコピーできます。

NURBS はサポートされていません。 ポリゴン メッシュに変換できます。

SUBD はサポートされていません。 ポリゴン メッシュに変換できます。

プレビュー ウィンドウは、最も厳密な意味でアニメーション化されていません。 アニメーションを再生するのではなく、Maya のシーンの最新の状態に同期しています。 アニメーションをエクスポートすると、各変換の行列がスケール、回転 (四元数)、および平行移動コンポーネント (多くの場合、SFT と呼ばれます) に分解されます。 SRT が行列よりも望ましいのは、正しく補間され、よりコンパクトな形式のデータが提供され、個別に圧縮できるためです。 すべてのマトリックスが SRT に分割できるわけではありません。 分解できない場合、結果の SRT は不明になるため、アニメーションの小さなエラーも検出される可能性があります。 分解中に最も頻繁に問題が発生する Maya の 2 つの特徴は、せん断と偏心回転またはスケールです。 この問題が発生した場合は、偏心回転またはスケールを使用しているため、階層レベルを上げる変換を追加することを検討してください。

D3DX アニメーションで SRT がサポートされている場合、次のようになります:

[S]x[R]x[T]

Maya のマトリックスははるかに複雑であり、大量の追加プロセスが必要です。これは次のようになります:

[SpInv]x[S]x[Sh]x[Sp]x[St]x[RpInv]x[Ro]x[R]x[Rp]x[Rt]x[T]

現時点では、Maya のリジット スキンはサポートされていません。 スムーズ スキンを使用してください。

X ファイルは IK をサポートしていません。 代わりに、IK ソリューションは X ファイルに格納されているフレームにベイクされています。

現在、Maya 用 DirectX 拡張機能では、プレビューおよびエクスポート用の DirectXShader マテリアルのみがサポートされています。 将来のバージョンでは、他の資料がサポートされる可能性があります。

はい。ただし、同じ軸として機能します。 そのため、DirectInput を使用してトリガーを個別に読み取ることはできません。 XInput を使用すると、トリガーは個別の値を返します。

DirectInput がトリガーを 1 つの軸として解釈する理由の詳細については、「DirectInput でのコントローラーの使用」を参照してください。

XInput では、一度に 4 つのコントローラーが接続されています。

いいえ。そうではありません。

はい。DirectInput を介して一般的なコントローラーにアクセスできます。

XInputSetState 関数を使用します。

ヘッドセットを接続すると、コントローラーのヘッドセットは標準の USB オーディオ デバイスとして機能するため、接続されると、Windows はこの USB オーディオ デバイスを既定として使用するように自動的に変更されます。 ユーザーはすべてのオーディオがヘッドセットを通過することを望まない可能性があるため、手動で元の設定に戻す必要があります。

コントローラーのライトはオペレーティング システムによって事前に定義されており、変更することはできません。

申し訳ございません。このボタンは今後使用するために予約されています。

ドライバーは Windows Update から入手できます。

XInput の起動時に、ID は XInput エンジンと接続されているコントローラーによって非確定的に決定されます。 XInput アプリケーションの実行中にコントローラーがプラグ インされている場合、システムは新しいコントローラーに使用可能な最小数を割り当てます。 コントローラーが切断されると、その番号が再び使用可能になります。

XInputGetDSoundAudioDeviceGuids 関数を使用します。 詳細については、AudioController のサンプルを参照してください。

コントローラーがプレイヤーによって使用されていた場合は、コントローラーが再接続され、プレイヤーがボタンを押して、一時停止を解除する準備ができていることを通知するまで、ゲームを一時停止する必要があります。