첫째, 우선 클래스와 관련된 얘기는 내가 했던 얘기와 분명히 연관이 있다.

사실 난 제로보드 XE의 코드를 본적이 없다. 그 이전의 제로보드5까지는 코드를 어느정도 구경해봤던 기억이 있는데, 그 날 내가 했던 얘기는 XE가 아닌 제로보드5의 코드에 대한 얘기였다. (사실 난 제로보드 XE가 제로보드5에서 이름이 바뀐 정도로 알고 있었다. 뭐 어쨌든!) 당시 제로보드5의 클래스는 다음과 같았다.

1. DB클래스
2. DB클래스를 상속한 ZeroBoard 클래스
3. 이를 상속한 또 하나의 클래스?

오래된 일이라 정확하게 기억나진 않고, 코드를 찾을 수가 없어서 더 자세하게는 얘기를 못하겠다. 어쨌거나 하고 싶은 얘기는 클래스의 사용이 나쁘다는 것이 아니라 필요없이 클래스를 상속하고, 쓸모없는 클래스들을 정의하고 있었다는 것이다.

클래스는 재사용을 위해 사용하는 것이다. 괜히 귀찮게 인터페이스를 만들고 내부 변수에 접근 못하도록 private, friend 같은 키워드를 걸어두는 게 아니란거다. ^[1]

당시 제로보드에 사용되어진 클래스들은 재사용 등의 관점하고는 거리가 멀었다. 클래스를 사용하고는 있지만 실제 뭔가를 하려면 클래스를 사용하지 않을때와 별반 다르지 않은 코드를 작성해야하는 상황. 디비 클래스 정도만이 재사용이 가능한 정도였다고 기억한다. (다행히 XE의 코드는 그 때 코드와는 아주 달라보인다.)

뭐 어쨌거나 그 날 오프모임에서 내부 구현이 지저분하다라기보다 당시 제로보드의 클래스는 저랬다. 그 이후로는 안봐서 모르겠다란 얘기를 했었다. 지금와서 생각해보면 최근까지 제로보드를 지켜보고 있었던 것도 아니면서 경솔하게 얘기했었던 걸지도 모르겠다.

그리고 이건 지금도 적용되는 이야기!

그날 제로보드에 대해 비판했던 내용 중 패치 배포 방법에 대한 내용이 있었다. unix에는 diff, patch란 툴이 있다. ^[2] 이 툴들을 이용할 경우 코드의 패치를 배포하려 할 경우 패치가 완료된 파일을 배포하는 것이 아니라 수정된 사항만을 배포할 수 있다. 이 툴들은 매우 똑똑하기 때문에 사용자가 다른 부분을 수정하였더라도 내가 수정을 한 부분과 상관이 없으면 아무 문제 없이 이 변경 사항들을 적용시켜준다. 그렇기 때문에 만약 사용자들이 여기저기 수정을 해서 사용하는 시스템이라면 당연히 이런 툴들을 사용한 패치를 제공해야한다고 생각한다.

unix툴이라고 하니까 다 뭔가 대게 복잡할거 같다고 생각하지만 windiff, filemerge 등의 윈도우 GUI프로그램도 존재하고, 그 중에는 공개 소프트웨어도 있다. 사용하는데 그리 어렵지 않다는 얘기다. SVN 등의 버젼 관리 시스템을 이용한다면 이런 툴들의 존재를 모르진 않을텐데, ‘패치 방법: 어떤 파일을 덮어쓰시면 됩니다.’ 이런 공지가 아직까지 보이는 걸 보면 여전히 답답하다.

사실 문제가 되었던 글을 읽으면 그 때 뭔가 얘기가 많이 오간 듯한 분위기지만 사실 5분 내외의 아주 짤막한 내용이 전부였던 것 같은데, 하여튼 오프라인에서 술먹으면서 하는 얘기라도 말은 조금 조심해야겠다.

덧: 혹시나 관련 글들을 보고 기분이 상하셨던 분들이 계시다면 사과드리겠습니다. (_ _*) 꾸벅;

