プログラミング一覧

DirectX12 フルスクリーンの罠

DirectX12 でフルスクリーン描画を行おうとしたときに、予想外に色々と苦戦しました。
DirectX12 というよりは、フルスクリーンは DXGI の機能・制御管轄なので、もしかすると今回の話は DirectX11 でも症状が出るのかもしれません。もしかすると環境要因もあるのかもしれませんが、何かの参考になれば幸いです。

出遭ったこと

「ALT+ENTER でフルスクリーンとウィンドウモードを行き来(切り替え)をしたい。」
これを実現するのに苦戦しています。

ディスプレイの解像度に対してのフルスクリーンとウィンドウモードの切り替えは、標準 DXGI の機能で問題なく出来ました。
ですが、描画の内容によっては指定された解像度でフルスクリーンとしたいことがあり、描画ターゲットの解像度を変えるのでは無く、ディスプレイの解像度設定のほうを変更したいという条件になります。

これには初期化時に DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH フラグを設定しますが、これがあると色々と問題に出遭いました。

続きを読む


Vulkan での排他フルスクリーン

Vulkan でフルスクリーンアプリケーションを作ろうと思ったら、全画面のウィンドウを枠なしで作るという方法でした。
いわゆる仮想フルスクリーンの手法です。OpenGL でもフルスクリーンのアプリケーションは同様の手順で作るので、特に違和感はありませんでした。
ただ、DirectX9 時には専用のフルスクリーン設定がありましたし、9.0c 以降では DXGI がそのあたりの設定を引き受けてくれていました。

VK_EXT_full_screen_exclusive

しかしつい最近に Vulkan にも排他フルスクリーンの拡張が用意されました!
それが VK_EXT_full_screen_exclusive です。紹介文を軽く読むと、ディスプレイのコンポジッタを迂回してフルスクリーン化が出来るようなので、画面表示完了までのレイテンシーは短くなるのではないかと期待です。

拡張そのものの説明は https://github.com/KhronosGroup/Vulkan-Docs/blob/master/appendices/VK_EXT_full_screen_exclusive.txt に記載されています。

NVIDIA の環境では、 Windows 版だと 425.89, Linux 版だと 418.52.14 のドライバでサポートされるようです。ただどちらもまだベータドライバなのでその点には注意が必要です。
RADEON の環境では、Adrenalin 2019 19.6.2 から対応されて居るみたいですね。

最近は不安定なドライバを入れて実験する時間がないので、安定版になってから試してみようと思います。


Git LFS について(オブジェクトとロック)

以前に 「Git LFS を使ってみる」という記事を書いたのですが、現在のものと少し合わなくなってきている感じがしたので書き直しました。
Git LFS が出始めの頃と比較すると利用できる環境は格段に増えています。

Git LFS について

出始めの頃は別パッケージとしてインストールが必要でしたが、現在は Git for Windows の中に含まれています。
Git LFS は、指定されたファイルタイプ(拡張子による設定など)によって、特別な処理を行いバージョン管理させる仕組みとなっています。
具体的には、比較的ファイルサイズが大きくなるバイナリファイルを対象に指定して、バイナリファイルへのリンク情報をテキストの形にして git によるバージョン管理に載せる動きとなります。
リポジトリ上では、バイナリファイルは git の標準のデータ構造とは別の場所に格納されていたりします。

現在においては、各種 git リポジトリサービスが、この Git LFS に対応しています。

  • GitHub
  • GitLab
  • GitBucket
  • GitBlit
  • Bitbucket
  • Azure DevOps

ただ Git LFS にもバージョンがあり、現時点においては git-lfs のバージョンは 2.7.2 となっています。この過程で Git LFS の通信プロトコルにも拡張が入ることがあり、機能が増えたり、作業の改善があったりとします。
例えば初期では LFS 対象のバイナリファイルが1つずつしかダウンロード出来ていなかったのが、複数を並列でダウンロード出来るようになったりしました。
こういった点より、リポジトリサービスを提供するアプリケーションもバージョン更新が定期的であることが理想的です。GitBlit はかなりの間、バージョン更新が無いようなので利用はあまりオススメできないかと思います。

続きを読む


OpenGL で描画先独立なブレンディング設定を使う

OpenGL でデュアルソースブレンディングを使うと、出力先カラーバッファが1つになってしまう!という話を聞いて、「1つのカラーバッファに2色出力し、ブレンド設定でさらに演算」という場面ってどのくらいあるのだろうと疑問に思いました。(おそらくデスティネーション色と処理したいのでしょうが)。
そんな中、Multiple Render Target (MRT)で、各カラーバッファのブレンディング設定は独立に出来たはず、と思うことがあったので使い方を確認してみました。
ちなみに、DirectX11 ではカラーバッファのブレンディング設定の独立(個別)は簡単にできます。D3D11_BLEND_DESC構造体を見るとすぐに分かります。

結果としては、 OpenGL でもこのようにブレンディング設定を変えて描画できます。

続きを読む


RDPでGraphicsAPIは実行出来るか実験

前回、RDP で OpenGL アプリを起動させる方法を考えましたが、そもそも他のグラフィックスAPIではどうなのか、気になってきたので調べてみました。

RDP で動作するか?

  • OpenGL : 動作しない
  • DirectX11 : 動作する
  • DirectX12 : 動作する
  • Vulkan : 動作する

