[한글 입출력] 완성형

OpenGL 한글 (입)출력 라이브러리 "glan"에 대한 포럼입니다.

Moderator: 류광

?

[한글 입출력] 완성형

Post by ? »

안녕하세요!

계시판을 보니 대부분 조합형으로 만드시네요!

조합형/완성형 둘다 만들어 봤지만 완성형이 성능이 뛰어나던데

개발기간도 짧고...

조합형은 조합하는 곳에서 연산을 하기때문에 완성형보다 성능이 떨어지는거

같네요!
eoh
Posts: 135
Joined: 2001-07-20 09:00
Location: REAL:DREAM
Contact:

Post by eoh »

에에.. 그렇긴 하네요..
하지만, 완성형을 비트맵형태로 저장하거나 하면,
텍스쳐를 사용하게 될경우.. 엄청난 낭비가 되겠죠.. ;ㅁ;

뭐.. 그래서 한자의 구현 같은것까지 고려하면,
속도의 문제 아니면 메모리쪽의 문제가 생기게 될것으로 예상되는군요..
noerror

완성형 메모리 문제

Post by noerror »

사용하고자 하는 프로그램마다 다르긴 하겠지만 그냥 PC환경의 게임이라면 폰트의 용량 문제는 심각할 정도는 아닙니다.

http://digibath.com/noerror/download/gulim12.gif

이 폰트는 굴림 12폰트 완성형폰트들 뽑은 셈플인데, 픽셀다 1비트로 저장한다면 40kb 정도될 거 같습니다. 텍스처에 글자 조합해서 출력하는 거야 완성형이나 조합형이나 같으니 조합형으로 처리한다고 해도 메모리상 이득은 별로 없다고 봐도 될거 같습니다. (물론 리소스 제한이 극심한 미니 게임기면 모르겠습니다만...)

아래는 허접하지만 나름대로 만들어 쓰던거 정리했던 글입니다. T_T
http://www.gamecode.org/article.php3?no=1501&field=tip
ccash

유니코드를 쓸려면..

Post by ccash »

제 생각에도 PC 게임이라면 메모리를 좀 더 써서 완성형을 사용하는게
글자도 예쁘고, 프로그램도 간편해서 좋겠다고 생각했습니다.

근데, 요즘은 네트웍 기능이 추가되면서 채팅도 가능하게 하고..
그렇게 된다면, 역시 유니코드를 지원하는 편이 좋겠지요.
완성형의 경우에는 '쀍' 과 같은 글자는 표현할 수 없잖아요.
'아햏햏'도 안되니까요..

따라서, 코드체계는 유니코드(또는 조합형)을 사용하면서, 폰트는 완성형
방식의 폰트를 쓰는 편이 가장 좋다고 생각합니다.
KS-5601 의 완성형 한글은 이젠 좀 부족하다고 생각합니다.
지나가는이

Post by 지나가는이 »

맨 위에분이 말씀하신 연산에 대한건 별로 신경 안써도 될거 같군요.

요즘 컴퓨터들이 워낙 좋아서 그런 연산은 있으나 마나한 지경에

이르렀죠..^^;

마찬가지로 완성형 폰트의 용량도 별로 문제될게 없을 정도네요.

확장 완성형이라고 해도 저장은 비트단위로 할테니 그리 큰 용량은 안될거 같네요.

ps .대충 계산해봐서..

11171글자(유니코드에서 표현되는 한글수)*32바이트(16x16폰트 크기)=
대략 349kb이군요.
류광
Posts: 3805
Joined: 2001-07-25 09:00
Location: GPGstudy
Contact:

Post by 류광 »

그런데 글꼴 데이터를 텍스처에 올린다고 하면, OpenGL의 경우 텍셀 형식이 최하가 4 비트라고 알고 있습니다(ALPHA4, INTENSITY4 등). 따라서 16x16 글꼴 한 글자에 필요한 텍스처 메모리는 32*4=128 바이트가 되고, 결국 확장 완성형에 필요한 텍스처 메모리는 적어도 1 메가 이상이라는 계산이 나옵니다...

...근데 계산이 맞나요? ^^;;;
eoh
Posts: 135
Joined: 2001-07-20 09:00
Location: REAL:DREAM
Contact:

Post by eoh »

