cegui
v0.8.7
http://www.cegui.org.uk
Copyright © 2004 - 2022 Paul D Turner, a equipe de desenvolvimento de Cegui e autores contribuintes
A maioria dos arquivos auxiliares para o CEGUI, que costumava ser texto simples, agora é mantido em um formato "doxigenizado" no diretório Doc/Doxygen - consulte esses arquivos ou gerar a documentação para um formato mais amigável. Como alternativa, visite http://static.cegui.org.uk/docs para todas as suas necessidades de documentação!
O que se segue é apenas um guia de partida rápida, vá para nossos documentos de doxygen para uma documentação mais detalhada.
v0-8 fornece a versão mais recente da versão estável compatível com a ABI (para 0,8.x) do CEGUI. Com base no padrão C ++ 03 e compatível com os compiladores mais comuns, incluindo o Visual Studio 2008-2015. Como essa filial é compatível com a ABI, é possível substituir as bibliotecas dinâmicas da CEGUI da versão 0.8.x por versões 0.8.x mais recentes, ou vice-versa, sem precisar recompensar o projeto. Esta filial também é a base para novas liberações 0.8.x.v0 fornece a mais recente versão compatível com API estável do CEGUI e contém alterações que quebram o ABI. Com base no padrão C ++ 03 e compatível com os compiladores mais comuns, incluindo o Visual Studio 2008-2015. As versões desta filial serão usadas para a próxima versão da versão menor.default contém alterações que serão usadas apenas na próxima versão principal. Com base no padrão C ++ 11 e compatível com os compiladores atualizados mais comuns, incluindo o Visual Studio 2013 ou mais recentes. Este ramo é altamente instável, introduzirá mudanças fundamentais e quebrará a compatibilidade com ABI e API . Não recomendamos que você use isso na produção, a menos que dependa fortemente de um recurso e discutisse isso com um desenvolvedor da CEGUI antes: isso é recomendado para que você esteja ciente de todos os riscos em potencial. No caso geral, você é aconselhado a usar uma das filiais estáveis, para economizar muita dor de cabeça. As ramificações v0-8 e v0 são consideradas estáveis, mas passam por correções de insetos e pequenas alterações, que não quebram ABI e API, respectivamente. É claro que essas mudanças introduzem um pequeno risco de que haja problemas temporários no momento nos ramos. Se você notar algum bug nessas filiais, informe -os o mais rápido possível - use o fórum e/ou nossos canais IRC #cegui e #cegui-devel no irc.freenode.net para nos informar. Por favor, considere que não estamos disponíveis no IRC 24 horas por dia, mas sinta -se à vontade para ociosos até respondermos. Em caso de dúvida, qual ramo usar, sinta -se também à vontade para nos perguntar dessa maneira. Para uso da produção, geralmente recomendamos usar uma versão estável de liberação. Uma lista de lançamentos pode ser encontrada no nosso site.
Somos mais felizes com solicitações de tração limpas que contêm consciência com compromissos com mensagens de comprometimento adequadas . Também aceitamos patches simples , mas facilitamos a aceitação de sua contribuição com um clique, acelera bastante o processo de revisão.
Aqui está uma explicação sobre como forçar o nosso repositório, cometer mudanças no garfo e criar uma solicitação de tração direcionada ao ramo certo: https://confluence.atlassian.com/display/bitbucket/fork+raQuest
Lembre -se também de atingir o repositório certo. Preferimos direcionar o ramo compatível com ABI, se possível. Caso contrário, os compatíveis com API. Para obter informações sobre compatibilidade com ABI/API, leia esta página: https://community.kde.org/policies/binary_compatibility_issues_with_c%2b%2b
Em caso de dúvida, qual ramo segmentar, entre em contato conosco!
O script a seguir é mais ou menos universal para os sistemas e Windows *nix. Pequenas alterações podem ser necessárias.
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 ../Neste ponto, makefiles, arquivos de projeto ou outra coisa serão gerados. O próximo passo depende do que é isso.
Para makefiles, basta correr
cd $cegui_folder
cd build/
makePara soluções do Visual Studio, clique duas vezes, altere o modo de construção de acordo (liberação, depuração, ...) e pressione Build.
Esta seção faz sentido apenas em sistemas semelhantes a nix.
Verifique se você tem o cmake_install_prefix correto definido no horário de configuração. Alternativo execute novamente o cmake e defina. Por padrão, deve ser /usr/local/ mas você pode querer /usr/ .
cd $cegui_folder
cd build/
sudo make installSe você instalou o CEGUI em todo o sistema, basta ligar:
CEGUISampleFramework-0Se for preferível chamá -lo da linha de comando, pois solicitará que você selecione um renderizador, caso você tenha mais de 1 disponível.
Se você não possui em todo o sistema instalado, é um pouco mais envolvido e complicado.
cd $cegui_folder
cd build/bin/
CEGUI_SAMPLE_DATAPATH=../../datafiles ./CEGUISampleFramework-0O CEGUI possui relativamente poucas dependências necessárias (atualmente apenas GLM) e muitas dependências opcionais . O fato de ele suportar muitas bibliotecas e motores de renderização diferentes, muitos carregadores de imagem/codecs diferentes (com passagens através de opções) e muitos analisadores XML diferentes é uma coisa boa e apenas uma pessoa desinformada lhe diria o contrário.
Se Cmake lhe disser que algo não foi encontrado, você não entrará em pânico ;)! Provavelmente é uma mensagem inofensiva. Você só deve se preocupar se uma dependência que você sabe que precisa não for encontrada ou se nenhuma dependência for encontrada. No último caso, no Windows e no Mac OS X, você provavelmente não colocou a pasta "Dependências" (incluindo as dependências compiladas em depuração/liberação/o que quer que seja-else-vítima) na pasta que contém todos os arquivos e pastas Cegui. Você também pode especificar outra pasta em cmake usando a variável CEGUI_DEPENDENCENS_DIR.
Este sistema de numeração realmente serve a um propósito muito importante! Por favor, vamos mantê -los. Ele permite que as distribuições do Linux (e outras) instalem várias versões da API CEGUI, juntamente com o que facilita a migração e acelera a adoção de novas versões CEGUI. No Windows, isso nos permitirá fornecer dependências Cegui pré -compiladas usando o NUGET no futuro.
Este é o comportamento esperado. Primeiro, você deve sempre testar o desempenho no modo de liberação, mas mesmo lá o cursor será mais lento. O motivo é simplesmente que é muito improvável que qualquer aplicativo tenha um cursor tão rápido quanto o cursor do sistema operacional. Lembre -se também de que a velocidade está intimamente ligada à sua taxa de quadros; portanto, se você executar a demonstração do Helloworld a 5000 fps, a diferença será menor, mas ainda é notável. Qualquer jogo, simulação ou outro aplicativo por aí que torne seu próprio cursor via funções OpenGL/Direct3D da mesma forma. No entanto, a velocidade do cursor não é um problema para os usuários se o seu aplicativo é executado a taxas de quadros rasonáveis (> 60 fps) sem queda de quadro e não serão percebidas como tal. Depois de esconder o cursor do sistema operacional, o atraso provavelmente não será mais perceptível para você.
Primeiro, o termo "DLL Hell" é usado incorretamente neste contexto. Isso não significa "eu vejo muitos arquivos DLL, isso deve ser um inferno!". Vincular dinamicamente a biblioteca Cegui é a melhor maneira de ter coisas funcionando como elas deveriam e garantir uma boa compatibilidade e uma baixa chance de problemas decorrentes das dependências. No Windows, recomendamos usar a ligação dinâmica ao CEGUI em vez de vincular estática, pois a experiência passada (alguns dos usuários se depararam com problemas técnicos) nos mostraram que isso é mais seguro. No entanto, se você souber o que está fazendo, pode definitivamente usar a ligação estática. Esteja ciente, porém, de que testamos apenas a ligação dinâmica regularmente, para que os arquivos cmake possam estar desatualizados e você pode precisar adicionar bibliotecas vinculadas ao seu IDE etc. em uma nota positiva: na próxima versão 1.0, reduziremos a quantidade de DLLs Cegui cria por meio delas na biblioteca base. Um resumo curto, mas definitivamente não completo, das vantagens e desvantagens da ligação estática versus dinâmica pode ser encontrada aqui: http://stackoverflow.com/questions/1993390/static-linking-vs-dynamic linking
Principalmente quando os usuários se queixaram nos fóruns sobre a velocidade de Cegui, acabou sendo que eles executaram o aplicativo na configuração de depuração ou fizeram algo errado: pode ser lento se você estiver carregando recursos/arquivos de layout em todos os quadros ou causando atualizações e eventos desnecessários. Ou pode ser lento se você estiver atualizando desnecessariamente o CEGUI várias vezes por quadro em seu programa. Se você não conseguir encontrar o problema, é melhor realizar uma pesquisa de fórum/Google e - se você não encontrar nada útil - descrever sua configuração em detalhes e quais problemas você tem. Quando o CEGUI fica lento, também pode ser devido a um uso muito específico de recursos específicos, que não esperamos nem testamos. Nesse caso, gostaríamos que você descreva seu caso de uso no fórum, para que possamos encontrar uma solução ou, se você for capaz de resolver o problema, criar uma solicitação de tração no Bitbucket.
Em geral, o CEGUI é muito rápido e pode competir facilmente com outras bibliotecas da GUI em velocidade (especialmente as baseadas em flash, pois não acessam diretamente o OpenGL ou Direct3D). Embora nenhuma biblioteca complexa seja perfeitamente otimizada, o CEGUI pode ser considerado altamente executado. Isso é verdade para os cálculos feitos na CPU, bem como para os da GPU. Ele ainda funciona de maneira ideal quando centenas de janelas são abertas e renderizadas ao mesmo tempo.
A melhor prova de que Cegui é rápida é que grandes jogos proprietários, que exibem centenas de widgets e usam hierarquias complexas, foram feitas usando Cegui (Torchlight 1, Torchlight 2, Vereticha, etc.).
A maioria de nossas amostras, se iniciada no modo de liberação, renderizará a velocidades acima de 3000 quadros por segundo em uma CPU e GPU moderna. Como uma nota adicional para algumas pessoas que gostavam de citar benchmarks duvidosos em relação a essas comparações de velocidade: os benchmarks são dependentes da situação e podem facilmente deturpar a velocidade real de uma biblioteca por uso errado, ineficiente ou incomum. Se usado corretamente e dentro dos limites do uso esperado, o CEGUI tem um desempenho extremamente bom.