1. 다른 클래스를 가져다 쓰고 있는데, 다른 클래스의 내부 구현이 변경되었다고 내 프로그램까지 문제가 생기면 안된다. 최악의 경우라도 새로 컴파일, 링크 하는 것 만으로 적용이 가능해야 한다.

   그런 이유로 내부 변수에 직접 접근하도록 하는 것은 좋은 생각이 아니다. 내부에 있는 a라는 변수에 접근하도록 허용하기 보다는 getA(), setA(int var) 식의 인터페이스(자바에서는 ‘메쏘드’라는 이름을 사용한다.)를 제공하고, 내부 변수에는 접근할 수 없도록 private 등의 키워드를 걸어버리는 것이 좋다. 이 개념이 바로 인캡슐레이션이라 불리는 개념이다.

   c의 변수에는 생성자(initializer)와 소멸자(destructor) 등이 없기 때문에 c style로 파일 단위 모듈화를 진행하게 되면 실제 그 모듈을 가져다 쓸 때 init_my_module() 같은 생성자를 호출하고, 그 모듈과 관련해서 더 이상 뭔가를 할 게 없으면 destruct_my_module() 같은 코드를 호출해줘야한다. 하지만 c++ 에서는 new 키워드를 통해 클래스를 만들게 되면 생성자가 호출되고 delete 키워드를 사용해서 클래스를 파괴해버리면 소멸자가 자동으로 호출된다. 그렇기 때문에 클래스를 가져다 쓸때는 복잡하게 해줄 일이 없다. 그저 header를 include하고, new 로 클래스를 초기화 시켜주는게 전부. c 로 짜여진 모듈을 가져다 사용할 때처럼 클래스를 사용해야한다면 이는 분명 잘못 설계된(남용된) 클래스다.

   물론 인터페이스를 통해서만 접근하는 것은 내부 변수에 직접 접근할 때보다 느리다. 또한 생성자 소멸자, 그리고 함수 오버라이딩, 오버로딩 등을 지원하기 위해 성능을 희생해야할 지도 모른다. 하지만 코드의 재사용이라는 관점에서 클래스를 사용하는 것은 플러스 알파를 가져온다.

2. 대강 어떤 식인지는 요 글을 보라!

   http://mytears.org/resources/tmp/zb_patch/

   위 url에 가보면 내 서버를 사용하고 있는 분들의 제로보드를 강제로 최신 버젼으로 올리기 위해 만들어놨던 제로보드 패치들을 볼 수 있다. 하여튼 diff를 이용하면 위와 같은 출력물이 나오고 patch 를 이용하면 구버젼의 제로보드에 패치와 관련된 코드를 아주 간단히 삽입할 수 있다.

Related Posts

• 3/9/2009 -- NDSL의 재발견! (7)
• 2/8/2009 -- WP-Eolin 플러그인 (3)
• 2/8/2009 -- Daum 블로거 뉴스를 위한 Trackback for Korean 패치 (0)
• 2/2/2009 -- 워드프레스 2.7을 위한 Trackback for Korean 패치 (6)
• 1/29/2009 -- wp-codebox, wp-openid 버그 패치 (4)

METHOD URI VERSION

많은 옵션이 붙을 수 있지만 이정도가 페이지를 요청하기 위한 기본 쿼리라고 생각하시면 됩니다. METHOD는 ‘GET’, ‘POST’, ‘HEAD’, ‘OPTION’ 정도가 될 수 있겠고, URI는 PATH + QUERY STRING이라고 생각하시면 되겠습니다.

자 그럼 이걸 응용해 봅시다.

GET /index.php HTTP/1.1

위 코드는 /index.php 페이지를 HTTP/1.1 프로토콜을 사용해서 호출하겠다는 얘기입니다. 여기에 값을 넘겨주려면 QUERY STRING을 사용하면 됩니다.

아래와 같이 var1이란 변수에 1234, var2란 변수에 2345란 값을 담아서 페이지를 호출해봅시다.

GET /index.php?var1=1234&var2=2345 HTTP/1.1

간단하죠. 단 URI의 길이에는 제약이 있기 때문에 이런 방식을 사용할 경우 긴 데이터를 넘겨줄 순 없습니다.

긴 데이터를 넘겨줄 때는 POST를 사용하게 되는데요. POST를 사용해서 값을 넘겨줄 때는 아래와 같은 코드를 사용하게 됩니다.

POST /index.php HTTP/1.1 Content-type: application/x-www-form-urlencoded Content-length: 19 var1=1234&var2=2345

Content-length는 넘겨줄 값의 길이를 의미합니다. 간단하죠. 뭐하튼 값을 넘겨주는 데는 GET과 POST 방식을 사용할 수 있고, GET 방식에서는 값을 URI에 붙여서 보내준다는 얘기를 하고 싶었습니다.