아.. 글쓴거 날려버렸군요.;; 그사이에 글도 늘었고.. 다시 씁니다. ;ㅁ;

음.. 그런데, openGL쪽에서 알파요소만으로 글자를 그릴 수 있나요? 전에 제가 구현할때는 아마 그것이 안되었는지, 적어도 256바이트정도 필요했던것 같습니다만.. (순수 비트맵의 경우, 시스템에 따라 엄청 느려지는 현상이 있어서.. 쓰지 않았었군요. )

openGL쪽에서는 그렇기 때문에.. 아예, 16픽셀정도 크기의 글꼴이라면, 어차피 정보가 필요하니, 투명도라던가, 밝기등, 안티얼라이징 된 글꼴을 사용하는건 어떨가 생각해 봅니다. 그러려면.. 분명, 글자당 256바이트이상이 필요하겠죠.; 그런경우에는 완성형 글꼴보다는, 조합형 글꼴이 훨씬 용량상의 이득이 있다고 생각했었습니다..
다만, 그렇게 안티얼라이징된 글꼴을 분리시켜 조합형의 글꼴을 만드는것이 상당히 귀찮은 일이었기 때문에, 미루고 있었지요..;;

그러나, 분명 완성형 글꼴에도 12픽셀정도의 글꼴이라면, 글꼴의 모양이라던가 하는것에 이점이 있습니다. 조합형 글꼴에 비해서요.

그래서.. 현재로선, 12픽셀 크기의 (확장)완성형 글꼴을 추출하고 있습니다..; 그리고 시간이 되면, 16픽셀의 안티얼라이징된 글꼴을 조합형 글꼴로 만들어볼 계획도 해보고 있습니다만..
noerror

텍스처 메모리

Post by noerror »

제 생각엔 영문자면 몰라도 한글을 비디오 메모리에 전부 올려놓고 찍는 건 무리라고 생각되고, 그냥 텍스처에 완성된 문장을 조합해서 찍는 방법이 가장 무난할 거 같습니다.
이 경우 128x128 짜리 16비트 텍스처를 기준으로 생성할 경우 장당 차지하는 메모리가 약 32kb 정도니까 넉넉하게 10장 정도를 작업 텍스처로 할당해도 320kb 정도 밖에 비디오 메모리를 안 먹을 테니 큰 무리는 없을 거 같네요.
eoh
Posts: 135
Joined: 2001-07-20 09:00
Location: REAL:DREAM
Contact:

Post by eoh »

네. 대량의 글꼴을 사용하게 된다면, 비디오카드에 저장을 할 수 없다는것과, 필요에 의해 메모리에서 텍스쳐로 전사(..)하는 형태가 바람직하다는것에 동의합니다. 그리고 작업텍스쳐의 양에대해서는, 이전의 버전이 그랬지만, 제한을 두는것보다는 기본으로 사용하는양이외에는 동적으로 처리를 하는것이 어떨까 생각해 봅니다..

여담으로.. 32픽셀의 글꼴쯤 되고, 밝기차(안티얼라이징된)가 있게 되면, 10메가쯤 되게 되는군요;
oranke
Posts: 244
Joined: 2002-05-09 09:00

OpenGL에서 1BPP 비트맵을 알파요소만으로 랜더링 하기...

Post by oranke »

오픈지엘은 다 좋은데 텍스쳐 형식 지정하기가 너무 어려워요...
구글을 하루 종일 뒤져 다음 답변을 찾았습니다.
http://groups.google.co.kr/groups?q=tex ... net&rnum=1

픽셀맵의 기본 범위가 [0..0] 이므로 GL_BITMAP으로 지정된 비트맵이 어떤 값이건 모두 시꺼멓게 들어온다는군요. glPixelMap()으로 해당 채널을 변환할 픽셀맵을 지정하면 된다나요~~

제가 델파이 사용자라 예제가 파스칼입니다~~ ^^;;
먼저 다음과 같은 픽셀맵 배열을 선언하고

var
PixelMap : Array[0..1] of Single = (0.0, 1.0);
Buffer : Pointer;

줄이 좍좍 쳐진 16*16짜리 비트맵을 만들어 줍니다.

GetMem(Buffer, 32); // 16*16/8 = 32바이트.
FillChar(Buffer^, 32, $AA); // 텍스쳐에 세로줄 치기..

