イミディエイトGUI-ええ、いや？[閉まっている]

私は、MFC、QT、Forms、SWING、および数年前のいくつかのWeb-GUIフレームワークなど、多くの「保持された」GUIシステム（これが意味することについては以下）でアプリケーション開発に取り組んできました。私は常に、ほとんどのGUIシステムの概念が非常に複雑で不器用であることを発見しました。コールバックイベント、リスナー、データコピー、文字列から何かへの変換の量-変換（など）は、アプリケーションの他の部分と比較して、常にミスと頭痛の原因でした。（データバインディング/モデルの「適切な」使用でも）。

今、私はコンピューターゲームを書いています:)。私はこれまでに1つのGUIで作業しました。宮城（よく知られていませんが、基本的に他のすべてのシステムと同じアイデアです。）

ひどかった。

ゲームのようなリアルタイムレンダリング環境の場合、「保持された」GUIシステムはさらに時代遅れになったように感じます。ユーザーインターフェイスは通常、自動レイアウトする必要も、オンザフライでサイズ変更可能なウィンドウを持つ必要もありません。代わりに、常に変化するデータ（世界のモデルの3D位置など）と非常に効率的に対話する必要があります

数年前、私は基本的にイミディエイトグラフィックスモードに似ていますが、ユーザーインターフェイス用の「IMGUI」に出会いました。私はまだアプリケーション開発に携わっており、IMGUIシーン自体はそれほど広くも成功もしていないように思えたので、あまり注意を向けませんでした。それでも、彼らがとるアプローチは非常にセクシーでエレガントであるため、このUIの方法を使用して次のプロジェクトのために何かを書きたいと思うようになりました（私は職場で誰も納得させることができませんでした：（...）

「保持」と「即時」の意味を要約します。

保持されたGUI：別の初期化フェーズで、ラベル、ボタン、テキストボックスなどの「GUIコントロール」を作成し、それらを画面に配置する記述的な（またはプログラム的な）方法を使用します。コントロールは、X、Yの位置、サイズ、境界線、子コントロール、ラベルテキスト、画像などの独自の状態のほとんどをメモリに保持します。コールバックとリスナーを追加して、イベントを通知したり、GUIコントロールのデータを更新したりできます。

即時GUI：GUIライブラリは、ワンショットの "RenderButton"、 "RenderLabel"、 "RenderTextBox" ...関数で構成されています（編集：Renderによって混乱しないでくださいプレフィックス。これらの関数は、ユーザー入力のポーリング、文字の挿入、ユーザーがキーを押したときに文字の繰り返し速度を処理するなどのコントロールの背後にあるロジックも実行します...）コントロールを「即座に」レンダリングするために呼び出すことができます（doesn ' tはすぐにGPUに書き込まれる必要があります。通常は、現在のフレームについて記憶され、後で適切なバッチに分類されます。ライブラリはこれらの「状態」を保持しません。ボタンを非表示にする場合は、RenderButton関数を呼び出さないでください。ボタンやチェックボックスなどのユーザーインタラクションを持つすべてのRenderXXX関数には、ユーザーがボタンをクリックしたかどうかを示す戻り値があります。あなたの「RenderGUI」関数は、ゲームの状態に応じてRenderXXX関数を呼び出すかどうかの大きなif / else関数のように見え、すべてのデータ更新ロジック（ボタンが押されたとき）がフローに絡まります。すべてのデータストレージはGUIの「外部」にあり、Render機能にオンデマンドで渡されます。（もちろん、大きな関数をいくつかに分割したり、GUIの一部をグループ化するためにいくつかのクラス抽象化を使用したりします。1980年のようなコードはもう書いていませんよね;））

今回、Unity3Dが実際に組み込みのGUIシステムとまったく同じ基本的なアプローチを使用していることがわかりました。おそらく、このアプローチを備えたGUIがいくつかありますか？

それでも..周りを見ると、保持されたGUIシステムに強いバイアスがあるように見えますか？少なくとも、Unity3Dを除き、このアプローチは見つかりませんでした。元のIMGUIコミュニティは、かなり静かなようです。

だから誰も両方のアイデアで働いていて、強い意見がありますか？

編集：私は実世界の経験から生じる意見に最も興味があります。IMGUIフォーラムでは、即時GUIアプローチの「理論上の弱点」について多くの白熱した議論があると思いますが、実際の弱点について知ることは常により啓発的であると思います。

