エントリー
こんにちはハブラ
前の記事で、 VLCに基づいたプレーヤーの開発について話し始めました。 この記事では、プレーヤーを作成するときに直面しなければならなかった主な側面と困難について説明します。 メインプログラムウィンドウは次のようになります。
プログラムのメインウィンドウ
Direct3Dを使用してフレームを画面にレンダリングする
したがって、すでに述べたように、LibVLCライブラリは、VLCプレーヤーの主要部分であるストリーミングビデオのデコードに使用されます。 VMemプラグインを使用すると、さまざまなフィルターを適用してビデオストリームをデコードし、最終的にユーザーのメモリ領域に保存できます。 画像の出力を高速化するために、Direct3D 9を使用しました。Direct3Dには、表面とテクスチャの概念があります。 表面は、幅x高さを測定するバイトの配列です。
表面スケッチ
つまり 基本的に表面はビットマップです
テクスチャは、プリミティブ（ポリゴン）に「重ね合わせ」られるという点で表面とは異なります。 テクスチャにはミップマップレベルもあります-テクスチャのコピーの削減（3Dグラフィックスで使用）
画面にフィルムフレームを表示するには、オフスクリーンサーフェスを作成し、メモリ領域へのポインタをVMemプラグインに転送してから、サーフェスをテクスチャにコピーし、テクスチャを伸ばした長方形を描画する必要があります。 概略的には、これは次のように表すことができます。
描画プロセス
Direct3Dのサーフェスおよびテクスチャへのアクセスの特性により、サーフェスのテクスチャへの中間コピーが必要です。
レンダリング中の括弧内の数字はテクスチャ座標であり、テクスチャがプリミティブにどのように重ねられるかを示しています。
マルチスレッドとウィンドウストレッチングの問題
ウィンドウを引き伸ばす場合、レンダリングに使用されるバックバッファは同じサイズのままであるため、ウィンドウのサイズを変更する場合、画像は引き伸ばされてぼやけます。 これを防ぐには、バッファを再作成する必要があります。 Direct3Dでは、これはIDIrect3DDevice9 :: Resetを呼び出すことで実行されます。 同時に、バッファを正常に再作成するための前提条件は、ビデオメモリからすべてのリソースを削除することです。 また、LibVLCは別のストリームで動作し、ビデオサーフェスにデータを書き込むため、ミューテックスまたはセクション（より便利な方）を同期する必要があります。
レンダリングの問題も解決する必要があります。 ビデオのレンダリングに加えて、アプリケーションには25フレーム秒を超える頻度でアニメーション化する必要がある要素があったためです。 この方法で実装できます。レンダリング中のGUI要素により、ビデオストリームだけでなくウィンドウも再描画されます。 または、ウィンドウは単純なアプリケーションで常に再描画されます（ゲームで行われているように）。 最初の方法では、ビデオをデコードするストリームは、アプリケーションを再描画する必要があるメインストリームにメッセージを送信する必要があります。これにより、さらにメッセージキューがロードされます。 2番目の方法では、メッセージを送信する必要はありません-アプリケーションは常に再描画されます。
ユーザーインターフェース
すべてのボタンとその他のコントロールは、テクスチャが引き伸ばされた半透明のプリミティブを表示することにより描画されます。 各要素には境界ボックスがあり、クリックすると、「接続された」スロットが目的のアクションで呼び出されます。
動的スクロール技術が伝送チャネルに使用されました。
スクロールには「動的スクロール」が使用されます。
スクロール技術は非常に簡単です。特にインターネットでは、この効果の実装に関する多くの記事があります。
ユーザーインターフェースについて言うことはありませんが、テレビ番組の「フェード」名などのいくつかの効果について頭を悩ませる必要がありました。
おわりに
どのように試してみても、私の考えのプレゼンテーションはかなり厄介であることが判明しました-私は多くのことについて話をしたかったのですが、同時にDirectXでアプリケーションを書く方法についてTalmud全体を書きませんでした。 質問や提案がある場合-私はうれしいです！
PS（編集:)最初に写真がドロップボックスにアップロードされたため、アカウントがブロックされました。 ソースファイルは保存されなかったため、回路を再描画しました。