高レベルVCL / LCLコンポーネントライブラリでDirect3Dを使用する

この出版物は、Microsoft DirectXグラフィックライブラリの使用を希望するコンピューターグラフィックプログラミングの分野の初心者を対象としています。 すぐに予約する：
-取り上げられているトピックはおそらくOpenGLにも当てはまりますが、経験的に（OpenGL用のアプリケーションを作成することにより）テストしていないため、タイトルにはDirect3Dのみを記載しています。
-ここに記載されているコード例はDelphi / FreePascal言語に関連していますが、リストされた「レシピ」はターゲットOS（Windows）内で広く使用されています-それらはあらゆるプログラミング言語に適用でき、VCL以外のコンポーネントの高レベルライブラリにも適用できます（Delphi）およびLCL（Lazarus）;
-この出版物は、Direct3Dワイヤフレームアプリケーションの作成と、DirectXおよびOpenGLグラフィックライブラリを操作する方法のトピックについては扱っていません。 これらはすべて他のソースで十分にカバーされており、これに追加するものはほとんどありません。

だから、トピックに近い。 3次元グラフィックスを使用してアプリケーションを開発し、教育用（さらに機能する）アプリケーションのフレームワークを構築する場合、通常、純粋なWin32 APIを使用することをお勧めします...

問題の紹介

純粋なWin32 APIを使用する場合、受信ウィンドウメッセージの処理サイクルは「手動」で記述する必要があり、通常は次のようになります。

repeat if ( PeekMessage(msg, 0, 0, 0, PM_REMOVE) ) then //   -    -     begin TranslateMessage(msg); DispatchMessage(msg); end //      3D- else RenderScene(); //         until ( msg.message = WM_QUIT ); 

このコードを使用すると、 無限のレンダリングサイクルを実装できます。このサイクルでは、ほとんどの場合、前のフレームの直後に次のフレームが描画され、アニメーションが画面に正しくスムーズに表示されます（グラフィックパフォーマンスが十分な場合）。

ただし、VCLやLCLなどの高レベルコンポーネントライブラリでは、プログラマがそのようなメッセージ処理サイクルを実装する必要はありません。 彼らの腸には、すでに何らかの形でそのようなサイクルの実装がありますので、これらのライブラリを操作する原則に違反せずに無限のレンダリングサイクルを実装し、同時にこれらのライブラリのすべてのバインディングコードの正しい動作を確保する方法が問題になりますか？ この質問を、私自身の理解の範囲内で将来的に説明するつもりです。

例外マスキング余談

通常、Direct3Dを使用してLazarusでコンパイルされたプロジェクトを起動できず、浮動小数点計算に「うなずく」プログラムの起動時に例外を安定して受信できなかったとき、私は驚きました。 問題の調査にしばらく時間を費やしたが、この問題に関するインターネット上の直接的な情報は見つかりませんでしたが、Delphiで64ビットアーキテクチャ用にプロジェクトをコンパイルすると、実行時に非常によく似たエラーが発生します。 Delphiのデバッグモードウィンドウの内容を調べると、プロセッサのFPU拡張では、考慮されるすべてのケースでMXCSR例外マスクレジスタの意味が異なることがわかりました。 その後でも、価値のあるものをグーグルで検索することはできませんでした。ただし、標準のDelphiパッケージのOpenGLモジュールには、「初期化」セクションにすべての可能なケースの例外のマスキングを設定する行が含まれています。

FPU例外のマスキングは、この出版物のトピックとは関係がないため、あまり注目しません。 最も単純な例を示します。非常に大きな浮動小数点数の乗算がオーバーフローを引き起こす場合、この場合、次の2つのいずれかが発生します。対応する例外のマスキングが有効な場合、乗算の結果はINFINITY（または-INFINITY）になります。 または、対応する例外のマスキングが無効になっている場合、プロセッサは浮動小数点オーバーフロー例外を生成します（この例外は、try exceptブロックのプログラムで処理する必要があります）。

その結果、標準OpenGLモジュールで行われたようにプロジェクトで例外マスクを設定しようとした後、Direct3DアプリケーションがLazarusとDelphi（64ビットプラットフォームを含む）の両方で問題なく動作することを確認しました。