いや。私はひどい「リテインモード」GUIとひどい「イミディエイトモード」GUIでgamedevの仕事をしましたが、どちらも目を引きたくなりましたが、リテインモードアプローチの方が明らかに優れています。

即時モードの欠点は多数あります。

• アーティストやデザイナーがレイアウトを簡単に設定できるわけではありません。
• ロジックとプレゼンテーションを混在させます。
• 一貫性のある単一の入力モデルを持つことが難しくなります。
• 動的データの複雑な制御を妨げます（リストビューなど）。
• レイヤー化が非常に厄介になります（たとえば、RenderComboBoxを呼び出した場合、ドロップダウンボックスは、ウィンドウの残りの部分の上に移動する必要があるため、まだレンダリングできません-ツールヒントについても同じです）
• レンダリングスタイルの構成は、グローバル（ick）または追加の関数引数（ick）で行われます。
• これらのすべての関数を呼び出して、変更された値または変更されていない値を照会すると、多くの小さなオブジェクトが作成され、メモリマネージャにストレスがかかるため、パフォーマンスが低下する可能性があります。
• ...そして私は、誰かがGUIを少しドラッグして並べ替えることを許すのがどれほど苦痛か想像もできません。すべてをレンダリングする場所を示すデータ構造を維持する必要があります。これは、保持モードシステムを自分で書き換えるようなものです。

即時モードのGUIは、迅速なHUDシステムを必要とする孤独なプログラマーにとって魅力的であり、そのために優れています。それ以外の場合は...単にノーと言います。

デスクトップでIMGUIを実際に5〜6年経験した人として、私はそれを守る義務があると感じています。すべての回答（および質問自体）はIMGUIの非常に制限された定義に基づいており、多くの疑わしい主張がなされているようです。

その多くは、IMGUIライブラリが内部でデータを保持できないという仮定から生じています。これはまったく真実ではありません。実際、洗練されたIMGUIライブラリは、同等のRMGUIライブラリとほぼ同じ量のデータを保持します。違いは、IMGUIライブラリはほとんど結果をキャッシュするのに対して、RMGUIライブラリは信頼できる状態を維持することです。IMGUIでは、アプリケーションは現在のモデルの状態を取得し、その状態のGUIを生成する機能を提供します。これは、GUIの正式な定義です。ライブラリは、画面上のGUIがその関数の結果と一致することを確認する責任があります。これは、フレームごとにその機能を完全に評価し、GUIを完全に再構築する必要があるという意味ではありません。それがキャッシングのポイントです。

このIMGUIのビューを使用すると、実際には高度なレイアウトを実行でき、パフォーマンスは非常に合理的です。インターフェイスが簡単になる場合は、実際の信頼できる状態を保持することもできます。IMGUIのポイントは、アプリケーションにすべてを保持させないことです。アプリケーションは、おそらくすべてのスクロールバーの位置とすべてのツリーノードの展開/折りたたみ状態を保存する必要はないでしょう。ポイントは、それらのツリーノードの内容とその存在そのものを手続き的に指定できるようにすることです。

私はすべてのIMGUI批判に一点一点対応しますが、それらの多くは本当に理解していません。それらのほとんどは、IMGUIがハックでRMGUIがよく構造化されているという基本的な信念から生じているようです。IMGUIライブラリーが複雑さで問題を抱えたり、グローバルに散らばったり、ロジックとプレゼンテーションを混在させたりする必要があるという固有の理由はありません。IMGUIの利点は、コンテンツがアーティスト主導型であるほど重要ではなくなると言いますが、アーティスト主導型コンテンツの方が実際に悪い理由はわかりません。（色、フォント/境界線のサイズなどのスタイルシートを除き、アーティスト主導のコンテンツは個人的に使用しませんが、RMGUIよりも実装が難しい理由はわかりません。）

私の考えでは、IMGUIは間違いなく良いことです。GUIを推論するためのより良いモデルを提供します。それは、はるかに機能的かつ反応的になり、推論する必要がある可変状態の量を最小限に抑えます。一方、洗練されたIMGUIライブラリの実装は非常に困難であり、同等のRMGUIライブラリの実装よりも明らかに困難です。ライブラリの複雑さとアプリケーションの複雑さとのトレードオフです。複雑なアプリ（または多くの単純なアプリ）の構築を計画している場合、トレードオフは非常に良いです。単一のアプリでこれを実行していて、それが非常に簡単な場合、おそらくRMGUIを使用して目標をより早く達成できます。