그런데 브라우져마다 GET 방식으로 값을 넘겨줄 때 사용하는 인코딩이 동일하지가 않네요. 예전에 ‘웹 서비스와 UTF-8‘이란 글에 적어놨듯이 RFC2718에서는 URI를 UTF-8로 인코딩할 것을 권고하고 있습니다.

그렇다면

1. euc-kr로 인코딩된 페이지에서 다른 페이지로 값을 GET 방식을 사용해서 넘겨준다면 어떤 인코딩을 사용해야할까요?
2. utf-8로 인코딩된 페이지에서 다른 페이지로 값을 GET 방식을 사용해서 넘겨준다면 어떤 인코딩을 사용해야할까요?
3. 만약 url에 직접 query string을 붙여서 페이지를 요청할 경우에는 어떤 인코딩을 사용해야할까요?

URL을 정의하고 있는 RFC2396에서는 URI를 PATH+QUERY 로 정의하고 있고, 이를 확장한 RFC2718에서 URI를 UTF-8로 인코딩하자고 했으니 위의 모든 경우에서 URI는 utf-8로 인코딩되어야 맞습니다. (단 1번의 경우에는 %인코딩을 사용해서 값을 Escape시켜줘야겠죠.)

하지만 재앙의 근원 Internet explorer에서는 3번과 같은 상황일 때 query string을 로컬 인코딩으로 인코딩해버립니다. ^[1] ajax를 사용할 때 생기는 문제에 비교하면 이 정도는 애교입니다.

1. utf-8 페이지에서 ajax + get으로 값을 전송합니다. 어떤 인코딩으로 값이 전송될까요?
2. euc-kr 페이지에서 ajax + get으로 값을 전송합니다. 어떤 인코딩으로 값이 전송될까요?
3. utf-8 페이지에서 ajax + post로 값을 전송합니다. 어떤 인코딩으로 값이 전송될까요?
4. euc-kr 페이지에서 ajax + post로 값을 전송합니다. 어떤 인코딩으로 값이 전송될까요?

3, 4번의 경우 Internet explorer를 쓰건 safari, firefox등을 쓰건 모두 utf-8로 값이 전송됩니다. (이유는 묻지 마세요. 안찾아봤습니다.) 2번의 경우는 모든 경우에 euc-kr로 값이 전송되구요.

하지만 1번의 경우 분명 utf-8로 값이 전송되어야 할 것 같지만 Internet explorer는 euc-kr로 값을 전송합니다. 상식적으로도 이해가 가질 않지만 그렇게 동작하고 있습니다.

덕분에 utf-8로 값이 넘어왔다고 가정한 프로그램은 오동작을 하게 될 수 밖에 없습니다. 전 정말 Internet explorer를 이해할 수가 없습니다.

상식이 통하는 세상에 살고 싶습니다. Internet explorer 노력하세요.

1. lastmind님이 포스팅하신 ‘On encoding uri with nonascii characters‘에 따르면 Internet explorer에서는 PATH는 utf-8로 (혹은 %인코딩으로) 인코딩하지만 Query string에 대해서는 시스템의 local encoding, 즉 한글 윈도우라면 euc-kr을 사용한다고 하네요.

   그렇다면 영문판 윈도우에서는 어떤 결과가 나올지 궁금하네요.

Related Posts

• 3/16/2009 -- 인터넷 뱅킹과 SSL… 변명은 이제 그만… (2)
• 9/5/2008 -- 매력적인 Internet Explorer 8 Beta2 의 개발툴 (1)
• 10/25/2007 -- 오픈웹과 관련해서… (4)
• 9/4/2006 -- wordpress: korean trackback! (22)
• 1/25/2005 -- 컴퓨터 속의 한글 (22)

어떻게 보면 ARM 입문용으로 이만큼 좋은 키트가 없다고 생각합니다. 조이패드, 터치패드, 두 개의 LCD 뿐만 아니라 Wi-fi까지 포함되어 있으면서 10만원 중반대로 낮은 가격대를 형성하고 있으니까요. 그 뿐만이 아닙니다. OpenGL까지 사용이 가능하기 때문에 그래픽 API를 새로 공부할 필요도 없어요.

부가적으로(?) 게임 기능까지 있으니 더 말할 필요가 없겠죠.

사용가능한 메모리가 4메가로 제약되어 있다는 점은 조금 아쉽지만 union질 좀 해주면 어떻게 되겠죠. 후훗!

