∇ 델파이 게임 제작 소품

 ▼ Direct3D에서 한글 고속 처리

Delphi

소스有

(나는 예전부터 조합형 한글의 신봉자였다. 비록 회사에서는 완성형이나 unicode의 font engine을 담당하고 있지만서도...)

AVEJ를 만들면서 성능면에서 가장 중요하게 생각한 것이 한글 출력 속도이다. 이 게임은 대화가 많은 부분을 차지 하기 때문이다. 이전에 계속 사용해 왔던 DirectX 7.0은 2D surface가 3D texture로 사용가능하기 때문에 한글을 조합하여 2D surface에 쓰고 그것을 3D texture로 화면에 출력하면 어느 정도 만족할만한 속도를 내었었다.

그런데 문제는 AVEJ를 DirectX 9.0로 개발하겠다고 한 후부터였다. 제일 처음에는 그냥 3D texture에 lock을 걸고 직접 폰트를 렌더링하는 방법을 썼었는데 profiling해 본 결과 모든 부하의 90% 이상을 폰트 출력이 차지하고 있었다. 그래서 결국 내부 character code는 unicode 2.0이며 출력용 폰트셋은 한글 조합형을 사용했다. 그래서 부하를 46%까지 내려서 사용할 수 있게 되었다. 하지만 역시 게임 내에서 텍스트 출력이 차지하는 비율은 여전히 컸다.

그 다음으로는 font caching을 생각했다. 어차피 자주 쓰는 글자가 많지 않을 것이므로 1024*1024 정도의 texture면 cashe buffer로 충분하다고 생각하고 그쪽으로 대세를 기울여 가고 있었다. (게임의 경우에는 유저의 입력을 제외하고는 닫혀진 입력이므로 게임 시작 시에 이미 가장 효율적인 cache를 미리 찾아 놓을 수 있을 것이라 생각한다.) 하지만 '뷁'과 같이 cache buffer에 hit되지 않을 문자를 입력했을 때 texure에 lock을 걸어야 하는 것은 어쩔 수 없는 것이다. 그래서 아예 KSC5601 완성형에서 2350자를 미리 올려 놓고 출력할까하는 생각도 해봤지만 이것 역시 '펲', '똠' 등의 글자 앞에서는 lock을 걸어야 하는 것이었다. (한글을 모두 출력하기 위해서는 11200자 정도가 필요한데 이것을 모두 texture에 올리기 위해서는 font마다 3M정도가 든다.)

조건1. 게임이 시작된 후 폰트 출력을 위해 texture에 lock을 걸고 싶지는 않다.
조건2. Texture의 형태로 사용되는 caching buffer를 최소로 하고 싶다.
조건3. DirectX에서 제공하는 font class는 쓰고 싶지 않다.

그런데 갑자기 이것들을 아주 쉽게 해결할 수 있을 것 같은 생각이 떠올랐다.

그것은 바로 위대한 '한글 조합형!!'. 여태까지 계속, 초성 중성 종성이 조합을 마친 것을 가지고 cache를 하려고 달려들었기 때문에 아주 기본 적인 것을 간과하고 있었다. 조합형의 raw data를 직접 texture에 올려 놓고 한 글자당 2-3번의 blitting만 하면 lock없이 모두 해결되는 것이었다. (font color는 vertext color를 조절하려 구현) 계산기로 계산해본 결과 16*16 크기의 한글을 사용할 때 12000자를 모두 표현하기 위해서도 300*300의 texture buffer만 있으면 되었다. 2의 승수로 texture를 잡는다면 512*256 정도가 되고 이 정도면 ascii과 latin1의 영역도 포함하고 필요한 특수문자도 남는 공간에 집어 넣을 수 있을 것 같다. 사실 글자가 변하지 않는 이상은 조합된 글자가 render target으로 설정된 font 출력용 texture에 남아 있을 것이기 때문에 실제 게임에서 부하율을 더 떨어질 것으로 예상된다.

위의 생각을 가지고 만든 것이 아래의 첨부파일이다. 델파이를 이용해서 가장 간단하게 Direct3D를 구성하고 글자를 출력하도록 했다. 글자로 화면을 가득 채우는 예제인데, 현재 나의 그래픽 카드에서는 FPS가 vertical retrace 비율과 동일한 결과로 나왔다. 즉 한글 출력에 의한 부하는 측정하기 어렵다는 결론이다.

첨부파일 (68K) (Delphi 5에서 작성되었음)