残念ながら、MSDNや他のソースで見つけることができませんでした（恐らく見た目が悪いのでしょうか？）この方法と他の方法については、読者に次のコードをDirect3Dプロジェクトで書くことをお勧めします。

 uses Math; ... INITIALIZATION Math.SetExceptionMask([exInvalidOp..exPrecision]); END. 

マスキング例外には、考慮すべき特定の副作用があることに注意してください。 たとえば、ゼロで除算することが「可能」になります（たとえば、 ここでそのような問題が発生します ）。そのため、浮動小数点計算を実行する場合、中間結果を確認する必要があります。

ただし、浮動小数点の計算を実行する際に以前に慣れている例外的な状況を受け取りたい場合は、適切な場所で次のようなデザインを使用することを妨げるものは何もありません。

 var mask: TArithmeticExceptionMask; begin mask := SetExceptionMask([]); //   (   )   try //       finally SetExceptionMask(mask); //       end; end; 

これで、例外のマスキングの問題で終わります。

別の余談-なぜこれが必要なのですか？

高レベルのコンポーネントライブラリを使用してDirect3Dアプリケーションを作成するには、多くの目標があります。 たとえば、シェーダーやエフェクトなどの瞬間をデバッグします。 または、独自の3Dエンジンを作成していて、エンジンがリソースをロードしてシーンをレンダリングする定義ファイルエディターが必要な場合があります。 そのような場合、すぐに結果を確認できるようにし、必要に応じて、メニューバーやモーダルダイアログなどの「健全な」ユーザーインターフェイスを使用して、その場で何かを編集します。 など

この出版物では、メインウィンドウに単一の三角形を表示する（DirectX 11 APIを使用する）比較的基本的なプログラムを準備し、同時にシーンのレンダリングに使用される頂点シェーダーとピクセルシェーダーを編集および適用できます。 そのためには、アプリケーションのメインフォーム（複数行入力フィールドとボタン）に必要なコンポーネントセットを配置する必要がありました。 すぐに警告します-このプログラムは（この出版物のために）デモのみであるため、特別なことを期待しないでください。 ソースコードへのリンクは、この出版物の本文の最後に記載されています。

ここで余談が終わります。ここで主なトピックに進みます。

簡単な方法は、TForm.OnPaintイベント、Windows.InvalidateRect（）関数です。

高レベルのコンポーネントライブラリだけでなく、クリーンなWin32 APIにも精通しているプログラマーは、おそらく頭の中に単純なスキームを既に構築しているでしょう。「OnPaintと呼ばれるフォームイベントハンドラー（または別のコンポーネント）でDirect3Dシーンを描画し、レンダリング、Win32 APIからInvalidateRect（）関数を呼び出して、システムに新しいWM_PAINTメッセージを送信させます。これにより、OnPaintハンドラーが再度呼び出されます。残りの部分に反応することを忘れずに、無限のレンダリングサイクルを繰り返します。 TIONALメッセージ。 "

一般的に、そうです。

OnPaintハンドラーのサンプルコードプランを次に示します。

 procedure TFormMain.FormPaint(Sender: TObject); begin //  Direct3D- // ... //        IDXGISwapChain pSwapChain.Present ( 0, 0 ); //    WM_PAINT     InvalidateRect ( Self.Handle, nil, FALSE ); end; 

しかし、彼らが言うように、「紙の上では滑らかでした」。

何が起こるか見てみましょう（テキストの最後にソースコードへのリンクがあることを思い出してください-ダウンロード後、読者はサブディレクトリ「01-OnPaint + InvalidateRect」を見つけ、プログラムをコンパイルして実行し、サンプルが正しく動作しないことを確認できます）

