OpenGLとOpenGLES2の互換性

Question

私はどこでも使えるいくつかのOpenGLコードを書こうとしてきましたが、自分自身をあまり制限することはありませんでした。
opengles2をサポートしているデバイスではopengles2を使用し、サポートされている場合はopenglコアを使用したいと考えました。

また、実行時に使用するものを選択できるようにしたいと考えています（利用可能な場合はもちろん）。

私の質問は以下のとおりです。
私はOpenGLライブラリとそれが利用可能であるたびに、私のコードをリンクして、GLES2またはGLコアコンテキストを作成するいずれかの場合、GLES2コンテキストがGLESv2ライブラリとまったく同じように動作しますか？ヘッダーワイズの影響はどうなりますか？ たとえば、GLESv2はBGRAテクスチャフォーマットを定義していないので、すべてをRGBAに変換する必要があります。それはあまり面倒ではありませんが、私は代替案を知ることに興味があります。

私は、ライブラリを動的にロードし、使用されているすべての関数ポインタをロードすることを考えましたが、それは多分簡単な答えがあるもののための膨大な量の作業です。 この場合、glext.hをインクルードして、使用された関数のすべての関数ポインタを宣言してそれらを生成します。 ここで問題になるのは、glextはデータ型（glenumなど）を定義しないため、常にgl.hを含める必要があるということです。 両方を含めることで、gl.h関数宣言と私自身の関数ポインタ宣言が得られるので、関数ポインタの汎用名前空間を使うことはできませんでした...そして、それでもglGetErrorのようないくつかの関数は見えませんそれらの関数ポインタに関連するtypedefを持つこと。

私はGLEWについて知っていますが、残念ながら、ほとんどのLinuxディストリビューションはまだGLES2と互換性のないGLEWのバージョンを配布しています（debian、私はあなたを見ています）。それはちょうどsegfaults。

あなたはどうしますか？ OpenGL関数をリンクするための他の方法はありますか？

Answer 1

私はあらゆるハードウェアプロバイダが独自のバージョンを持っているため、すべての種類のOpenGLサブセットで作業する航空宇宙産業です。 （私は完全に文書化されたプロファイルで作業するのが大好きです...まあ...何でも）それは同じような問題があるようです。私はこれまでに学んだことをあなたに与えます。

まず、あなたが得ることができるすべてのプロファイルの中で最大の最悪のスーパーセットに向かって開発したいと考えています。ハードウェアベンダーが提供するOpenGLヘッダーの最新バージョンを使用してください。そうすれば、あなたのプログラムは少なくともコンパイル部分を解決します。

BGRAマクロ/列挙型はGLESv2ランタイムの一部ですが、プラットフォームでRGBAのみをサポートしている場合は、実行時に決して使用しないでください。

プラットフォーム機能に基づくランタイムの決定は、OpenGL拡張リストに基づいて行われます。アプリケーションが使用するものと拡張リストを比較し、サポートされていないブランチを無効にし、サポートされているブランチをアクティブにします。この方法でOpenGLとGLESを区別することができます。