목표는 SNES9x 포팅인데, 유닉스용은 메모리가 16메가 이상이 필요하다고 나와있는 걸 보고 조금 좌절 중입니다. 화면 크기가 256*192 라서 SNES9x의 저해상도 모드보다 세로로 30픽셀정도 작은 문제도 있는데, openGL을 지원한다고 하니 텍스쳐를 사용해서 리사이즈 되도록 하면 될 것 같아요.

GUI와 코드가 완전히 분리되어 있기 때문에 포팅에 크게 손이 가진 않을 것 같더군요.

만약 다음 학기에 강의를 맡게 되면 이런 걸로 수업을 개설해보면 어떨까 싶어요. 뭐 NDSL이 없더라도 에뮬레이터들이 잘 나와있고, devkitpro를 비쥬얼 스튜디오와 연동시킬 수도 있으니 학생들이 접근하는 데도 어렵지 않을 것 같고…

저도 학부 때 들었던 수업 중에 openGL로 게임을 만들게 시켰던 과목이 제일 기억에 많이 남더라구요. -_-a

사실 Embedded 개발이라고 해봐야 tftp 나 nfs 를 사용해서 파일을 옮기고 결과를 serial terminal로 확인해야 한다는 점을 제외하면 윈도우에서 개발을 할 때와 크게 차이가 없자나요. 어떻게 보면 이것도 임베디드 실습이라고도 생각해볼 수 있겠네요. tftp, nfs 대신 micro sd를 사용하고, 시리얼 터미널 대신 문쉘을!!

덧: NDSi 나오면 그것도 하나 질러줄까봐요. -_-! 카메라까지 달려있으면 가지고 놀기 정말 좋아질 거 같은데…

Related Posts

• 4/9/2009 -- 제로보드 XE 관련 약간의 해명… (1)
• 6/23/2008 -- 지뢰찾기 프로그램 (0)
• 4/4/2010 -- 지멋대로의 영어를 더 자주 볼 수 있었음 좋겠습니다. (5)
• 12/15/2009 -- MySQL의 라이센스 모델이 가지는 의미는? MySQL은 결국 죽임을 당할 것인가? (0)
• 8/25/2009 -- 사라져가는 오픈소스 커뮤니티? (7)

바로 Visual Studio 를 실행시키고 -_-; 한 두 시간 정도 뚝딱뚝딱 거린 끝에 결국 콘솔용 지뢰찾기를 완성하기에 이르렀습니다. GUI 버젼으로도 만들어볼까 하는 생각이 있어서 게임 코어와 인터렉션 부분을 분리시켜 놓기는 했는데 구차니즘 말기인 요새 상황으로 볼때 GUI 버젼이 정말 나올까 하는 걱정이 조금 –;;

코드는 아래 url 로 가시면 볼 수 있고, Visual Studio 와 gcc (linux/Windows) 에서 정상적으로 컴파일되는 것을 확인했습니다. :) standard c function 을 제외하곤 별 다르게 사용한 게 없어서 아마 다른 플랫폼에서도 잘 실행될거라 생각합니다.

http://trac.unfix.net/browser/snippet/console_mine

p.s) 콘솔에 찍기에는 9×9 사이즈 이상은 너무나도 커져버려서 사이즈를 고정해놨는데 gui 로 옮기게 되면 저 부분에 관련해서 좀 업데이트를 해야겠네요.

Related Posts

• 4/9/2009 -- 제로보드 XE 관련 약간의 해명… (1)
• 3/9/2009 -- NDSL의 재발견! (7)
• 8/2/2008 -- YUVPlayer 업데이트… (0)
• 7/15/2007 -- 소스 공개: yuvplayer (4)
• 6/9/2007 -- YUVplayer for MS Windows (6)

function stripslashes_deep($var){
    $var = is_array($var)?
                  array_map('stripslashes_deep', $var) :
                  stripslashes($var);
 
    return $var;
}
 
function mysql_real_escape_string_deep($var){
    $var = is_array($var)?
                  array_map('mysql_real_escape_string_deep', $var) :
                  mysql_real_escape_string($var);
 
    return $var;
}
 
if( get_magic_quotes_gpc() ){
    if( is_array($_POST) )
        $_POST = array_map( 'stripslashes_deep', $_POST );
    if( is_array($_GET) )
        $_GET = array_map( 'stripslashes_deep', $_GET );
}
 