問題1 ：Delphiでアプリケーションをコンパイルし、その後起動すると、Direct3Dシーンは期待どおりに描画されますが、ユーザーインターフェイスコントロールは正常に表示されません。 プログラムウィンドウの場所やサイズを変更するまで、ラベル、複数行編集フィールドの内容、ステータスバー、ボタンのいずれも正常に表示されません...まあ、スクロールと編集を開始すると、複数行編集フィールドはだいたい再描画されます内容、しかし全体的に結果は不満足です。 また、プログラムがプロセス内でダイアログボックス（または少なくともプリミティブなMessageBox）を開く場合、通常は閉じないか、画面に表示しません（スペースバーでメッセージボックスを盲目的に閉じますが、TFormから継承したダイアログウィンドウを閉じます）もうできません） この問題を説明するために、サンプルプログラムのメインメニューに「詳細->バージョン情報（MessageBox）」および「詳細->バージョン情報（TForm）」という項目を追加しました。

問題2 ：Lazarusでアプリケーションをコンパイルし、その後の起動時に、上記の問題（十分ではないかのように）に加えて、プログラムを終了できないことが追加されます-ヘッダーの標準の閉じるボタン（「X」）またはメニュー項目に応答しません「終了」...タスクマネージャの「ヘルプ」またはIDEの「Ctrl + F2」の組み合わせを使用せずにプログラムを終了するには、プログラムをタスクバーに最小化する必要があります（なぜだろうか？）ウィンドウを閉じるボタンをクリックした後。

最後の問題を取り除くには、実際には非常に簡単です。InvalidateRect（）関数を呼び出す前に、次のような条件を追加するだけです。

  if ( not ( Application.Terminated ) ) then InvalidateRect(Self.Handle, nil, FALSE); 

しかし、ここで最初の問題を解決するのはとても簡単です、悲しいかな、それは機能しません。

結論：この小見出しで説明されている方法は、Windowsウィンドウメッセージキューの通常の操作を中断し、多くのウィンドウメッセージが時間どおりに処理されないようにします。これは、コンポーネントの高レベルライブラリを使用する場合に特に顕著です（少なくとも、この時点でのバージョンのVCLおよびLCL出版）。

注：MSDNでは、 GetMessage関数の説明を見つけることができます。ここで、WM_PAINTメッセージは他のウィンドウメッセージと比較して低い優先度を持ち（WM_TIMERを除き、その優先度はさらに低い）、他のすべてのウィンドウメッセージの後に処理されます。

合計：彼らが言うように、事実は明らかです。 すべてのOSバージョンではない場合、少なくとも現在人気のあるWindows 7オペレーティングシステム（私はパブリケーションに添付されているすべてのサンプルプログラムを実行しました）では、WM_PAINTメッセージを処理する優先順位のある状況は、特にアプリケーションが高レベルのコンポーネントライブラリを使用するため、MSDNで指定された優先度に依存することはできません。

これで、無限のレンダリングサイクルを整理する次の方法に進むことができますが、別の短い余談、1つの小さな段落を作成します。

VCLおよびLCLライブラリは、TWinControlから継承したクラスで、Invalidate（）メソッドをプログラマに提供します。 VCLライブラリでは、その呼び出しは上記の純粋なWin32 APIのInvalidateRect（）関数の呼び出しに限定されますが、一般にこのメソッドの動作は特定のライブラリの実装に依存します。 そのため、LCLでは、このメソッドはRedrawWindow（）と呼ばれる別のWin32 API関数を呼び出します-この関数はほぼ同じ結果（新しいウィンドウレンダリングが実行されます）を提供しますが、微妙な違いがあります。 したがって、ニュアンスに焦点を合わせないために、すぐにWin32 APIからInvalidateRect（）関数を使用することを提案しました。

メソッドはより成功しています-Application.OnIdleイベントを使用します

前の方法は失敗するため、Windowsウィンドウのメッセージキューの通常の操作が中断されるため、他のすべてのウィンドウアプリケーションを処理した後、アプリケーションウィンドウのレンダリングを厳密に試みることは論理的です。 一見すると（少なくともライブラリの内部を詳しく見ていない場合）、このタスクはVCLおよびLCLライブラリの腸に隠れているウィンドウメッセージ処理サイクルを変更しないと不可能に思えるかもしれませんが、実際はそうではありません。