이걸 16*16짜리 1비트 알파 텍스쳐로 만들 때는 다음과 같습니다.

glPixelMapfv(GL_PIXEL_MAP_I_TO_A, 2, @PixelMap[0]);
glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA, 16, 16, 0, GL_COLOR_INDEX, GL_BITMAP, Buffer);

Image

알파값이 아닌 희고 검은 일반 텍스쳐로 만들 때는 다음과 같네요...

glPixelMapfv(GL_PIXEL_MAP_I_TO_R, 2, @PixelMap[0]);
glTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE, 16, 16, 0, GL_COLOR_INDEX, GL_BITMAP, Buffer);

Image

뒷북 아닌지 모르겠습니다만... 그래도 꾿꾿이 올려봅니다~ ^^;;
그럼...
Last edited by oranke on 2003-06-23 19:30, edited 1 time in total.
oranke
Posts: 244
Joined: 2002-05-09 09:00

Post by oranke »

추가로... 개념만 잡혀 있는 한글 출력 아이디어 입니다... ^^;;

http://www.delmadang.com/cwb-bin/CrazyW ... ackdepth=1
soaringhs
Posts: 230
Joined: 2001-07-30 09:00

Post by soaringhs »

모노 비트맵이면 원하는 위치에 글자를 집어 넣을려면 bit연산이 난무할것 갈군요.
SubTexture 쓰기도 곤란한면도 있고...

개인적으로 간단하게 구현할려고 memDC의 raw bitmap을 바로 SubTexture로 붙일수 있게 8bit grayscale DIB를 폭을 4의 배수로 만들어 (글자폭이 4의 배수가 아닐땐 공간이 좀 낭비되긴하지만...) 쓰고 있습니다.
류광
Posts: 3805
Joined: 2001-07-25 09:00
Location: GPGstudy
Contact:

Post by 류광 »

makefile wrote:모노 비트맵이면 원하는 위치에 글자를 집어 넣을려면 bit연산이 난무할것 갈군요.
아마 DC에 출력하고 그걸 다시 텍스처로 만드는 과정을 걱정하시는거죠?? 그보다는... oranke님이 올려주신 정보는 현재 Glan에서 사용하는 fnt 파일을 텍스처로 만들 때 필요한 작업을 크게 줄여주는 역할을 할 것 같습니다. 실제로 fnt 파일이 딱 저런 1 비트 비트맵 방식이거든요. 지금 Glan은 비트 연산으로 각 비트를 일일이 1 바이트 휘도 값으로 바꾸고 있죠(맞죠 crowy님??).
oranke
Posts: 244
Joined: 2002-05-09 09:00

Post by oranke »

모노 비트맵을 텍스처의 원하는 위치에 넣을 때 bit연산은 필요 없습니다.
GL_UNPACK_ALIGNMENT만 잘 설정해 놓으면 그냥 glTexSubImage 한방으로 해결되죠... ^^;

위에서 말했던 개념을 실제로 코딩 해 봤습니다.
http://myhome.naver.com/oranke/GLHangul/GLHanTest.zip

makefile님 말씀대로 혹시 2진 raw 이미지도 DIB로 만들 수 있는지 테스트 해 봐야겠네요. 그렇게 되면 비트열을 추출하는 코드도 필요없고 조금 더 속도가 빨라질텐데요~~ ^^;;

그럼~~
eoh
Posts: 135
Joined: 2001-07-20 09:00
Location: REAL:DREAM
Contact:

Post by eoh »

에.. 잘 봤습니다.. ^^

음.. 저도 처음에 구현할때, 그냥 모노비트맵으로 구현을 했었는데요.. 작업을 하던 컴퓨터의 그래픽 카드에서는 엄청 느리게 돌아가더군요..;;
점하나당 byte 를 차지하도록 바꿔주는것이 훨씬 더 빠르게(10배이상이었던걸로 기억하는군요;;) 동작하는탓에, 그렇게 구현되었군요..
뭐.. 당시 그래픽카드가 좀 구형(MGA G400) 이기도 합니다마는..;