if( is_array($_POST) )
    $_POST = array_map( 'mysql_real_escape_string_deep', $_POST );
if( is_array($_GET) )
    $_GET = array_map( 'mysql_real_escape_string_deep', $_GET);

common function 들을 정의해놓은 파일 맨 아래 저 코드를 삽입해버리니 sql injection 따위 이제 두려워할 필요가 없어졌다. 움하하핫!!

p.s) 그냥 array_map 에 stripslashes 나 mysql_real_escape_string 을 사용하게 되면 array 가 넘어온 경우 문제가 생길 수 있어서 약간 수정을 했습니다.

Related Posts

• 11/15/2005 -- 나는 제로보드가 싫어요!! (5)
• 1/28/2009 -- 번역: 한국의 홈브류 인터넷 (0)
• 1/28/2009 -- 인터넷 뱅킹과 크로스 브라우징 (2)
• 1/23/2009 -- Punbb update (0)
• 1/31/2008 -- problem in fastcgi with apache (2)

지난 며칠간 꽤나 재밌게 프로그래밍을 했던 관계로 블로그에도 살짝 정리해보는게 어떨까 하는 생각이 들었는데, 막상 쓸려니 내용이 잘 전해질지 의문이네요.

What is the Perspective Projection?

Perspective Projection 이란 아래의 왼쪽 이미지를 오른쪽 이미지 처럼 변화시키는 것을 얘기합니다. 꼭 저렇게 비뚜러진 이미지를 바로잡는것은 아니고, 이미지가 투영되는 면을 변화시키는 것이라고 생각하시면 됩니다.

이해를 돕기 위해 wikipedia 에서 이미지를 하나 가져왔습니다. 아래 이미지의 연보라색 면이 상이 맺히는 곳이라고 할 때, perspective transform 은 그 보라색 면을 이동시킨 것 같은 효과를 주기 위해 사용합니다.

How to get a projection matrix.

기본 적으로 Perspective Transform 을 위한 식은 다음과 같습니다.

homogenious coordinate 를 사용하고 있으니 x’ 와 y’ 에 관한 식은 아래와 같이 바꿔쓸 수 있습니다.

이를 정리하면 다음과 같은 꼴로 만들 수 있고,

우리가 값을 알고 싶은 변수들은 a, b, c, d, e, f, g, h 이렇게 8 개이므로, (x, y) 와 그에 대응되는 (x’, y’) 쌍을 4개만 알고 있으면 projection matrix 를 구할 수 있습니다. 이를 구하기 위한 매트릭스는 아래와 같습니다.

남은 건 8×8 matrix 의 inverse matrix 를 구한 뒤 뒤 쪽의 매트릭스에 곱해주는 것 뿐이군요.

Implementation of Perspective projection

이제까지 Perspective Transform 을 위한 매트릭스에 대해 알아봤습니다. 이제는 실제 구현을 해보는 것만 남았네요. 위에서 알아봤듯이 Perspective matrix 를 구하려면 matrix multiplication 과 inverse 를 위한 인터페이스가 필요합니다.

matrix multiplication 의 경우 서로 곱할 수 있는 형식인지를 체크한 뒤 단순한 계산을 하면 되고, inverse 는 gauss elimination 을 이용 reduced row echelon form 으로 만들어주는 것을 통해 쉽게(?) 구해낼 수 있습니다.

위의 두 가지까지 구현했다면, 이제 warping 만을 구현하면 되겠습니다. 이 warping 은 크게 두가지 방법을 통해 구현할 수 있습니다.

forward mapping

forward mapping 은 말 그대로 src 의 x, y 좌표에 대하 dst 의 x’, y’ 를 계산 한 뒤 값을 채워주는 방식입니다. 간단히 pseudo code 로 표현하면 다음과 같이 표현할 수 있겠네요.

for( y = 0 ; y < height ; y++ ){
    for( x = 0 ; x < width ; x++ ){
        x' = (ax+by+c) / (gx+hy+1);
        y' = (dx+ey+f) / (gx+hy+1);
 
        dst[y'][x'] = src[y][x];
    }
}

근데 막상 구현을 해놓고 보면 pixel 이 정수단위이기 때문에 아래와 같이 hole 이 발생하는 것을 확인할 수 있습니다.

backward mapping