ApplicationオブジェクトにはOnIdleイベントがあり、新しいウィンドウメッセージがないことが検出されるたびに発生します。さらに、このイベントのハンドラーは、最終的に新しいメッセージが表示されるまで、このイベントをもう一度（ループで）処理することを報告できますメッセージ。 新しいメッセージが処理された後、Application.OnIdleイベントハンドラーが再び呼び出されます...など、アプリケーションが終了するまで続きます。 一般に、Application.OnIdleイベントは、独自のニュアンスはありますが、無限のレンダリングサイクルを整理するのに非常に適しています（このイベントの詳細については、使用している開発環境のヘルプを参照することをお勧めします）。

OnPaintハンドラーからInvalidateRect（）API関数の呼び出しを削除し、Application.OnIdleイベントハンドラーに転送できます。

結果は、次のようなコードになります。

 procedure TFormMain.FormCreate(Sender: TObject); begin Application.OnIdle := OnApplicationIdle; //    // ... end; procedure TFormMain.FormPaint(Sender: TObject); begin //  Direct3D- // ... //        IDXGISwapChain pSwapChain.Present ( 0, 0 ); //    WM_PAINT    —    OnApplicationIdle() end; procedure TFormMain.OnApplicationIdle(Sender: TObject; var Done: Boolean); begin if ( Application.Terminated ) //     or ( {  ,         } ) then begin //   ,    OnIdle() Done := TRUE; Exit; end; //   OnIdle()       Done := FALSE; //   WM_PAINT    InvalidateRect ( Self.Handle, nil, FALSE ); end; 

パブリケーションに添付されているソースで、サブディレクトリ「02-OnPaint + OnApplicationIdle」を見つけて、すべてのコントロールの内容をタイムリーに更新し、すべてのモーダルダイアログボックスを正しく表示することにより、プログラムの動作を改善できます。

上記にもう1つ追加します。プログラムウィンドウをタスクバーに最小化し、タスクマネージャーを開くと、プログラムが少なくとも1つのプロセッサコアを完全に「消費」していることがわかります。 。 このような場合にプログラムで他のアプリケーションにCPUリソースを割り当て、開いているモーダルウィンドウでグリッチを発生させないようにする場合（Lazarusでのみ見ました）、次の方法でApplication.OnIdleイベントハンドラーを変更できます。

 procedure TFormMain.OnApplicationIdle(Sender: TObject; var Done: Boolean); begin if ( Application.Terminated ) //     or ( Application.ModalLevel > 0 ) //    or ( Self.WindowState = wsMinimized ) //    or ( {  ,         } ) then begin //   ,    OnIdle() Done := TRUE; Exit; end; //   OnIdle()  Done := FALSE; //   WM_PAINT    InvalidateRect ( Self.Handle, nil, FALSE ); end; 

ただし、Application.OnIdleイベントが処理されても、完璧な無限のレンダリングサイクルを達成することは不可能です。 たとえば、ウィンドウのメインメニューが開いている場合、ナビゲーション中にApplication.OnIdleイベントは呼び出されないため、Direct3Dシーンのアニメーションは「停止」します。 プログラムがモーダルダイアログまたはメッセージボックスウィンドウを開いた場合も、同じことが起こります。

もちろん、そのような問題も克服できます。 たとえば、フォームにTTimerオブジェクトを配置し、50ミリ秒ごとに起動するように設定し、そのイベントハンドラーで同じInvalidateRect（）関数を呼び出します。メインメニューをナビゲートしてモーダルダイアログを操作するとき、ループレンダリングは作業を続けますが、これらの瞬間には、FPSと3Dシーン全体のレンダリングパフォーマンスを適切に評価することができなくなります。 ただし、ユーザーがメインメニューとダイアログボックスを開いた瞬間に興味を持つ可能性は低いため、無限のレンダリングサイクルの連続性に焦点を当てることはありません。 -シーン、そして残りはそれほど重要ではなく、読者に任されています-希望する人は、TTimerで自分自身で瞬間を実現し、これが期待どおりに機能することを確認できます。

別のコントロールで3Dシーンを描画する

プログラムウィンドウの一部がDirect3Dシーンのレンダリング用に予約され、その他がユーザーインターフェイスコントロール用に予約されている場合、プログラムウィンドウ全体にビデオメモリを割り当てることは完全には正しくありません。

