CEGUI 그냥 사용하기엔 정말 무겁습니다

CEGUI 그냥 사용하기엔 정말 무겁습니다.

|

CEGUI분석

2008.03.30 00:07

옥이(jjylover)

http://cafe.naver.com/cegui/48

현재 버젼이 어느 정도 안정화 단계에 접어 들었기 때문에 추후 버젼업 시에 관련 부분 패치를 포기하시고,

라이브러리 자체를 뜯어 고치셔야 상용게임 수준에서는 필요하다고 봅니다.

 

1. freetype라이브러리의 실시간 비트맵폰트 생성 부분.

내부 캐싱은 지원하질 않습니다. 특정 비트맵폰트가 필요하면 그 폰트의 페이지에 있는 모든 폰트를 그려넣은 텍스쳐를 생성합니다. 정확히 유니코드의 완성형 코드 구성이 어떻게 이뤄졌는지는 모르겠으나 "가"라는 글자를 치면.."가 갸 거 겨"와 같은 앞 뒤에 있을 수 있는 글자가 포함된 텍스쳐를 생성한다는 겁니다. 이는 소스상에서 수정할 수 있습니다. 어떤거였는지 생각은 나질 않으나 CEGUIText? 클래스의 선언부에 이 텍스쳐 안에 포함될 글자의 숫자를 define해놓은게 있습니다. 아마 256 정도로 define을 해놨는데 확실히 그 보다 작은 수로 하면 텍스쳐 생성 및 write시간이 적게 걸립니다. 장단점은 있겠죠? 텍스쳐를 크게 만들고 연관글자의 입력시 텍스쳐 생성에 대한 시간이 없을 수 있다는 겁니다. 이러한 부분은 비트맵폰트 텍스쳐의 캐싱코드를 포함해서 만들어야 될 거란 생각이 듭니다.

 

2. 지나친 update()함수의 호출.

UI라이브러리는 업데이트 함수의 호출을 통해 메모리버퍼의 내용과 프로퍼티 설정 내용을 동일시 시켜줍니다. CEGUI의 업데이트는 너무 무겁고, 너무 자주 호출됩니다. 특정 프로퍼티 설정이 변경이 되면 바로 업데이트 함수를 호출해주면서 버퍼의 내용과 프로퍼티를 동일 시 시켜주는데 그럴 필요 없다는 겁니다. 렌더링 전에 한 번만 호출해 주면 된다는 겁니다.

 

3. CEGUI::String클래스.

요 놈은 std::string클래스를 랩핑해서 만든 클래스 입니다. 맵 저장 시 정렬 순서에 대한 오퍼레이터와 몇 가지 차이점이 있으나 큰 차이는 보이질 않습니다. 그런데!!!! 디버깅 시에 String객체의 내용을 조사식 창에서 확인할 수 없습니다. 팁이라면 std::string과 CEGUI::String클래스간의 변환은 c_str()매서드를 통해 이루어질 수 있습니다. 이 클래스에 대한 중요한 얘기를 할게 있었는데 잠깐 다른 생각 하는세 까먹었습니다.

 

4. UTF-8 인코딩

이 놈 역시 상당히 거슬립니다. CEGUI에 들어가는 문자열은 모두 UTF-8로 인코딩을 시켜야합니다. 멀티바이트와 유니코드는 알겠는데UTF-8? 음 저 역시 깊게 설명 드릴 수는 없고 UTF-32인코딩 방식이 일반적으로 쓰이는 방식이기 때문에 UTF-8인코딩 형식의 문자열로 바꿀려면 멀티바이트 설정의 솔루션에서는 멀티바이트(UTF-32)를 유니코드로 변환 하고 이걸 다시 멀티바이트(UTF-8)로 변환을 거쳐야 합니다. 변환 관련 Flag중에 인코딩 형식을 설정해주는게 있습니다.

 

5. 지나친 Render()함수의 호출.

Update()함수와는 또 다른 개념입니다. 프레임윈도우에 CEGUIStaticImage를 3개를 attach시킨 캐릭터 상태표시창이 있었는데 이거 하나 그릴 때 Render()함수가 27번이 호출이 됐습니다. 사각형 이미지의 경우(물론 룩앤필 설정에서 이를 최소화 시킬 수 있습니다. staticimage의 looknfeel설정을 각 테두리 이미지는 하나도 없에고 배경만 남기는 겁니다.)Left-Top, Left-Middle, Left-Bottom과 같이 각 각을 9번 렌더링 합니다. 이걸 최적화 시키기 위해서는 CEGUITexure클래스의 연관관계를 파악 후에 Update()함수에 의해 최종적으로 완성된 버퍼를 하나의 텍스쳐에 옮겨담고 한 번만 렌더링 하는 겁니다.

 

6. 수 많은 예외처리

예외처리는 때론 유용하지만 때론 불편합니다.

 

 

제가 사용하면서 느낀 건 이 정도의 이유라 상용게임에서 사용하기엔 무리가 있다는겁니다.

이 작성자의 게시글 구독하기 |더보기 http://acasia.na.mu http:://actionslove.tistory.com ..

덧글 4개

|

등록순

|

조회수 916

북마크

|

인쇄

|

신고

• 프리스

  2008/03/30 20:37답글

  신고

  오~ 그렇군요.. 시간 절약이 많이 되는 정보네요
  감사합니다 ^^

• contacoonta

  2008/04/30 17:01답글

  신고

  연구하신 내용을 이렇게 보기좋게 올려주셔서 정말 감사드립니다.
  지금 회사 프로젝트 진행하면서 CEGUI 로 ui 구현하려고 하는데, 이글을 보고 많이 고민이 됩니다.
  현재는 CustomUI 를 개조해서 쓰고 있는데요 ... CEGUI 퍼포먼스 문제가 제일 고민이네요 ㅡㅡ;;;

• 바지

  2008/07/22 11:55답글

  신고

  1번에 내부 캐싱이 무슨 뜻인지 잘 모르겠습니다. 구체적으로 설명해줄 수 있나요?

• 혜윰

  2008/07/22 12:50답글

  신고

  사용하지 않는 텍스쳐와 사용하는 텍스쳐를 구분하여 적절한 타이밍에 메모리에서 해제를 하는 것과 같은 일을 캐싱이라는 단어로 표현했습니다. CEGUI라이브러리 내부적으로 이러한 글자 텍스쳐에 대한 캐싱을 하지 않기 때문에 프레임워크의 업데이트 타임에 레퍼런스 카운트를 체크해서 메모리를 해제 해주는 부분을 구현할 필요가 있을 듯 합니다. 내부적으로는 조합형 폰트를 출력할 때 해당 폰트의 앞 뒤 몇개를 동시에 만듭니다. 이렇게 만들어진 텍스쳐를 맵에서 관리를 하구요. 텍스쳐맵에 대한 해제 시점을 CEGUI::System을 해제 할 때 함께 메모리에서 삭제 됩니다.