위에서 얘기한 hole 을 방지하기 위한 방법 중 하나로 backward warping 이란 것이 있습니다. forward warping 에서 src 의 좌표를 기준으로 dst 의 좌표를 계산했다면, backward warping 에서는 dst 의 좌표를 기준으로 src 의 좌표를 계산하게 됩니다.

간단하게 pseudo code 로 표현하면 아래와 같이 되겠습니다.

for( y' = 0 ; y' < height ; y'++ ){
    for( x' = 0 ; x' < width ; x'++ ){
        x = (ax'+by'+c) / (gx'+hy'+1);
        y = (dx'+ey'+f) / (gx'+hy'+1);
 
        dst[y'][x'] = src[y][x];
    }
}

간단히 코드만 봐도 예상할 수 있겠지만 backward_warping 을 해주게 되면 hole 은 확실하게 없앨 수 있습니다. 결과 이미지는 아래와 같은데, 아주 깔끔한 결과가 나오지는 않았습니다.

forward (or backward) warping with interpolation

forward warping 을 하게 되면 hole 이 생기게 되고, 단순한 backward warping 을 하게 되면 이미지의 화질 저하가 발생하게 되는데, interpolation 을 사용하게 되면 이를 조금 더 개선할 수 있습니다.

전 linear-interpolation 을 사용해보았는데, 설명하기는 복잡하니 관심있으신 분은 저 아래 첨부할 소스를 참고해보시면 좋겠습니다. 결과는 아래와 같이 나옵니다.

우선 interpolation 을 이용한 forward warping 입니다. 복잡하게 하기는 귀찮고 해서 대강 구현했더니, hole 이 줄기는 했지만 여전히 존재하고 있습니다.

다음은 backward warping 에 linear interpolation 을 적용한 결과입니다. hole 도 없고, 보기에 상당히 괜찮아진 것을 확인할 수 있습니다.

소스코드:

http://trac.unfix.net/bro...snippet/image_projection/

참고자료:

http://en.wikipedia.org/w...rspective_%28graphical%29

http://en.wikipedia.org/wiki/Gaussian_elimination

p.s) 부동 소숫점 연산에서 x – x/x*x = 0 이라는 것이 보장되질 않더군요. 코드 한 줄 줄일려다가 디버깅을 30분동안 해야했습니다. -_ㅜ

Related Posts

• 10/16/2007 -- CG: 3D Image Rotation (2)
• 1/24/2009 -- Cairo test… (0)
• 11/21/2008 -- CG: dithering (2)
• 11/13/2007 -- CG: auto stitch (1)
• 10/29/2007 -- CG: gaussian blur (0)

1. glBegin(GL_POINTS); glColor3i(…);glVertex3d(x0,y0,0); …반복; glEnd();
2. texture 로 올려주고, 해당 texture 가 입혀진 quad 을 그려줌
3. glDrawPixels 를 이용

첫번째 방법이야 그냥 저렇게도 가능하다는거지 실제 저렇게 사용할 일은 없다고 생각되고, 실제 빠르게 화면에 2D 이미지를 그려주기 위해서는 2번째 방법이나 3번째 방법을 사용해야할텐데, 저 중에 어떤 걸 사용하는게 더 좋은 방법인지 확신이 들질 않는다.

우선 화면이 확대되었을 때 texture 를 사용할 경우 GL_LINEAR 등의 기본으로 제공되는 interpolation method 들이 있기 때문에 (약간 Blur 된 결과일지는 모르지만) 더 좋은 품질의 이미지를 얻을 수 있겠고, 화면이 다시 그려질 일이 있을 때 texture 데이타가 다시 전송될 필요가 없다는 장점이 있는 듯 싶지만, (texture 로 등록할 때 이미지 데이타는 비디오 메모리로 옮겨진다.) width 나 height 가 2^x 형태로 표현되어야 한다는 제약이 있다. 이게 만약 이미지가 크지 않다면 큰 문제가 되지 않겠지만 만약 HD Sequence 라면? 1920×1080 을 표현하기 위해 2048×2048 = 4MB 를 사용해야 하므로 반 정도의 공간이 낭비될 수밖에 없다.

glDrawPixels 는 다시 화면을 그려줘야할 때마다 이미지 데이타를 메인메모리->비디오메모리 로 복사해줘야 하는 문제가 있지만 만약 동영상 플레이어등을 만들 때 처럼 빠르게 화면이 전환되는 경우라면 이는 큰 문제가 되지 않을 듯 싶기는 하다. 물론 화면이 멈춰있는 상태라면 얘기가 다를 지 모르겠다. 또 이미지를 실제 크기보다 더 크게 표현할 경우 glPixelZoom 을 이용해 간단히 구현할 수 있지만 실제로는 픽셀 크기만 커지는 효과이지 interpolation 은 일어나지 않으므로 화질은 texture 를 사용할 때에 비해 떨어진다고 할 수 있을 듯…

