完全なアプリケーションを開発するときに、glTools / glutを使用すべきではないのはなぜですか？

私はOpenGLの使用方法をOpenGL SuperBible、Fifth Editionを使用して少し前から学び始めました。そして、この本はOpenGLの使用方法を実際には教えていないが、代わりに使用方法を教えているという事実について人々が議論しましたそれに関連する2つのラッパーライブラリ、glutとglTools。

また、過剰なプロジェクトを本格的なプロジェクトに使用してはならないことも聞かされましたが、正当な理由はありませんでした。

私の質問は、なぜ、そしていつ私はglTools / glutライブラリーを使用すべきでないのか、そして代わりに何を使用すべきなのか、です。

GLToolsとGLUTは同じものではありません。GLUTはOpenGL以外のものを扱う責任があります。GLUTはウィンドウとOpenGLコンテキストを作成および管理します。そのコンテキスト（別名：OpenGL）内で進行する実際のものは、GLUTの責任ではありません。

Maikは、深刻なアプリケーションでGLUTが表示されない理由をすでにカバーしています。GLToolsは別の問題です。

GLToolsは単なるフレームワークであり、OpenGLのラッパーです。真面目な仕事でそれを使わない多くの理由があります：

1. それは非効率的です。パフォーマンスが重要な場合は、それを回避する必要があります。
2. それはあまり良くありません。GLShaderManagerを例にとってみましょう。シェーダーをロードするか、0を返します。コンパイラ/リンカーエラーがある場合、これに関する情報は提供されません。はい、それはログをstderrに書き込みますが、すべての人が目に見える場所にパイプされたstderrを持っているわけではありません。例外は無視するのがかなり難しいです。

この本はOpenGLの使い方を実際には教えていないが、それに関連する2つのラッパーライブラリの使い方を教えているという事実について私は人々に議論してきました。

これは余談ですが、一般にこれに関する問題は非常に単純です。5thは、フレームワークが何をしているかを説明する前に、フレームワークを使用することを教えています。したがって、シェーダーとは何か、頂点属性とは何かなどを学ぶ前に、メッシュの読み込みの使用方法、遠近法マトリックス生成コードの使用方法、デフォルトのシェーダーなどについて学習します。

それは基本的に本の最初の部分の固定機能プログラミングです。OpenGLではなく、独自の固定機能コードを使用するだけです。

それは問題であるフレームワークを使用するということではありません。問題は、このフレームワークを使用して、現在のレッスンにとって重要ではない詳細を非表示にするのではなく、説明されていない詳細を非表示にすることです。シェーダーのロードコードを数回確認した後は、再度表示する必要がないため、ライブラリ関数にすることができます。

本を構成するより良い方法は、フレームワークが実行している基礎となるOpenGL呼び出しを表示した後でフレームワークの一部を使用することでした。シェーダーの標準セットは問題ありませんが、ユーザーがシェーダーの動作を手動で確認した後でのみ使用する必要があります。メッシュの読み込みと処理、テクスチャなどについても同様です。

大きなプロジェクトにおける過剰に対する反対論は、アプリケーションループにアクセスできないため、ニーズに合わせて変更することはできないということです。それが持っているのは、過剰からトリガーされるいくつかのコールバックですが、それについてはあまり制御できません。

ただし、glutの目的は、ウィンドウを作成するために醜いOSコードを処理する必要なく、簡単にデモとテストアプリを作成し、プラットフォームをクロスさせることです。