なんとなく読みたくなって狂気太郎作品を読み返していた。

---

作ってるゲーム開発ライブラリについて、落ち着いて当時考えてた設計を思い返したらそこまで意味不明の構造ではなかったので、とりあえずちょっとづつ設計を整理し直していく方針にした。

描画対象と描画方法をそれぞれrender_targetとrendererというオブジェクトとして抽象化しているのだが、現状render_targetはウィンドウが元になることが前提になっている。しかし将来的には画像データへのレンダリングみたいなこともしたい。どうしたらいいだろう。

Vulkan実装にとしてはrender_targetがswapchainとかを握っているのだが、ただの画像データを描画対象にするならswapchainは存在しないはずだ。またrendererもプレゼンテーションとかを行うことになっていて、surfaceへの描画が前提となってしまっている。これは恐らく、描画処理の大枠はrender_target側の責任にしてしまうのが良い気がする。

あと、ライブラリ全体の初期化がウィンドウ作成と対応していてウィンドウを作成する前に画像読み込みとかをすると死ぬ問題があったのだが、考えた末に結局ユーザが初期化関数を呼び出すようなありきたりのAPIになった。本当はcoutみたいにユーザの明示的な初期化が要らない雰囲気にしてみたりしたかったのだが。

• DLLとしてライブラリを作ってDllMainで初期化→静的ライブラリにしたいので却下
• ライブラリ側でmain関数を乗っ取ってSiv3DのようにMain関数みたいのをユーザに実装させる→main関数を乗っ取りたくないので却下
• グローバル変数を作ってそれのコンストラクタで初期化→ライブラリでそれやるとリンカの最適化でカットされる可能性が拭えない
• 上記の方法+何らかのテクで最適化阻止→調べたが手段のコンパイラ依存が強そうなので却下
• ライブラリで使用できる全てのクラスについてライブラリ全体の初期化をトリガーする→面倒、実装漏れの可能性がある
• 遅延評価みたいな感じで必要になるまでライブラリの各モジュールの初期化を遅らせる→技術的難度が高そうなので諦めた

ウィンドウを作成した後にライブラリを初期化するようにしていたのはVulkanのデバイス作成がサーフェスに依存しているなどの理由も大きかったのだが、それについてはなんとかなった。サーフェスに依存せずデバイスの互換性確認が出来るっぽいのだ。

https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html#_querying_for_wsi_support

プラットフォームに依存する形にはなるが、ウィンドウシステム全体でプレゼンテーションの可不可が判定できる。これを使えばサーフェスに依存することはない。