0

プラットフォームに依存しないコードを書きたいのですが、問題が発生しました。一部のマシン (windows/python OpenGL)GL_VERTEX_SHADERでは定義されており、他のマシンでは定義されGL_VERTEX_SHADER_EXTていGL_VERTEX_SHADER_ARBます。glCreateShaderObject関数(EXT/ARB) とを使用しても同じ組み合わせが見つかりglProgramParameteriます。これらには正しい列挙型を使用していることを確認する必要があります。
あなたが使用しているマシンがこれらの組み合わせの1つをサポートしていることを確認する方法はありますか?

4

2 に答える 2

2

2.0 より前のバージョンの OpenGL をターゲットにしている場合を除き、これらの拡張機能は使用しないでください。正直なところ、最近、なぜそのような古いマシンをわざわざサポートするのですか? 2.0 より古い実装との互換性を維持するには、2 の累乗でないテクスチャの再スケーリングを含め、不便なことをしなければならないことが多すぎます。

あなたが使用しているマシンがこれらの組み合わせの1つをサポートしていることを確認する方法はありますか?

はい、ソフトウェアのベースライン要件として OpenGL 2.0 を確立すると、次のような標準の GLSL 関数を使用できますglUseProgram (...)。ARB 拡張機能とコア GLSL で使用される名前の間には直接的な対応はありませんglUseProgramObjectARB (...)。たとえば、先ほど述べた関数の ARB バージョンがそうです。


およびそのglProgramParameteriEXT/ARB の種類に関しては、これはおそらくあなたが思っているものではありません。とは関係ありませんGL_VERTEX_SHADER。コア (OpenGL 4.1) に導入される前は、この関数は拡張機能によって提供されていました:ARB_geometry_shader4およびEXT_geometry_shader4. glProgramParameteriこれは、拡張子:という名前で最初に正式に定義され、ARB_get_program_binaryこの拡張子を提供する場合、非 OpenGL 4.1 実装に存在する可能性があります。

つまり、準拠した 4.1 実装を使用している場合は、 のプロシージャ アドレスが保証されますglProgramParameteri。それ以外の場合、使用する適切な関数は、拡張文字列に表示される次の関数によって異なります。

 1. ARB_get_program_binary --> glProgramParameteri    (...)
 2. ARB_geometry_shader4   --> glProgramParameteriARB (...)
 3. EXT_geometry_shader4   --> glProgramParameteriEXT (...)

これらの条件のいずれも満たさglProgramParameteriれない場合、そのフレーバーはありません。

于 2013-11-13T03:12:39.643 に答える