まさかの OpenGL だけが動作しないという状況だったようです。確認したのは、2台とも Windows10 1809 の環境で、デスクトップPCとノートPCという構成でした。
低レイヤーグラフィックスAPIのDirectX12/Vulkan らが RDP 経由でも使えたという点で驚きました。画面を単なる画像として送るなら、これらの動作に納得もあるのですが、かつては DirectX9 や OpenGL がリモートデスクトップ環境下で動かなかった時代を味わったために動作しないという思い込みがあったようです。

プログラムコードで考えてみると、デバイスコンテキストが不要な API だと動作しているようですね。あとは、画面ロック・UACの暗転でいわゆるデバイスロストが発生しない時代になってきたから、というのもありそうです。


リモートデスクトップで OpenGL アプリを操作したい

Windows のリモートデスクトップで OpenGL を使用したアプリケーションの起動は出来ないことは、経験上知っていたのですが、OpenGL アプリを起動した状態で、リモートデスクトップ接続すると問題なくアプリが使用できる、という話を聞きました。

RDP接続後にOpenGLアプリを起動したい

事前にOpenGLアプリを起動した状態で、他の端末から RDP で接続すれば問題なくアプリは操作できますが、事前に起動しておくことが不可能な時もあります。
また、アプリケーションを終了してしまって、再度起動したいということもあると思います。

このようなときには、 tscon コマンドを使うとよいようです。
このコマンドを用いるとセッションを切り替えることができるようなので、一度物理的なコンソールを持つセッションに切り替えてアプリケーションの起動をする、という方法が使えます。このときに、一度リモートデスクトップは切断されてしまいますが、再接続すればアプリケーションが起動した状態から再開できます。

アプリケーションの起動をするまでを次のような内容でバッチファイルにして、起動する際にはこのバッチファイルを実行するようにします。

実行する際には、管理者権限ありのコマンドプロンプトで実行してうまくいきました。一般権限のコマンドプロンプトだと、このままのバッチではうまく動作しない可能性があります。

他にもセッションのIDが必要な場面では、 “query session” を実行してみて、どのようなセッションが生きているかを見てみるのもよさそうに思います。


VisualStudio の HLSL テンプレートがおかしい その2

以前に、 VisualStudio の HLSL テンプレートがおかしい として、修正したシェーダー用のプロジェクトテンプレートですが、 Visual Studio 2017 の更新をしたら、また妙な状況になってしまったようです。
もしかすると、先の手作業の修正が引き金で新規にインストールした場合には、おかしな構造ながらも正常に動くのかもしれません。

続きを読む


Visual Studio Graphics Debugger の終了

Windows 10 October 2018 Update (1809) で、 Visual Studio 2017 の Graphics Debugger が正常に動かなくなりました。最近は Vulkan を勉強していることが多く、 VS の Graphics Debugger は使っていませんでした。再び D3D12 の勉強を再開した今日、この問題を発見しました。

最初は、今の D3D12 のために、色々と新しいインターフェースを使ったのが問題で失敗したのだろうと考えていたのですが、どうやらそうではないようです。
仕様として 1809 バージョンの上では VS 付属 Graphics Debugger は使えないということになったようです。

続きを読む


VisualStudio の HLSL テンプレートがおかしい

15.8.x のどこかのバージョンから、以下のようにシェーダーの作成の項目が減ってしまいました。
(自分の記憶では、15.8.1 の時点では大丈夫でした)。 この画面は 15.8.5 のものです。
本来ならば、ここに頂点シェーダーやピクセルシェーダー、ハルシェーダーといった項目も出現していなければなりません。

この問題を解決する方法がわかったので、これについて説明します。
なお、Professional 版、 Community 版ともに同じ問題を抱えているようです。

続きを読む


Caliburn.Micro に入門してみる その3

前回は簡単にバインディングができることを確認しました。実はあれは省略形に近いものだったので、フルに設定するとどのようになるかを今回確認します。
基本的に前回のプロジェクトの使い回しで説明します。

メソッド呼び出し

ボタンの Name を削除して、 Interaction.Triggers を指定してメソッドを呼び出してみます。

ShellView.xaml は以下のように変更します。

EventTrigger の Click までは問題ないとして、 Livet では CallMethodAction を呼び出していたような箇所で、 ActionMessage によってメソッドを呼び出します。
この ActionMessage も引数情報を設定することが可能です。パラメータを指定するには以下のようにします。

これを受け取るための IncrementCount メソッドでは引数を取れるように変更する必要があります。忘れると例外(No target found for method IncrementCount.)が飛びます。

メソッド呼び出し その2

ここまでの設定方法が Long Syntax と呼ばれるものになっているようです。次に Short Syntax と呼ばれるものについて確認してみます。

ShellView.xaml を編集してボタンを追加してみます。

見て分かるように、 cal:Message.Attach という添付プロパティでイベントとアクション(メソッド呼び出し)を設定しています。
注目なのはイベント名の記述と、メソッドの呼び出し&引数記述がこのように書ける、という点です。わかりやすいですね。

引数については即値で書いていますが、ここを他のコントロールの値にすることも可能です。

さらに Caliburn では、メソッド引数名から、引数を推測してバインディングしてくれる機能もあります。
以下のように ShellView.xaml を編集して、スライダとボタンを用意してみます。

スライダの名前を IncrementCount の引数名である delta としたことで、 Caliburn が情報をうまく解釈して結合してくれます。

まとめ

自分でバインディング設定を記述しないでもバインディングしてくれることで、プログラマの作業を省力化してくれる感がすごくあります。
ただし、ルールを知らないと動きを追いかけるのも厳しいという印象です。

これらのバインディングについては、 All About Actions を参照して読んでおくのもよさそうです。
パラメータとして、 $source, $view, $dataContext といったものも設定可能であったりするので、なかなか深いです。