パネル（または他のコントロール）を作成し、必要に応じてプログラムウィンドウと共にそのサイズを変更し（Alignプロパティを使用してコントロールサイズを自動的に調整すると便利です）、Direct3Dシーンをレンダリングするときに変換マトリックスで「シャーマニズム」を軽減する方が論理的です。

残念ながら、「パブリック」OnPaintイベントハンドラを持つTPanelのような標準の低機能コントロールを見つけることができなかったため、TCustomControl後継コンポーネント（他のクラスも使用可能）を実装し、Paint（）メソッドをオーバーロードする必要がありました。

このような実装は非常に簡単で、パブリケーションに添付されているソースコードには、サブディレクトリ「03-TCustomControl子孫」に同様の例が含まれています。

ウィンドウのレンダリング時にWindowsスキンとダブルバッファリングを使用する

パブリケーションに添付されているソースコードでは、Delphiプロジェクトの設定にマニフェストが含まれており、Windowsテーマをサポートしているため、Delphiでコンパイルされたプログラムのランタイムは完全にモダンに見えます。

Lazarusプロジェクトに関しては、そのようなマニフェストを設定することはできません。これは、残念ながら偶然ではありません。意図的に設定したので、その理由を説明します。

VCLおよびLCLコンポーネントライブラリは、ウィンドウのレンダリング時にダブルバッファリングを使用できます。 サンプルプロジェクトでは、ダブルバッファリングを無効にするFormCreate（）ハンドラーの行を見ることができます。
Direct3Dを使用してウィンドウを描画するときにダブルバッファリングを無効にすることが重要なのはなぜですか？ ウィンドウとコントロールの描画は、GDIツールを使用してこれらのライブラリによって実行されるためです。 また、サンプルプログラムのDirect3Dはウィンドウに直接出力し、「カスタム」ダブルバッファリングをバイパスするため、ダブルバッファリングがオンになっている場合、コンポーネントライブラリはオンスクリーンバッファに黒い長方形だけを受け取ります。オンスクリーンバッファには何もないためです。塗装済み！ したがって、ダブルバッファリングがオンになっている各描画では、次のシナリオが発生します。ライブラリは画面上のバッファを作成し、黒でクリアします。次に、OnPaint（）ハンドラは、Direct3Dを使用してシーンを描画し、コンポーネントのライブラリによって作成された画面上のバッファをバイパスして表示します...そして、OnPaint（）ハンドラーの実行後、コンポーネントライブラリは、Direct3Dを使用して受け取った画像の上に空のバッファー（黒い長方形）を描画します。その結果、ダブルバッファリングを有効にすると、非常に目立つ（まれに「フラッシュ」のある黒いウィンドウまで）ちらつきのプログラムウィンドウができます。これは、プロジェクトのFormCreate（）ハンドラーの対応する行を変更することにより、サンプルプログラムで確認できます。

おそらく、あなたはすでにそれについて考えました-すべてのサンプルプログラムでダブルバッファリングが無効になっている場合、どのような問題が発生する可能性がありますか？
教えてください-DoubleBufferedプロパティ（またはターゲットコントロール）がFALSEに設定されている場合でも、LCLコンポーネントライブラリを使用してLazarusで作成されたプログラムは、プログラムにWindows用のテーマがある場合（上記のマニフェストファイルを使用）、ダブルバッファリングを使用します。
これの証明は非常に簡単です。LCLライブラリのwin32callback.incヘッダーファイルに、WindowProc（）関数のコードに次の行があります。

 useDoubleBuffer := (ControlDC = 0) and (lWinControl.DoubleBuffered or ThemeServices.ThemesEnabled); 

条件の最後の部分に注意してください-利用可能なWindowsテーマでDoubleBufferedプロパティを無効にすることの無駄さを雄弁に説明しています。

DelphiのVCLライブラリについては、スキンの使用時にダブルバッファリングなしで実行できます。VCLの腸からの同様の行は次のとおりです。

 if not FDoubleBuffered or (Message.DC <> 0) then 

これですべてです。ご清聴ありがとうございました。
材料への有用な追加と建設的な批判がコメントで待っています。

ソースコード

この出版物のサンプルプログラムは、次のリンクから入手できます：
github.com/yizraor/PubDX_VCL_LCL