cegui
v0.8.7
http://www.cegui.org.uk
Copyright © 2004-2022 Paul D Turner, Cegui 개발 팀 및 기고 작가
일반 텍스트였던 Cegui에 대한 보조 파일의 대부분은 이제 Doc/Doxygen 디렉토리 내의 "doxygenised"형식으로 유지됩니다. 해당 파일을 참조하거나보다 친숙한 형식으로 문서를 생성하십시오. 또는 모든 문서 요구 사항에 대해서는 http://static.cegui.org.uk/docs를 방문하십시오!
다음은 빠른 시작 가이드입니다. 자세한 내용은 Doxygen 문서로 이동하십시오.
v0-8 Cegui의 최신 안정 ABI 호환 (0.8.x 릴리스) 버전을 제공합니다. C ++ 03 표준을 기반으로하며 Visual Studio 2008-2015를 포함하여 가장 일반적인 컴파일러와 호환됩니다. 이 지점은 ABI 호환이므로 Cegui Dynamic Libraries of Version 0.8.x를 최신 0.8.x 버전으로 교체하거나 프로젝트를 다시 컴파일하지 않고도 그 반대로 대체 할 수 있습니다. 이 지점은 또한 새로운 0.8.x 릴리스의 기반입니다.v0 Cegui의 최신 안정 API 호환 버전을 제공하며 ABI를 깨는 변경 사항이 포함되어 있습니다. C ++ 03 표준을 기반으로하며 Visual Studio 2008-2015를 포함하여 가장 일반적인 컴파일러와 호환됩니다. 이 분기의 버전은 다음 마이너 버전 릴리스에 사용됩니다.default 에는 다음 주요 버전에서만 사용할 변경 사항이 포함되어 있습니다. C ++ 11 표준을 기반으로하며 Visual Studio 2013 또는 Newer를 포함하여 가장 일반적인 최신 컴파일러와 호환됩니다. 이 지점은 매우 불안정하고 근본적인 변화를 일으키고 ABI 및 API 호환성을 깨뜨릴 것입니다 . 기능에 크게 의존하고 이전에 CEGUI 개발자와 논의하지 않는 한이 기능을 제작에서 사용하는 것이 좋습니다. 모든 잠재적 위험을 인식하도록 권장됩니다. 일반적인 경우에는 안정된 가지 중 하나를 사용하여 두통을 많이 절약하는 것이 좋습니다. v0-8 및 v0 지점은 안정적 인 것으로 간주되지만 버그 고정 및 작은 변화를 겪어 각각 ABI 및 API를 끊지 않습니다. 물론 이러한 변화는 지점에서 순간에 일시적인 문제가있을 수 있다는 작은 위험을 초래합니다. 해당 지점에 버그가 표시되면 가능한 빨리 당사에 버그를 신고하십시오. 포럼 및/또는 IRC 채널 #cegui 및 #cegui-devel 의 irc.freenode.net 사용하여 우리에게 알려주십시오. IRC에서 하루에 24 시간 동안 사용할 수 없지만 응답 할 때까지 자유롭게 유휴 상태를 유지하십시오. 어떤 지점을 사용할 지 의심 스럽다면, 이런 식으로 우리에게 물어보십시오. 생산 사용을 위해서는 일반적으로 안정적인 릴리스 버전을 사용하는 것이 좋습니다. 릴리스 목록은 당사 웹 사이트에서 찾을 수 있습니다.
우리는 Conder Commit 메시지가 포함 된 깨끗한 풀 요청 으로 가장 행복합니다. 우리는 또한 일반 패치를 받아들이지 만 한 번의 클릭으로 귀하의 기여를 더 쉽게 수락하면 검토 프로세스 속도가 크게 높아집니다.
다음은 저장소에서 포크하고 포크를 변경하고 오른쪽 지점을 대상으로 한 풀 요청을 작성하는 방법에 대한 설명입니다.
또한 올바른 저장소를 타겟팅하려면 명심하십시오. 가능하면 ABI 호환 브랜치를 대상으로하는 것이 좋습니다. 그렇지 않으면 API 호환 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 ../이 시점에서 Makefiles, 프로젝트 파일 또는 다른 것들이 생성됩니다. 다음 단계는 그것이 무엇인지에 따라 다릅니다.
Makefiles의 경우 그냥 실행하십시오
cd $cegui_folder
cd build/
makeVisual Studio 솔루션의 경우 두 번 클릭하고 그에 따라 빌드 모드를 변경하고 (릴리스, 디버그, ...) 빌드를 누르십시오.
이 섹션은 *닉스와 같은 시스템에서만 의미가 있습니다.
구성 시간에 올바른 cmake_install_prefix가 설정되어 있는지 확인하십시오. 대안 적으로 CMAKE를 다시 실행하고 설정하십시오. 기본적으로 /usr/local/ 이어야하지만 /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의 경우, "Debug/Release/Nothing-Else-You-Need에서 컴파일 된 종속성을 포함하여"종속성 "폴더를 모든 CEGUI 파일 및 폴더를 포함하는 폴더에 넣지 않았을 것입니다. 변수 CEGUI_DENFERISE_DIR을 사용하여 CMAKE의 다른 폴더를 지정할 수도 있습니다.
이 번호 시스템은 실제로 매우 중요한 목적으로 사용됩니다! 우리가 그들을 지키도록 해주세요. Linux 배포판 (및 기타)이 여러 Cegui API 버전을 설치하여 마이그레이션을 완화하고 새로운 CEGUI 버전의 채택을 속도를 높일 수 있습니다. Windows에서는 향후 Nuget을 사용하여 선행 CEGUI 의존성을 제공 할 수 있습니다.
이것은 예상되는 행동입니다. 우선 릴리스 모드에서 항상 성능을 테스트해야하지만 커서도 느리게됩니다. 그 이유는 단순히 OS 커서만큼 빠른 커서를 가질 가능성이 거의 없기 때문입니다. 또한 속도는 프레임 속도와 밀접하게 연결되어 있으므로 5000 fps에서 Helloworld 데모를 실행하면 차이가 덜 눈에 띄게됩니다. OpenGL/Direct3D 기능을 통해 자체 커서를 렌더링하는 모든 게임, 시뮬레이션 또는 기타 응용 프로그램도 비슷하게 기능합니다. 그러나 애플리케이션이 프레임 방울이없는 라스로 가능한 프레임 속도 (> 60 fps)로 실행되면 인식되지 않는 경우 사용자에게는 커서 속도가 문제가되지 않습니다. OS 커서를 숨기면 지연이 더 이상 눈에 띄지 않을 것입니다.
우선, "dll hell"이라는 용어는이 맥락에서 잘못 사용됩니다. "많은 DLL 파일을 보았습니다. 이것은 지옥이어야합니다!"를 의미하지는 않습니다. CEGUI 라이브러리를 동적으로 연결하는 것은 예상대로 작동하는 것이 가장 좋은 방법이며, 양호성이 우수하고 종속성으로 인해 발생할 수있는 문제가 적을 가능성을 보장합니다. Windows에서는 과거의 경험 (일부 사용자가 기술적 인 문제에 부딪친)이 우리에게 이것이 더 안전하다는 것을 보여 주었기 때문에 정적 링크 대신 Cegui와 동적 링크를 사용하는 것이 좋습니다. 그러나 당신이 무엇을하고 있는지 알고 있다면 정적 링크를 사용할 수 있습니다. 우리는 정기적으로 동적 링크 만 테스트하므로 CMAKE 파일은 구식이 될 수 있으며 링크 된 라이브러리를 IDE에 추가해야 할 수도 있습니다. 긍정적 인 참고 사항 : 다가오는 1.0 버전에서는 일부 DLLS CEGUI가 기본 라이브러리로 병합하여 생성됩니다. 정적 대 동적 링크의 장점과 단점에 대한 짧지 만 확실하지 않은 것은 여기에서 찾을 수 있습니다 : http://stackoverflow.com/questions/1993390/static-linking-vs-dynamic-linking
대부분 사용자가 Cegui의 속도에 대해 포럼에서 불만을 제기했을 때, 디버그 구성에서 응용 프로그램을 실행했거나 잘못한 것으로 판명되었습니다. 모든 프레임마다 레이아웃 리소스/파일을로드하거나 불필요한 업데이트 및 이벤트를 일으키는 경우 속도가 느릴 수 있습니다. 또는 프로그램에서 프레임 당 CEGUI를 여러 번 불필요하게 업데이트하는 경우 속도가 느릴 수 있습니다. 문제를 찾을 수없는 경우 포럼/Google 검색을 수행하는 것이 가장 좋습니다. 도움이되는 것을 찾지 못하면 설정을 자세히 설명하는 것이 가장 좋습니다. Cegui가 느리게되면 우리가 기대하거나 테스트하지 않은 특정 기능을 매우 구체적으로 사용하기 때문일 수도 있습니다. 이 경우 포럼에서 사용 사례를 설명하여 솔루션을 찾거나 문제를 직접 해결할 수있는 경우 Bitbucket에서 풀 수반을 만듭니다.
일반적으로 Cegui는 매우 빠르며 다른 GUI 라이브러리와 쉽게 경쟁 할 수 있습니다 (특히 Flash 기반 라이브러리는 OpenGL 또는 DirecT3D에 직접 액세스하지 않기 때문에). 복잡한 라이브러리는 완벽하게 최적화되지는 않지만 Cegui는 고도로 성능이있는 것으로 간주 될 수 있습니다. 이는 CPU에서 수행 된 계산 및 GPU의 계산에 해당됩니다. 수백 개의 창이 열리고 동시에 렌더링 될 때 여전히 최적으로 실행됩니다.
Cegui가 빠르다는 가장 좋은 증거는 수백 개의 위젯을 표시하고 복잡한 계층을 사용하는 큰 독점 게임이 Cegui (Torchlight 1, Torchlight 2, Venetica 등)를 사용하여 만들어 졌다는 것입니다.
릴리스 모드에서 시작된 경우 대부분의 샘플은 최신 CPU 및 GPU에서 초당 3000 프레임 이상의 속도로 렌더링됩니다. 그러한 속도 비교와 관련하여 모호한 벤치 마크를 인용하는 것을 좋아하는 일부 사람들에게 추가적인 메모로서 : 벤치 마크는 상황에 따라 다르며 잘못, 비효율적이거나 비효율적 인 사용으로 도서관의 실제 속도를 쉽게 잘못 표현할 수 있습니다. 예상 사용의 범위 내에서 올바르게 사용하는 경우 Cegui는 매우 잘 수행됩니다.