いずれにせよ、幸運を祈ります！

GUIライブラリは、ワンショットの「RenderButton」、「RenderLabel」、「RenderTextBox」...で構成され、コントロールを「即座に」レンダリングするために呼び出すことができる関数です（GPUにすぐに書き込む必要はありません。通常は記憶されています）現在のフレームについて、後で適切なバッチに分類されます）。

私はこれがGUIライブラリを構成しないと言っているところまで行きます。これは単なるレンダリング関数の集まりです。

GUIのレンダリングは、GUI を作成する最も簡単な部分です。テキストボックスを例にとります。簡単な単一行の入力テキストボックスという最も簡単なケースを想定します。

RenderTextBoxテキストボックスを描画するだけです。いくつかの簡単なテキスト測定を行い、グリフを画面に描画します。しません

• ユーザーがコントロール内でマウスをクリックしたことを検出し、カーソルを文字列内の適切な場所に移動します。
• ユーザーがコントロールでマウスをダブルクリックしたことを検出し、テキストブロックを選択します。
• ユーザーが「ホーム」キーを押したことを検出し、カーソルをテキストの前に移動します。
• ユーザーが有効なキーを押したことを検出し、それに応じて文字列を変更します。テキストが選択された場合、選択された部分は挿入されたテキストに置き換えられます。

私は続けることができますが、私のポイントは明確だと思います。RenderTextBoxテキストボックスの描画に使用する場合、取得できるのは静的で機能しないテキストボックスのみです。実際の機能はすべてユーザーが実装する必要があります。

テキストの測定とグリフの描画を行っていますか？これは、GUI作業の簡単な部分です。GUIは「グラフィカルユーザーインターフェイス」の略です。最後の2つの単語は、ユーザーからの入力を受け取り、それを使って何かを行う部分です。

ゲームプレーヤーは、GUIコントロールが合理的に機能することを期待しています。PCスタイルの環境（マウスとキーボードなど）では、プレイヤーがテキストボックスを見ると、通常のテキストボックスのように機能することを期待しています。彼らは、矢印キーでその中を動き回り、前にジャンプしてホームで終了して削除し、その中の文字を選択するなどを期待しています。

つまり、このUIコードをすべて実装する必要があります。クリックされたコントロールをテストする必要があります。次に、クリックされたコントロールに基づいて何かを行う必要があります。キーボード入力を取得する「アクティブ」コントロールの概念が必要です。異なるコントロールは、異なるタイプのユーザーインタラクションに対して異なる応答をしなければなりません。

基本的に、TextBoxWindowクラスが必要になります。

ゲームオプション画面を実装しているとしましょう。そのため、ゲームプレイ、グラフィックス、サウンド、コントロールなど、さまざまなオプショングループがあります。したがって、画面の左側にさまざまなグループのリストがあります。各グループは、ユーザーが操作できる一連のコントロールを表示します。ユーザーがTabキーを押すとどうなりますか？

まあ、それはアクティブなコントロールに依存します。グループコントロールの1つがアクティブである（最後にクリックされた）場合、次のグループに移動します。代わりに、グループ内のコントロールの1つがアクティブな場合、そのグループ内の次のコントロールに移動します。これが、システムの動作方法です。

したがって、アクティブなコントロールはキーボード入力を処理するだけでなく、未処理の入力をそれを所有するコントロールにファーム化する必要があります。それまたはコントロールは、何らかのリンクリストに含まれている必要があります。つまり、各コントロールにはデフォルトの動作が必要です。

これは、保持されたGUIのように聞こえますか？唯一の違いは... あなたが大変な仕事をしているということです。GUIをしている人のelsesの使用を想定少ない作業を行うための方法であることを。しかし、ユーザーが期待するようにGUIを応答させるのにかかる労力は簡単ではありません。

覚えておいてください：UIはあなたのためではなく、あなたのユーザーのためです。プレーヤー用です。期待どおりに動作するはずです。そうでない場合は、その後、あなたは失敗しています。

ユーザーインターフェイスは通常、自動レイアウトする必要も、オンザフライでサイズ変更可能なウィンドウを持つ必要もありません。

