cegui
v0.8.7
http://www.cegui.org.uk
Copyright © 2004 - 2022 Paul D Turner, l'équipe de développement CEGUI et les auteurs contributifs
La majorité des fichiers auxiliaires pour CEGUI, qui étaient auparavant, sont maintenant conservés dans un format "doxygénisé" dans le répertoire DOC / Doxygen - veuillez consulter ces fichiers, ou générer la documentation pour un format plus convivial. Alternativement, visitez http://static.cegui.org.uk/docs pour tous vos besoins de documentation!
Ce qui suit n'est qu'un guide rapide, accédez à nos documents Doxygen pour une documentation plus détaillée.
v0-8 fournit la dernière version stable ABI compatible (à 0.8.x) de CEGUI. Basé sur la norme C ++ 03 et compatible avec les compilateurs les plus courants, y compris Visual Studio 2008-2015. Comme cette branche est compatible ABI, il est possible de remplacer les bibliothèques dynamiques CEGUI de la version 0.8.x par des versions plus récentes 0.8.x, ou vice-versa, sans avoir à recompiler le projet. Cette branche est également la base des nouvelles versions 0.8.x.v0 fournit la dernière version compatible API stable de CEGUI et contient des changements qui brisent l'ABI. Basé sur la norme C ++ 03 et compatible avec les compilateurs les plus courants, y compris Visual Studio 2008-2015. Les versions de cette branche seront utilisées pour la prochaine version de version mineure.default contient des modifications qui ne seront utilisées que dans la prochaine version principale. Basé sur la norme C ++ 11 et compatible avec les compilateurs les plus courants à la date, y compris Visual Studio 2013 ou plus récent. Cette branche est très instable, introduira des changements fondamentaux et brise la compatibilité ABI et API . Nous ne vous recommandons pas de l'utiliser en production, sauf si vous dépendez fortement d'une fonctionnalité et en avons déjà discuté avec un développeur de CEGUI: il est recommandé de vous rendre compte de tous les risques potentiels. Dans le cas général, il est conseillé d'utiliser l'une des branches stables, pour vous faire économiser beaucoup de maux de tête. Les branches v0-8 et v0 sont considérées comme stables mais subissent des fixes de bogues et de petits changements, qui ne cassent pas respectivement ABI et API. Ces changements présentent bien sûr un faible risque qu'il puisse y avoir des problèmes temporaires pour le moment dans les branches. Si vous remarquez des bogues dans ces succursales, veuillez nous les signaler dès que possible - utilisez le forum et / ou nos canaux IRC #cegui et #cegui-devel sur irc.freenode.net pour nous informer. Veuillez considérer que nous ne sommes pas disponibles sur IRC 24 heures par jour, mais n'hésitez pas à s'y informer jusqu'à ce que nous répondons. En cas de doute quelle branche utiliser, n'hésitez pas à nous demander de cette façon. Pour l'utilisation de la production, nous recommandons généralement d'utiliser une version de version stable. Une liste de versions peut être trouvée sur le site Web.
Nous sommes les plus heureux avec des demandes de traction propres contenant des engagements de conscience avec des messages de validation appropriés . Nous acceptons également les correctifs simples , mais nous facilitons plus facilement votre contribution en un seul clic accélère considérablement le processus d'examen.
Voici une explication sur la façon de fourrer à partir de notre référentiel, de commettre des modifications dans votre fourche et de créer une demande de traction ciblant la bonne branche: https://confluence.atlassian.com/display/bitbucket/fork+a+repo ,+compare+code ,+ etcreate++a+Requequest
Veuillez également garder à l'esprit pour cibler le bon référentiel. Nous préférons cibler la branche compatible ABI si possible. Sinon, les API compatibles. Pour plus d'informations sur la compatibilité ABI / API, veuillez lire cette page: https://community.kde.org/polices/binary_compatibilité_issues_with_c%2b%2B
En cas de doute quelle branche cibler, veuillez nous contacter!
Le script suivant est plus ou moins universel pour les systèmes * Nix et les fenêtres. Des modifications mineures peuvent être nécessaires.
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 ../À ce stade, des makefiles, des fichiers de projet ou quelque chose d'autre seront générés. La prochaine étape dépend de ce que c'est.
Pour Makefiles, il suffit de courir
cd $cegui_folder
cd build/
makePour Visual Studio Solutions, double-cliquez, modifiez le mode de construction en conséquence (libération, débogage, ...) et appuyez sur Build.
Cette section n'a de sens que sur les systèmes de type * Nix.
Assurez-vous que le bon CMAKE_INSTALL_PREFIX est défini au moment de la configuration. Rerrons alternativement CMake et le définir. Par défaut, il devrait être /usr/local/ mais vous pouvez vouloir /usr/ .
cd $cegui_folder
cd build/
sudo make installSi vous avez installé CEGUI à l'échelle du système, appelez simplement:
CEGUISampleFramework-0S'il est préférable de l'appeler à partir de la ligne de commande, car il vous demandera de sélectionner un rendu au cas où vous en aurez plus de 1.
Si vous n'avez pas d'installation à l'échelle du système, c'est un peu plus impliqué et compliqué.
cd $cegui_folder
cd build/bin/
CEGUI_SAMPLE_DATAPATH=../../datafiles ./CEGUISampleFramework-0CEGUI a relativement peu de dépendances requises (actuellement uniquement GLM) et de nombreuses dépendances facultatives . Le fait qu'il prenne en charge de nombreuses bibliothèques et moteurs de rendu différents, de nombreux chargeurs / codecs d'image différents (avec des options de passage) et de nombreux analyseurs XML différents est une bonne chose et seule une personne non informée vous dirait le contraire.
Si Cmake vous dit que quelque chose n'a pas été trouvé, vous ne paniquerez pas ;)! C'est probablement un message inoffensif. Vous ne devez vous inquiéter que si une dépendance dont vous savez que vous avez besoin n'est pas trouvée ou si aucune dépendance n'est trouvée du tout. Dans ce dernier cas, sur Windows et Mac OS X, vous n'avez probablement pas mis le dossier "dépendances" (y compris les dépendances compilées dans Debug / Release / What-else-You-Need) dans le dossier contenant tous les fichiers et dossiers CEGUI. Vous pouvez également spécifier un autre dossier dans CMake en utilisant la variable CEGUI_DEPENDENCES_DIR.
Ce système de numérotation sert en fait un objectif très important! Veuillez les garder. Il permet aux distributions Linux (et autres) d'installer plusieurs versions API CEGUI à côté de la migration et accélère l'adoption de nouvelles versions CEGUI. Sur Windows, cela nous permettra de vous fournir des dépendances CEGUI précompilées en utilisant Nuget à l'avenir.
Ce comportement est attendu. Tout d'abord, vous devez toujours tester les performances en mode libération, mais même là, le curseur sera plus lent. La raison en est simplement qu'il est très peu probable qu'une application aura un curseur aussi rapidement que le curseur du système d'exploitation. N'oubliez pas non plus que la vitesse est étroitement liée à votre fréquence d'images, donc si vous exécutez la démo Helloworld à 5000 ips, la différence sera moins mais toujours perceptible. Tout jeu, simulation ou autre application qui rend son propre curseur via des fonctions OpenGL / Direct3D de la même manière. Cependant, la vitesse du curseur n'est pas un problème pour les utilisateurs si votre application s'exécute à des fréquences d'images rasonables (> 60 ips) sans chute de trame et ne sera pas perçue comme telle. Une fois que vous cachez le curseur du système d'exploitation, le retard ne vous sera probablement plus perceptible.
Tout d'abord, le terme "DLL Hell" est mal utilisé dans ce contexte. Cela ne signifie pas "Je vois beaucoup de fichiers DLL, ce doit être l'enfer!". Lier dynamiquement la bibliothèque CEGUI est le meilleur moyen de faire fonctionner les choses comme ils sont censés le faire et garantir une bonne compatibilité et un faible risque de problèmes sur les dépendances. Sur Windows, nous vous recommandons d'utiliser des liens dynamiques avec CEGUI plutôt que des liens statiques, car l'expérience passée (certains utilisateurs ont rencontré des problèmes techniques) nous a montré que cela est plus sûr. Cependant, si vous savez ce que vous faites, vous pouvez certainement utiliser des liens statiques. Sachez cependant que nous ne testons que des liens dynamiques régulièrement, afin que les fichiers CMake puissent être obsolètes et vous devrez peut-être ajouter des bibliothèques liées à votre IDE vous-même, etc. Sur une note positive: dans la version 1.0 à venir, nous réduirons la quantité de DLLS que CEGUI crée en fusionnant certaines d'entre elles dans la bibliothèque de base. Un résumé court mais certainement pas complet des avantages et des inconvénients du lien statique vs dynamique peut être trouvé ici: http://stackoverflow.com/questions/1993390/static-liking-vs-nynamic-liking
La plupart du temps, lorsque les utilisateurs se sont plaints dans les forums de la vitesse de CEGUI, il s'est avéré qu'ils ont exécuté l'application dans la configuration de débogage ou ont fait quelque chose de mal: cela peut être lent si vous chargez des ressources / fichiers de mise en page à chaque trame ou provoquant des mises à jour et des événements inutiles. Ou cela peut être lent si vous mettez inutilement à jour CEGUI plusieurs fois par trame dans votre programme. Si vous ne trouvez pas le problème, il est préférable d'effectuer une recherche Forum / Google et - si vous ne trouvez rien d'utile - pour décrire votre configuration en détail et quels problèmes vous avez. Lorsque CEGUI est lent, il peut également être dû à une utilisation très spécifique de caractéristiques spécifiques, que nous ne nous attendions pas ou ne testons pas. Dans ce cas, nous aimerions que vous décriviez votre cas d'utilisation dans le forum afin que nous puissions trouver une solution ou, si vous êtes capable de résoudre le problème vous-même, créez une request de traction sur Bitbucket.
En général, CEGUI est très rapide et peut facilement rivaliser avec d'autres bibliothèques d'interface graphique à la vitesse (en particulier celles basées sur Flash, car ils n'accétent pas directement OpenGL ou Direct3D). Bien qu'aucune bibliothèque complexe ne soit jamais parfaitement optimisée, CEGUI peut être considéré comme très performant. Cela est vrai pour les calculs effectués sur le CPU ainsi que ceux du GPU. Il fonctionne toujours de manière optimale lorsque des centaines de fenêtres sont ouvertes et rendues en même temps.
La meilleure preuve que CEGUI est rapide est que les grands jeux propriétaires, qui affichent des centaines de widgets et utilisent des hiérarchies complexes, ont été fabriqués à l'aide de CEGUI (Torchlight 1, Torchlight 2, Venetica, etc.).
La plupart de nos échantillons, s'ils sont démarrés en mode de libération, rendront à des vitesses supérieures à 3000 images par seconde sur un CPU et un GPU modernes. Comme note supplémentaire pour certaines personnes qui aimaient citer des repères douteux concernant de telles comparaisons de vitesse: les repères dépendent de la situation et pourraient facilement déformer la vitesse réelle d'une bibliothèque par une utilisation erronée, inefficace ou inhabituelle. S'il est utilisé correctement et à l'intérieur des limites de l'utilisation attendue, CEGUI fonctionne extrêmement bien.
