ビデオカードの機能を抽象化したオブジェクト
…というと分かりづらいけれど、つまり、画面に関わることを一手に引き受けてくれるオブジェクト。TDGCaradオブジェクトは内部的にこれを生成したり解放したりします。
画面モードを変える時には、画面のサイズやピクセルフォーマットといった、画面モードごとに異なるパラメータでDirect3DDeviceを生成しなおさなければなりません。つまり、それまで使っていたDirect3DDeviceは無くなります。
テクスチャ(TDGTextureでカプセル化されている、IDirect3Dtexture8)などは実際にはDirect3DDeviceに依存しているので、こいつらも一旦全部消去されますが、再生成するのに必要な情報(例えばテクスチャの内容や、テクスチャのサイズ)を一旦退避して、新しいDirect3DDeviceに合わせてテクスチャを再生成する機能が、TDGTextureに備わっています。
つまり、D3DDeviceが生成されたり解放されたりする、という事はDGCaradユーザが意識する必要はあまりないのですが、自分でDGCaradリソースを設計する場合などに、この事は知っておく必要があります。
DGCaradリソースとは、Direct3DDeviceの状態の変化 (画面モードが切り替わったとか、フルスクリーンでの実行中にフォーカスを変えられたとか) による影響を考慮しなければならないオブジェクトの事です。
Direct3DDeviceの状態の変化によって生じる、以下の４つのイベントを受け取ることが出来ます。
| OnCleanup | 画面モードの切り替え時、DGCaradオブジェクトの解放時など、使用中のDirect3DDeviceを解放する直前に発生します |
| OnRecover | 画面モードの切り替え後、新しくDirect3DDeviceを生成しなおした直後に発生します |
| OnReset | Direct3DDeviceがリセットされる直前に発生します |
| OnAfterReset | Direct3DDeviceがリセットされた直後に発生します |
参考 : TDGCarad.RegisterResource デバイスのロスト
Direct3Dにおいて、頂点データというものは、一通りではありません。
位置、法線ベクトル、色、テクスチャ座標などなど、１つの頂点に持たせたい情報は山とありますが、全部持たせてしまうと、超巨大な頂点データが出来上がってしまうことは想像に難くありません。
そこで、Direct3Dでは、そうした情報のうちどれが必要なのかをフラグで指定して、新しい頂点フォーマットを各プログラマで作ることが出来ます。これが、Flexible Vretex Formatという考え方です。
「どういうフラグがあるのか」、「新しい頂点フォーマットをどうやって定義するのか」という事の詳細については、DirectX SDKのヘルプをご覧ください。日本語版DirectX8.0 SDKのヘルプでは、「DirectGraphicsの使い方 → 頂点フォーマット → 頂点フォーマットについて」の項にあります。
FullScreen Anti-Aliasing の略。
ポリゴン使ったゲームって、ポリゴンのエッジのギザギザが気になることがありますね。これを低減する技法のひとつがFSAAです。
まず、実際に表示されるより大きな (画面に対して2x2倍とか4x4倍とか) 仮想画面を用意して、大きな画像をレンダリングします。その後、実際の表示の際に、仮想画面の複数のピクセルから、実際の画面の１ピクセルの情報を計算します。例えば、仮想画面の2x2ピクセルの色情報の平均値を実際の画面の１ピクセルにします。こうする事で、同じCRTの解像度でレンダリング結果の品質向上が図れるというわけです。
QuadrupleD Archiveの略。
ゲームなどを作ると、どうしてもBMPファイルやWAVファイルの山が出来ますが、Quadruple Dでは添付のArchiver.exeで、ファイルを圧縮、ひとまとめにしてコンパクトに配布が出来るようになります。
そうして作ったファイル内のデータは、TDGTexture.LoadFromFileメソッドなどで普通のファイルとほぼ同様に読み込むことが出来ます。
メッシュを表現するためには、
が必要です。
このうち、頂点データの塊をDG-CaradではVertexBuffer(頂点バッファ)として格納し、頂点インデクスの塊をIndexBuffer(頂点インデクスバッファ)として格納することが出来ます。
「なんでいちいちクラスを使うの？配列とかの方が書き換えるときとか便利じゃない」と思うかもしれません。しかし、VertexBuffer、IndexBufferの内容は、ビデオカードのドライバにとって、一番アクセス効率の良い部分に置いてもらえます。特に、ハードウェアで頂点の座標変換や照明演算を行ってくれるビデオカードならば、配列、つまり低速なシステムメモリに置かれた頂点データや頂点インデクスをレンダリングの度にいちいちビデオカード側に渡さなければならないとすると、相当な無駄であるというのは想像に難くないですね。
DirectX SDKによれば「ディスプレイメモリ上の連続した領域」との事です。確かにその通りなんですが…(^^;)
２次元のバッファで、バックバッファやデプスステンシルサーフェスなど、色々な用途があります。色々使えるから、説明しづらいというのはあるのかも〜
CRTディスプレイの画面の内容はプライマリバッファの内容にしたがって、電子銃によって左上から右下に、いつも書き換えられています。そして、一番右下まで電子銃が行き着くと、また左上に戻って書き換えを始めるわけです。
この電子銃が画面の右下から左上に戻っている、画面の書き換えが一切起こらない期間の事を、垂直帰線期間(垂直ブランク状態)といいます。
LCDの場合でも同様に、ハードウェアによる画像の書き換えが起こっている期間、起こらない期間というものが存在します。
DGCaradでは、画面の書き換えの際ちらつきを押さえるために、表示用と、書き換え用に、２枚のスクリーンを持つ事が可能です。これがダブルバッファリング。 ３枚ならば、トリプルバッファリング。
画面に見えているバッファ(プライマリ・サーフェス)と、書き換え用のバッファ(バックバッファ)を持ち、書き換えが完了し次第、バックバッファとフロントバッファを入れ替えます(スワップ…TDGCarad.D3DDevice.Presentメソッドによって、実行されます)。
この入れ替え作業は、単にバックバッファの内容をプライマリサーフェスに転送するだけという事にも出来ますし、垂直帰線期間を待って行って見た目上、(理論的には)全くちらつきの無い美しい描画を可能にしたりといった細かい設定が可能です。この設定のことを、スワップエフェクトと呼びます。
なお、TDGCaradでは、バックバッファにはTDDDD.BackBuffersプロパティでアクセス出来ます。プライマリサーフェスへの直接アクセスは、DirectX8から出来なくなりました。
ビデオカードの事。TDGCarad.D3D.GetAdapterCountの返り値の数だけシステムにはビデオカードがインストールされていることを知ることが出来、複数枚ビデオカードがあるという羨ましい環境では、どれを使うかを0から始まる通し番号で設定します。ちなみに、デフォルトのビデオカードを示す、D3DADATER_DEFAULT は 値0 です。
尚、DG-Caradでは、同時にひとつのディスプレイアダプタのみ扱えます。いわゆるマニチモニタ専用のアプリケーションは書けませんので悪しからず。 マルチモニタデバッギング目的で、「右のディスプレイだけを出力先にしたいんだけど…」といった場合への対処は出来るので、よしとしてください。
フルスクリーンモードで実行中に、Alt + Tabが押されるなどしてアプリケーションのフォーカスが失われると、Direct3DDeviceが「ロストした」状態になります。この時、TDGCarad.D3DDevice.TestCooperativeLevelメソッドは、D3DERR_DEVICELOSTを返します。
この状態では、Direct3DDeviceに対する操作は、IDirect3DDevice.TestCooperativeLevelと、解放処理を除いて一切行えなくなりますので、レンダリングなどは行わないでください。つまり、アプリケーションはレンダリングにかかる前に、いつもTestCooperativeLevelでデバイスの状態をチェックする必要があります。
フォーカスが復帰すると、TDGCarad.D3DDevice.TestCooperativeLevelメソッドはD3DERR_DEVICENOTRESETを返すので、TDGCarad.Resetメソッドを用いてデバイスの復帰を行ってください。この時、内部的にDGCaradリソースの復元も自動的に行います。
以前、Zバッファと呼ばれていた物の進化形であり、デプスステンシルサーフェスとは、デプスバッファとステンシルバッファを合体させたものです。
デプスステンシルサーフェスは、これら二つのバッファを同居させたものです。「同居」というのは、上位８ビットがステンシルバッファで、下位２４ビットがデプスバッファというように、物理的なメモリ空間内で混載されているからです(詳しくはD3DFORMATの項を参照するとよいでしょう)。扱う上では、デプスステンシルサーフェスを直接アクセスしたりしない限り、別個のものと考えても差し支え有りません。
CPUではなく、ビデオカード側で頂点に対しての座標変換や、照明についての計算を行ってくれる、素敵な機能のことです。
2002年1月現在、ハードウェアT&Lに対応したビデオカードも大分浸透してきたという感じでしょうか。
デプススステンシルサーフェスによるポリゴンの前後関係の解決というのは、万能では有りません。
デプススバッファによる描画が破綻する良い(悪い？)例が、半透明体の描画です。半透明体は、奥が「透けて」見えなくてはならないので、デプスバッファを用いつつ、手前→奥の順で半透明体を描画した場合、手前の半透明は、奥の半透明体を透けて見せずに、完全に隠してしまう事になります。
そこで、半透明体を混在したシーンのレンダリングには、
という手順を踏むことで、正しく半透明体をシーンへ書き入れる事が可能になります。
ちなみに、SXLibではそうした半透明体の仕分け・ソート作業をTSXSceneによって内部的に処理しています。
煙などを画面に表示するとき、一枚のポリゴンに煙を描いたテクスチャを貼って表現したとすると、そのままでは煙を横から見ようとすると、ペラペラの煙が表示されてしまう事になります。これはマズい。そこで、ビルボードの出番です。
ビルボードは、視点に対して一定の向きで描画されるポリゴンを指します。煙の描画や、背景の木の描画などに使用すると効果的です。
英語で「網細工」の意。
ポリゴンモデルの形状データの事をSXLibではこう呼びます。
一個のメッシュは、一組の頂点と頂点インデクスで表現されます。