それは限定的で限定的な考えです。

UIのニーズが異なるさまざまなゲーム、一部のゲームではサイズ変更可能なウィンドウなどが必要であるという話をすることができます。しかし、もっと大きな問題があります。

あなたの種類の思考は、無償の宇宙戦の問題につながります。

あなたがそのゲームをプレイしたことがないなら、それは安くて、インディーで、非常にGUIが重いゲームです。実際のゲームプレイはすべてGUIで行われます（「ユニットをセットアップして、それらが戦うのを見る」種類のゲームです）。問題？

GUIを復元することはできません！

ああ、これは普通のモニターを使っていたり、普通の視力を持っているなら大丈夫です。しかし、たとえば、とてつもなく巨大なモニター（Windowsですべてのテキストのサイズを拡大して実際に読むことができるほど大きいモニター）を実行している私なら、これはひどいです。テキストは微視的です。フォントサイズを変更する方法はありません。

確かに、GSBはGUIベースのゲームであるため、絶対に言い訳にはなりません。GUI-liteゲームはおそらくそれでうまくいくでしょう。

ユーザーが自分と同じようにゲームを見ていると思い込まないでください。そうすることは愚かです。

ユーザーの解像度に合わせて再スケーリングできるGUIシステムを使用する場合、真に解像度に依存しないGUIでは、レイアウトをGUIシステム自体の一部にする必要があります。それを提供しない場合、あなたのテキストは誰かの巨大なモニターで小さく表示されるでしょう。これは良いことではありません。

ですから、このテーマに関するあなたの考えは近視眼的だと思います。あなたはそのようなものが必要です。保持されたGUIが提供するものが必要です。ああ、あなたは特定のGUIシステムが提供するすべてを必要としないかもしれません。しかし、あなたはそれのいくつかが必要です。

システムにデータを取得するために必要な定型的な作業は、ユーザーがコントロールと正しくやり取りできること、およびプレーヤーのニーズに合わせてサイズを変更することを合理的に保証することに加えて、わずかな費用です。

プレーヤーからあまりユーザーの入力を受け取らなければ、イミディエイトモードのGUIで逃れることができる場合があります。しかし、それはそれについてだろう。

しばらく前にIMGUIも興味を引きました。テストとして、テクニックに慣れるためのチュートリアルをいくつか書きました（興味があればここから始めてください。ただし、C＃/ XNA + ここにある元の「チュートリアル」以上ではありません） 。

IMGUIは、表示される情報が常に最新かつ正確であるため、しばらくの間は本当に気に入っていました（常に実際のデータにフィードする状態がないため）。しかし、最終的には興味を失ったため、通常は保持されたGUIを再び使用します。

最終的には、GUIの即時性により、GUIをデータから分離することが難しくなると考え、時には状態を導入してIMGUIの優雅さを損なうことで、物事をさらに分離しようとしました。また、保持されたGUIのコードを書くことはIMGUIのコードを書くことよりも手間がかかるとは思いません。保持されたGUIを起動して忘れることができ、イベントが本当に好きです。

しかし、誰かがIMGUIに言及するたびに、私の中の何かがもう一度やり直したいと思います。私はそれを試してみて、多分私がやったように試して、いくつかのチュートリアルを書くと思います（新しいテクニックを学ぶ最良の方法は、他の人に説明することです）。

私はUnity3D GUIシステムで多くの仕事をしました。そして私は言わなければならない、私は情熱を持ってそれを憎む。

「即時」アプローチは、場合によっては非常にうまく機能します。まず、いくつかのボタンとラベルだけが必要な場合-たとえば、シューターHUDを考えます。「保持された」アプローチでそれらを作成することはそれほど難しくありませんが、UnityGUIで非常に簡単です。2番目のケースは、画面上に多くのコントロールを配置する必要があるが、レイアウトはあまり気にしない場合です。特に、正確な制御が実行時にのみ知られている場合。これは実際にはどのゲームでも有用ではありませんが、Unityエディター内で実行するツールを作成する際に非常に役立ちます。

ただし、（MMO）RPGや戦略ゲームなどの半複雑なGUIは、不可解なコードの不可解な混乱に変わり、特殊なケースとたくさんの方法で破壊されます。このようなGUIを構築する場合、通常は、解像度に応じて機能し、送信するデータを表示できる特定のレイアウトが必要です。たとえば、いくつかのボタンを下に動かして長いテキストを表示するなどのことが必要です。「保持された」GUIを使用すると、それを自動的に行うコントロールを使用できます。「即時」モードでは、コントロールがないため、すべてを明示的に行う必要があります。

