グラフィックスAPIを厳密に抽象化しすぎているかどうかを知るにはどうすればよいですか？

複数のグラフィックスAPIをサポートするレンダラーを作成する場合、通常、OpenGL、Vulkan、D3D11などのグラフィックスAPIに関連付けられた何らかの低レベルライブラリでコードを抽象化します。

これらは互いに非常に異なる動作をするため、適切な汎用APIを作成することが不可欠になります。サポートしたい各APIの基本機能を実装する「バックエンド」と、プログラマーが何かを描画するために使用する「フロントエンド」を通常使用することを読みました。画面。

タイトな抽象化をしすぎているかどうかを知るにはどうすればよいですか？

まず、複数のグラフィックスAPIをサポートする価値があるかどうかを検討してください。OpenGLを使用するだけで、ほとんどのプラットフォームがカバーされ、最もグラフィカルな野心的なプロジェクトを除くすべてのプロジェクトで「十分」になります。数千人時間をかけて複数のレンダリングバックエンドの実装とテストに費やすことができる非常に大きなゲームスタジオで働いていない限り、そして本当に見せたいDirectXまたはVulcan固有の機能がない限り、通常は面倒の価値はありません。特に、他の人が作成した抽象化レイヤー（サードパーティのライブラリまたはゲームエンジン）を使用すると、多くの作業を節約できることを考慮してください。

しかし、あなたはすでにあなたのオプションを評価し、それが実行可能であり、あなた自身のものをロールバックする時間の価値があるという結論に達したと仮定しましょう。

そして、抽象化層のソフトウェアアーキテクチャの主な判断は、フロントエンドプログラマです。

• 低レベルの詳細を気にすることなく、実装したいゲームシステムを実装できますか？
• 複数のグラフィックスAPIがあることを完全に無視できますか？
• 理論的には、フロントエンドコードを変更せずに、さらに別のレンダリングバックエンドを追加することは可能でしょうか？

もしそうなら、あなたは成功しました。

APIの「ラッパー」部分から実際に必要なものを識別することから始めます。通常、非常にシンプルです。基本的なリソース（バッファー、シェーダー、テクスチャ、パイプライン状態）と、それらのリソースを使用していくつかの描画呼び出しを送信してフレームを構築する方法が必要です。

任意の高レベルのロジックを保つようにしてください外の APIのラッパー部分。APIのこの部分に巧妙なシーンカリングテクニックを実装する場合、すべてのバックエンド実装でそのロジックを複製するためのフックになりました。それは多くの余分な労力ですので、単純にしてください。シーン管理は、ラッパー自体の一部ではなく、ラッパーを使用するAPIの上位レベルの一部である必要があります。

サポートするターゲットを選択し、それらを理解します。「すべて」のきちんとしたラッパーを書くのは難しく、おそらく必要はありません（おそらく、Philippの回答に記載されているように、単一のラッパーを記述する必要はありません）。ラップするAPIがわからない場合、適切なラッパーを作成することはほとんど不可能です。

APIの状態を定期的に評価します。一般的に、基礎となるラップされたAPIよりも小さな表面積を持つ必要があります。すべてのD3D構造体またはすべてのOpenGL関数呼び出しに対して1対1のラッパータイプを作成していることに気付いた場合、おそらくコースから外れているでしょう。

以前に行った作業を見てください。SokolとBGFXは、あなたに役立つかもしれないレベルの不可知論を提供するAPIであり、比較的簡単に理解できます（特に前者）。

まだ考慮していないもう1つの点は、パフォーマンスの目標です。安価なハードウェアプラットフォームで優れたパフォーマンスを実現するグラフィックライブラリを作成することを目標としているが、非常に強力であるが異なるAPIを使用するさまざまなプラットフォームでも使用できる場合、APIを設計することは理にかなっているかもしれませんパフォーマンスが問題になるプラットフォームでネイティブに使用される抽象化。これにより、より強力なプラットフォームで50％の速度低下が発生した場合でも、パフォーマンスが最も重要なプラットフォームで20％の速度改善が可能であれば価値があります。