트루타잎의 큰글자들이라면 모노비트맵의 한계가 심할것 같아서.. 일단, 그쪽에 대한 고려를 더 해봐야 할것 같습니다. 물론, 사무용이라면 작은글자가 더 많겠습니다만, 게임에선 의외로 큰글자들이 중요할 수도 있어서요.. (그래서.. 2가지 종류를 생각해보고 있습니다.; )
음.. 여담으로, 글자들이 커지면, 완성형글꼴에 미리 만들어진 텍스쳐의 사용은 무리가 있을듯하군요;;

라는것으로 이만 줄이도록 하죠.. ^^;
aser0070
Posts: 103
Joined: 2001-10-15 09:00
Location: if

폰트용 텍스쳐를 사용하는 방법에 대해 한가지 올리겠습니다.

Post by aser0070 »

다른건 아니고 폰트용 텍스쳐를 사용하는 방법에 대해 한가지 올리겠습니다.

저도 폰트때문에 고민을 하다가 테스트 해본적이 있는데,,,

그때 방식이 완성형 폰트를 전부 한장에 뽑아놓고 사용하는 방법이었습니다.

텍스쳐 사이즈가 무지 커지겠구나 싶었는데.. 의외로 그렇게 까지 커지지는 않더군요...
(글자크기 12짜리 폰트가 640x576짜리 텍스쳐로 만들어지더군요..)

이걸 1bit 비트맵 포멧으로 사용하려고보니,, 이포멧으로 하드웨어 가속을 지원하지 않는 카드가 많더군요..(거의 대부분..)

어떻할까하다가,, 그걸가지고 DDS파일(DXT1방식)로 만드니 181kbyte 정도 나오더군요.

그래서 그걸가지고 테스트 했습니다. 속도 하나는 무지하게 잘나오던군요..
(GForce4 Ti 440에선 약 1400프레임정도... 라데온 9000에서는 1200프레임 정도 나옵니다.)

방식은 DXT1텍스쳐에,, 글자의 좌표들을 쭈욱 모아뒀다가 버텍스버퍼를 한번 lock한후 구성하여 뿌렸습니다.

단점도 몇가지 있는데,,,

일단 글자를 크게 했을경우,, 용량이 훨씬 늘어난다는 점입니다.(당연한 얘기죠..)

글자크기 16짜리하고 24짜리도 뽑아봤는데,, 16짜리는 341kbyte, 24짜리는 720kbyte입니다.
(이것 이상으로 글자를 크게 써야 한다면,, 텍스쳐 용량때문에 고민을 해야할듯 하네요..^^)

그리고 텍스쳐 사이즈가 문제인데,, 24짜리 글자의 경우 텍스쳐 크기가 1024x1024를 넘어가더군요..
(글자가 이정도로 커야 한다면,, 여러장의 텍스쳐로 나눠야 할껏같더군요..)

그리고 각 플레이어들의 컴퓨터가 DXT1포멧을 지원하냐가 중요한 문제이기도 합니다.
(이부분은 잘 모르겠더군요. 일단 최신 그래픽 카드들은 전부 지원하더군요.)

어쨌든 단점이 많죠.. 하지만 빠르다는 장점이 있습니다.

만약에 텍스트를 많이 빠른시간내에 뿌려야한다면,, 이런식으로 구성하는것도 한가지 방법이 될수 있을꺼 같더군요..

위에서 말씀하신 글자 하나크기의 텍스쳐를 생성해 놓고,, 실시간으로 텍스쳐 버퍼를 구성하여 뿌리는 방법과,,

제가 제시한 방법을 모두 구현해놓고,, 제목이나 타이틀같은 고품질이 요구되는 폰트는 텍스쳐를 실시간으로 구성하는 방법으로,,

그리고, 시나리오라든지,, 여러 도움말들, 채팅같은것은 제가 제시한 방법으로 하면 좋겠구나,, 라는 생각이 듭니다.


추신) KGDA의 프로그래밍 포럼에 프로그래밍 자료실에서 "폰트"라는 제목으로 검색하면,,
테스트용 프로그램을 올려놨습니다.(아이디가 aser0070입니다.)
그리고 이참에 나도 소스좀 올려보자,, 하고 소스를 찾아봤더니.. 지웠더군요..
다행이 지운건 테스트용 소스만이어서 라이브러리부는 그대로 있습니다.
그부분만이라도 필요하신분은 메일을 보내주시면,, 보내드리겠습니다.

[email protected]
Post Reply