UnityGUIの別の問題（すべてのイミディエイトモードGUIに起こるかどうかはわかりません）は、たとえば、Button()他のGUI呼び出しを考慮せずに呼び出しが機能することです。そのため、あるボタンが別のボタンの上にある場合、クリックすると両方のボタンが同時に押されます。これは間違いなくユーザーが期待するものではないため、これは別の特別なケースを処理するために追加します。

このすべてに対応するために、UnityGUIの周りに独自のラッパーを作成し、それを「保持」モードシステムに変えます。独自の状態を保存し、GUIフレームごとに必要な関数を呼び出すコントロールです。

私は、「即時」モードであると言うことができない、間違いなく「留保」よりも悪いが、私は確かにはるかに良いモードを「保持」で働いて感じます。

ここにIMGUIを擁護します。以前にリストされた問題のいくつかは、そのためのコードを書いても構わないと思ったら解決できるからです。さらに、コードを記述すると、再利用可能で堅牢なライブラリが得られ、変更が必要になることはほとんどありません。

• スキーマからGUIをロードする

おそらく最初は、アーティストにはIMGUIの柔軟性があまりないようです。これは、xmlまたはJSONスキーマからGUIレイアウトをロードすることで解決または改善されます。

• メニューレイヤーの描画呼び出し

この問題は並べ替えで解決されます。描画の順序を並べ替えるUI Managerクラスを作成する必要があります。C＃XNAでこの問題を解決するには、上下に移動可能なクリック可能なパネルを使用します。質問があれば擬似コードを投稿できます。

• リストボックス

配列から文字列を描画できますか？これらの文字列のフォントの高さと幅から四角形の領域を定義できますか？スクロールボタンのサイズと追加されたすべての長方形の高さの比率を作成できますか？次に、スクロール可能なボタンでリストボックスを作成し、上下に移動します。難しいと思っていましたが、思ったよりもずっとシンプルでした。バッファも状態もコールバックも含まれていません。

• GUIからのデータの分離

個々のパネル、ボタン、ボックスにデータを保持させないでください。IMGUIの最初の試みは即座に行われたが、グラフィックの意味でのみ行われたことを知っています。UIにデータを保持するというミスを犯しました。UIの変更によってデータを配置および変更する場所について異なる考え方をすることは、ほとんど哲学的な変化でした。

• SDKからのGUI

これはSDKのコードの制限と機能であり、あなたのものではありません。とにかく、SDK UI（Hammer、Unity、UDK）はほとんど新しい言語です。実際、それらはWindows.Formsとして私に似ていますが、両方とも最も広い可能性のためにセットアップされており、そのため、複雑さが多少重くなっています。

最後にこれを見る> http://mollyrocket.com/861

ユーザーインターフェイスは通常、自動レイアウトする必要も、オンザフライでサイズ変更可能なウィンドウを持つ必要もありません。代わりに、常に変化するデータ（世界のモデルの3D位置など）と非常に効率的に対話する必要があります

問題のジャンルとゲームに依存します。優れた在庫管理システムは、ほとんどのRPGにとって不可欠です。レイアウトを処理し、スクロールバー、ドラッグアンドドロップ、ツールチップ、および保持GUIを使用した実装がはるかに簡単なその他の機能をサポートするものが必要になります。

Zバッファーを一時的に変更したり、時間情報を保存して移動を起こしたクリックを除外したりするなど、多くのジャグリングやユーザー状態の保存を必要としない即時GUIでドラッグアンドドロップを行う方法は考えられません。ビット。

しかし、設計の観点からは、GUIイベントのない世界を想像するのは困難です。また、即時GUIはOOPと互換性がないため、手続き型プログラミングに頼らざるを得ません。

即時GUIによって提供されるシンプルさは、UIに必要な複雑さが増すにつれてコードが急速に成長するという追加の複雑さを犠牲にしてもたらされます。優れた保持されたGUIは元々より複雑ですが、より優れた拡張性を備えています。そのため、特定の複雑なポイント以下では、即時のGUIで十分ですが、ほとんどの状況では、むしろGUIを保持したいと思います。