뭐 하튼 뭘 사용하는게 더 좋은건지 인터넷을 열심히 찾아봤지만 뭐가 더 좋은지에 대한 정확한 답은 찾을 수가 없다. -_-!

p.s) yuv2rgb 변환 같은 것은 cg 를 이용해서 처리할 수 있는 것 같은데… 이 경우 texture 를 사용해야지만 가능 한 듯…

openGL 에 이미 4×4 matrix multiplication 은 구현되어 있으므로 color_matrix 를 사용해서 yuv2rgb 변환을 빨리할 수 있지 않을까 하는 생각도 해봤지만 실제 결과는 참담…

Related Posts

• 8/2/2008 -- YUVPlayer 업데이트… (0)
• 6/4/2007 -- 내 첫 cocoa application: yuv player (5)
• 10/24/2007 -- sql injection 을 피하기위한 간단한 방법… (2)
• 10/16/2007 -- CG: 3D Image Rotation (2)
• 10/14/2007 -- CG: Perspective Projection (6)

랩에 이미 충분히 쓸만한 yuvplayer 가 있기는 하지만 윈도우 전용이고, 내가 예전 신입생 과제를 하면서 만들었던 플레이어 역시 윈도우용;; 뭐 하튼 플레이어를 구현하는데 필요한 기반 테크닉은 다 갖추고 있었기 때문에 MFC + OpenGL 로 구현해봤던 것을 똑같이 Cocoa+OpenGL 로 구현해봤다.

메뉴를 이용해서 size 와 color format, frame rate 등을 준비할 수 있도록 만들었는데, size 와 frame rate 를 사용자가 직접 입력하는 것은 귀찮은 관계로 나중에 -_-;;

뭐 하튼 Zoom 하고 Drag And Drop 과 관련된 코드만 추가하고 나면 내가 구현하고 싶었던 모든 기능이 다 들어가는 거 같다. (Zoom 이야 glPixelZoom 을 사용하면 한방에 오케이니 흐흣)

XCode + Interface Builder 를 이용한 첫 결과물인데, 굉장히 오래전에 이미 나와있던 프로그래밍 인터페이스인데도 불구하고 굉장히 편리하게 프로그래밍이 가능해서 감탄을 해버렸다. 물론 MS 진영도 Visual Studio 2005 로 오면서 편리한 기능들이 꽤 많이 추가되긴 했지만, GUI Application 을 만들기 위한 IDE 로는 XCode + 인터페이스 빌더 쪽이 한 수 위인 듯…

MFC 나 Cocoa 나 진입 장벽이 꽤 높지만… 기본적인 테크닉을 익히고 나면 굉장히 강력하게 사용이 가능한 것 같다. 그리고 C 에 능숙하다면 다른 언어를 접하는 데도 그리 큰 어려움을 느끼지 않는 것 같다. 학부 시절 C++, Java 등에 눈길을 뺐기지 않고 주력 언어로 C 를 선택했던 게 탁월한 선택이었던 듯…

p.s) 코드를 좀 정리하고 sourceforge 등에 자리를 틀어볼까 싶네요. :)

Related Posts

• 8/2/2008 -- YUVPlayer 업데이트… (0)
• 6/9/2007 -- YUVplayer for MS Windows (6)
• 7/15/2007 -- 소스 공개: yuvplayer (4)
• 6/4/2007 -- OpenGL: texture vs glDrawPixels (2)
• 4/9/2009 -- 제로보드 XE 관련 약간의 해명… (1)

histogram 을 보면, 값들이 낮은 값들로 집중되어 있는걸 확인할 수 있습니다. 역시 이미지 압축을 위해 사용할만 하네요. ;)

Related Posts

• 10/24/2007 -- sql injection 을 피하기위한 간단한 방법… (2)
• 10/16/2007 -- CG: 3D Image Rotation (2)
• 10/14/2007 -- CG: Perspective Projection (6)
• 6/4/2007 -- OpenGL: texture vs glDrawPixels (2)
• 6/4/2007 -- 내 첫 cocoa application: yuv player (5)