
http://www.cegui.org.uk
Copyright©2004-2022 Paul D Turner、The Cegui Development Teamおよび貢献している著者
以前はプレーンテキストだったCEGUIの補助ファイルの大部分は、Doc/Doxygenディレクトリ内の「Doxygenized」形式に保持されています。これらのファイルを見て、よりフレンドリーな形式のドキュメントを生成してください。または、すべてのドキュメントのニーズについては、http://static.cegui.org.uk/docsにアクセスしてください。
次のことは、クイックスタートガイドです。より詳細なドキュメントについては、Doxygenドキュメントにアクセスしてください。
v0-8 、CEGUIの最新の安定したABI互換(0.8.xリリースまで)バージョンを提供します。 C ++ 03標準に基づいており、Visual Studio 2008-2015を含む最も一般的なコンパイラと互換性があります。このブランチはABI互換性があるため、バージョン0.8.xのCEGUIダイナミックライブラリを、プロジェクトを再コンパイルすることなく、新しい0.8.xバージョン、またはその逆に置き換えることができます。このブランチは、新しい0.8.xリリースのベースでもあります。v0 、CEGUIの最新の安定したAPI互換バージョンを提供し、ABIを破る変更が含まれています。 C ++ 03標準に基づいており、Visual Studio 2008-2015を含む最も一般的なコンパイラと互換性があります。このブランチのバージョンは、次のマイナーバージョンリリースに使用されます。default 、次のメジャーバージョンでのみ使用される変更が含まれます。 C ++ 11の標準に基づいており、Visual Studio 2013以降を含む、最も一般的な最新のコンパイラと互換性があります。このブランチは非常に不安定で、根本的な変化を導入し、 ABIとAPIの互換性を破ります。機能に大きく依存し、以前にCEGUIの開発者と話し合っていない限り、これを使用することはお勧めしません。これは、すべての潜在的なリスクを認識できるようにお勧めします。一般的なケースでは、安定した枝のいずれかを使用して、多くの頭痛を救うことをお勧めします。 v0-8およびv0ブランチは安定していると見なされますが、それぞれABIとAPIを破ることはありません。もちろん、これらの変更は、ブランチに今のところ一時的な問題があるかもしれないという小さなリスクをもたらします。これらのブランチのバグに気付いた場合は、できるだけ早くそれらを報告してください - フォーラムおよび/または当社のIRCチャンネル#ceguiおよび#cegui-develを使用して、 irc.freenode.netでお知らせください。 1日24時間IRCでは利用できないと考えてください。ただし、応答するまで気軽にアイドル状態にしてください。どのブランチを使用するか疑わしい場合は、この方法でお気軽にお問い合わせください。生産の使用については、通常、安定したリリースバージョンを使用することをお勧めします。リリースのリストは、当社のWebサイトにあります。
適切なコミットメッセージを含む良心のコミットを含むクリーンなプルリクエストで私たちは最も幸せです。また、プレーンパッチも受け付けていますが、ワンクリックであなたの貢献を受け入れやすくすることで、レビュープロセスが大幅に高速化されます。
リポジトリからフォークをフォークする方法、フォークに変更をコミットし、適切なブランチをターゲットにするプルリクエストを作成する方法について説明します:https://confluence.atlassian.com/display/bitbucket/fork+ repo,+ compare+code,++++create+pull+request
また、適切なリポジトリをターゲットにすることも留意してください。可能であれば、ABI互換のブランチをターゲットにすることを好みます。それ以外の場合は、API互換性のあるもの。 ABI/API互換性の詳細については、このページをお読みください:https://community.kde.org/policies/binary_compatibility_issues_with_c%2b%2b
ターゲットにするブランチが疑わしい場合は、お問い合わせください!
次のスクリプトは、 *nixシステムとWindowsの多かれ少なかれ普遍的です。小さな変更が必要になる場合があります。
cd $cegui_folder
# you can call the folder differently but "build" is customary
mkdir build/
cd build/
# run the configure step
cmake-gui ../
# fix any issues pointed out by cmake
# not all dependencies are required so if some are not found, don't panic and carry on!
# alternative (if you are a command line pro)
# cmake ../この時点で、メイクファイル、プロジェクトファイル、または何か他のものが生成されます。次のステップは、それがどちらであるかによって異なります。
メイクファイルの場合は、実行するだけです
cd $cegui_folder
cd build/
makeVisual Studio Solutionsの場合、ダブルクリック、それに応じてビルドモード(リリース、デバッグなど)を変更し、ビルドを押します。
このセクションは、 *nixのようなシステムでのみ理にかなっています。
Configure Timeに正しいCMAKE_INSTALL_PREFIXが設定されていることを確認してください。代替の再実行cmakeと設定します。デフォルトでは/usr/local/ beが必要ですが、 /usr/必要な場合があります。
cd $cegui_folder
cd build/
sudo make installCEGUIシステム全体にインストールした場合は、電話をかけてください。
CEGUISampleFramework-0コマンドラインから電話をかけることが望ましい場合は、1つ以上が利用できる場合に備えてレンダラーを選択するように求められます。
システム全体にインストールされていない場合は、もう少し関与して複雑です。
cd $cegui_folder
cd build/bin/
CEGUI_SAMPLE_DATAPATH=../../datafiles ./CEGUISampleFramework-0Ceguiには、必要な依存関係(現在はGLMのみ)と多くのオプションの依存関係が比較的少ないです。多くの異なるレンダリングライブラリとエンジン、多くの異なる画像ローダー/コーデック(パススルーオプションを使用して)、および多くの異なるXMLパーサーをサポートしているという事実は良いことであり、知らない人だけがそうでなければ伝えます。
Cmakeが何かが見つからなかったと言ったら、あなたはパニックになりません;)!おそらくそれは無害なメッセージです。必要な依存関係が見つからない場合、または依存関係がまったく見つからない場合にのみ心配する必要があります。後者の場合、WindowsおよびMac OS Xでは、おそらく「依存関係」フォルダー(デバッグ/リリース/あらゆるものにコンパイルされた依存関係を含む)をすべてのCEGUIファイルとフォルダーを含むフォルダーに入れませんでした。変数CEGUI_DEPENDENCIES_DIRを使用して、Cmakeの別のフォルダーを指定することもできます。
この番号付けシステムは、実際には非常に重要な目的に役立ちます!それらを維持させてください。 Linuxディストリビューション(およびその他)は、移行を容易にし、新しいCEGUIバージョンの採用を高速化する複数のCEGUI APIバージョンをインストールできます。 Windowsでは、これにより、将来Nugetを使用して事前にコンパイルされたCegui依存関係を提供できます。
これは予想される動作です。まず第一に、リリースモードで常にパフォーマンスをテストする必要がありますが、そこにもカーソルが遅くなります。その理由は、あらゆるアプリケーションがOSカーソルと同じくらい速くカーソルを持つ可能性が非常に低いためです。また、速度はフレームレートと密接に結びついているため、5000 fpsでHelloworldデモを実行すると、差は少なくなりますが、視覚的になります。 OpenGL/Direct3D機能を介して独自のカーソルを同様にレンダリングするゲーム、シミュレーション、またはその他のアプリケーション。ただし、アプリケーションがフレームドロップなしでRasonableフレームレート(> 60 fps)で実行され、そのように認識されない場合、ユーザーにとってカーソル速度は問題ではありません。 OSカーソルを非表示にすると、遅延はおそらくあなたにとって顕著ではないでしょう。
まず、「Dll Hell」という用語は、この文脈で誤って使用されます。 「多くのdllファイルが表示されている、これは地獄でなければならない!」という意味ではありません。 Ceguiライブラリを動的にリンクすることは、想定どおりに機能し、適切な互換性と依存関係に起因する問題の可能性が低いことを保証するための最良の方法です。 Windowsでは、過去の経験(ユーザーの一部が技術的な問題に遭遇した)がより安全であることを示したため、静的リンクではなくCeguiとの動的リンクを使用することをお勧めします。ただし、自分が何をしているのかがわかっている場合は、静的リンクを間違いなく使用できます。ただし、定期的に動的リンクのみをテストすることに注意してください。そのため、cmakeファイルは時代遅れであり、リンクされたライブラリを自分自身に追加する必要がある可能性があります。肯定的な注意事項:1.0バージョンでは、ベースライブラリにそれらの一部をマージすることで作成するDLLSの量を減らします。静的リンクと動的リンクの利点と欠点の短いが間違いなく完全な要約は、http://stackoverflow.com/questions/1993390/static-linking-vs-dynamicリンクにあります
主に、ユーザーがフォーラムでCeguiの速度について不満を言ったとき、デバッグ構成でアプリケーションを実行するか、何か間違ったことをしたことが判明しました。または、プログラムのフレームごとに複数回Ceguiを不必要に更新している場合、遅くなる可能性があります。問題が見つからない場合は、フォーラム/Google検索を実行するのが最善です - 役に立たない場合は、セットアップを詳細に説明し、どのような問題を抱えていますか。 Ceguiが遅くなると、特定の機能の非常に具体的な使用が原因である可能性がありますが、これは予想もテストもしませんでした。この場合、フォーラムでユースケースを説明して、解決策を見つけるか、自分で問題を解決できる場合は、Bitbucketでプルレクエストを作成できます。
一般に、Ceguiは非常に高速で、他のGUIライブラリと簡単に速度で競合できます(特にフラッシュベースのライブラリは、OpenGLまたはDirect3Dに直接アクセスしないため)。そこには完全に最適化された複雑なライブラリはありませんが、Ceguiは非常にパフォーマンスが高いと見なされます。これは、CPUで行われた計算とGPUの計算に当てはまります。数百のウィンドウが開いて同時にレンダリングされると、最適に実行されます。
Ceguiが高速であるという最良の証拠は、数百のウィジェットを表示し、複雑な階層を使用する大きな独自のゲームがCeguiを使用して作成されたことです(Torchlight 1、Torchlight 2、Veneticaなど)。
ほとんどのサンプルは、リリースモードで開始された場合、最新のCPUとGPUで1秒あたり3000フレームを超える速度でレンダリングされます。このような速度比較に関して疑わしいベンチマークを引用するのが好きな一部の人々の追加のメモとして:ベンチマークは状況に依存しており、間違った、非効率的または異常な使用法でライブラリの実際の速度を簡単に誤って伝えられる可能性があります。予想される使用法の範囲内で正しく使用すると、Ceguiは非常にうまく機能します。