16

glLoadIdentityは言う

GL_INVALID_OPERATIONの実行とそれに対応するglLoadIdentityの実行の間に実行された場合に生成 されます。glBeginglEnd

ただし、 glGetErrorGL_INVALID_OPERATIONによって返されるフラグです。

私の質問は、glGetError（openglを正しい順序で呼び出しているかどうかを知るために）いつ呼び出すべきかということです。

4

3 に答える 3

22

あなたの質問が、glBegin / End内にある場合にglGetErrorを呼び出すことができる時期に関するものなのか、それとも一般的なglGetErrorの使用法に関するより一般的な質問なのかはわかりません。だから私は両方に答えます。

glBeginとglEndの間でできることは非常に限られています。GLを非常に特殊なモード（ドローの途中）に置くため、これは意図的なものです。そのため、頂点ごとの属性に直接関係しないものはすべて無効です。glGetErrorでさえ、そのコンテキストでは無効です.glBegin+その間のすべてのGL呼び出し+glEndをGLへの単一のDraw呼び出しとして考えてみてください。これは、GLが実際に行うことをとにかく近づけるのに役立ちます。

これで、属性メソッド（glNormal、glTexCoord、glColor、glSecondaryColor、glIndex、glMultiTexCoord、glVertexAttrib、glVertexなど）のみを呼び出す単純なルールに固執する場合、Begin/Endペア内でGLエラーが実際にトリガーされることはありません。 ）。それ以外の場合はエラーが発生します。（エラー...まあ、glMaterialは少し例外です。動作しますが、その使用は推奨されていません）

質問がBegin/Endペア内でエラーがトリガーされたときにglGetErrorを呼び出すことができる場合、ChrisFはコメントで答えました：glEnd呼び出しの後。

現在、より広い意味で、glGetErrorはデバッグツールとしてのみ使用してください。私の個人的な偏見は2つあります。

  • フレームごとに1回glGetErrorをチェックして、エラーがないことを確認します
  • ほとんどのGL呼び出しを、GLエラーコードをチェックできるマクロでラップし、フレームごとのチェックが失敗した場合にのみオンにします。

もちろん、属性メソッドはBegin / Endペアの外部で呼び出すことができるため、正しく取得するのは少し難しいです。しかし実際には、これらのメソッドはとにかく失敗することはないので、私はわざわざマクロチェックをしません。

ちょっとした雑学：GL APIは元々、クライアント実装が呼び出しサイトでエラーが発生したかどうかを実際に認識できないように設計されていました。たとえば、GLが実際にリモートマシンに実装されている場合（SGIの時代のように）、たとえば、GL_TEXTURE_ENVではないターゲットを使用したglTexEnvの呼び出しをコマンドバッファーに追加するだけで、その時点でエラーは記録されません。 。

次にglGetErrorを呼び出すと、クライアント側はコマンドバッファをGLサーバーにフラッシュし、バッファリングされたコマンドが処理されるのを待って、エラーコードを取得し、適切なエラーコードをアプリケーションに返す必要があります。

これが重く聞こえるなら、それはそうだったからです。ちなみに、これが各呼び出しでエラーコードが返されない主な理由であり、glGetErrorの呼び出しはデバッグ目的でのみ問題ないと見なされた理由です。最近、ほとんどのGL実装は同じプロセスですべての状態管理を処理しているので、私が言ったように、それはほとんどのユーザーにとって本当にトリビアです。

最後に、Begin / Endについて話すときはいつでも、それをまったく使用しないことを検討する必要があると私は言う必要があると思います。これは、GLで描画するための最もパフォーマンスの悪い方法です。

于 2010-01-01T14:10:50.713 に答える
4

呼び出しの効果の1つは、スタックから（MSDNから）エラーをクリアすることであるため、通常は1回glGetErrorおきに呼び出す必要があります。gl...

エラーが発生すると、エラーフラグが適切なエラーコード値に設定されます。glGetErrorが呼び出され、エラーコードが返され、フラグがGL_NO_ERRORにリセットされるまで、他のエラーは記録されません。

ただし、呼び出しをラップしてglBegin、の後にglEnd呼び出す場合。これにより、正しいエラーコード（存在する場合）が返され、エラースタックがクリアされます。glErrorglEnd

于 2009-12-26T13:15:15.907 に答える
3

コーディングの哲学の中には、すべてのプログラムが考えられるすべてのエラーをチェックし、それらのエラーを適切に処理することを期待しているものがあります。それでも、これらの哲学の1つに従うには、多くの追加コードが必要であり、プログラムの速度が大幅に低下する可能性があります。実際には、問題を診断するとき、または失敗する可能性が非常に高く、エラー後に適切なアクションを実行するコードを作成するときにのみ、glGetErrorを使用します。

最初のケースでは、問題を診断するために、2つの戦略のいずれかを使用します。OpenGLはglGetErrorが呼び出されるまで新しいエラーを記録しないため、メインループを介して毎回エラーをチェックできます。これで最初のエラーがわかり、それを追跡して修正できればと思います。問題のあるコードに絞り込んだときに使用するもう1つの戦略ですが、どの呼び出しが問題を引き起こしているのかわかりません。各glの後に...glBeginの外に呼び出します。。。glEndブロックglGetErrorを呼び出し、エラーがあれば報告します。これにより、どのgl ...呼び出しが問題を引き起こしているのかが正確にわかり、うまくいけば、修正への道を歩み始めます。

2番目のケースでは、発生する可能性のあるエラーを防御的にプログラミングするために、glGetErrorを呼び出してエラーフラグをクリアし、他のgl ...呼び出しを行ってから、glGetErrorを呼び出します。次に、glGetErrorが報告するものを処理するために必要なアクションを実行します。

于 2009-12-26T19:04:43.657 に答える