2010년 11월 28일 일요일

프로그래밍과 수학.

http://digestingduck.blogspot.com/2010/02/simple-stupid-convex-hull.html

예전에 엄청나게 고민했던  convex hull 관련 내용이네요.
이게 결과는 간단한데 -- 뭔가 잘 정리가 안되는 내용들이 많았습니다..

게임쪽은 굳이 그래픽스 플머가 아니더라도 어느 정도 수학이 필요한 경우가 많은 거 같습니다.
물론 알면 좋다 식의 경우가 많지요 모르면 찾아보면 되지 뭐 이정도인 경우가 사실 대부분이긴 한 거 같기도 합니다만!!
수학공부 취미로라도 열심히 해야겠습니다. 근데 역시 수학공부는 학교스타일이 좋은 거 같습니다. 교수님께 수업듣고 시험 때 복습하고-ㅅ-.
뭐 정말 플밍을 좋아하는 분들은 학교에 수학 공부할때도 하나하나 플밍해보면서 한다는 소문이-ㅅ-

요즘 개발 환경 구성

요즘 집에서 개발 환경 구성을 어떻게 꾸밀 까 생각중입니다.
일단  당분간은 열심히 구상하고, 어느 정도 정착하게 되면 개인 프로젝트 환경을 꾸며볼까 합니다.
일단 오픈소스 프로젝트를 할 계획이고, 또 오픈소스들을 최대한 활용할 계획입니다.(코드 읽기 연습도 더하고요).

1. 컴퓨터,
    일단 본격적인 개발엔 아직 데스크톱인 거 같습니다. 이사를 많이 다니는 관계로-_- 노트북만 써왔는데 본격적인 개발은 힘든 거 같습니다(현재 집에서는 거의 개발서적만 일고 있습니다.)
   SSD 를 일단 2개 달고, 메모리는 최소 8기가, 나머지는 적당히.라고 생각하고 있습니다.?

2. 빌드 환경
    단연 비쥬얼 스튜디오(집이니까 익스프레스+플랫폼 SDK)일테고(다른 건 사실 써본적도 거의 없습니다. 학교 다닐때 빼고는요-)
    여기에 CruiseControl.net 과 Ant 나 요새 뭐 유행하는 다른  CI 등을(오픈소스 인것들로)로 가볍게 구성할 계획입니다.
   코드 짜기전에 문서화 환경도 어느 정도 구축해야 되니 Doxygen 세팅등도 확인해야겠지요.
   그리고 VCS로는 Mercurial(DVCS) 로 일단!!
   여기에 유닛테스트 구글 유닛 테스트나 CppUnit  이었나요? 이걸로.!
   그리고 스테이티스틱 코드체크는 CPPCheck 등이 있겠네요(http://jooyunghan.da.to/blog/?p=57)
   그리고 디버깅용으로는 Pix 와 Process Monitor, Depend 등이 있겠네요(뭐 당연합니다만 가끔 잊어버리는 경우가 있어서 적어둡니다.;;; 뭐 sysinternal  페이지에 가면 다 있겠지만요)

3. 외부 오픈 소스 라이브러리.(물론 오픈소스가 아니더라도 공짜면, 물론 오픈소스가 아닐 경우에는 사용자 그룹이 있는지가 정말 중요한 거 같습니다.)
     일단 해본 다면 툴쪽을 많이 해보고 싶으니 C# (+MonoProejct) 가 일단 제일 관심이 갑니다.
     그리고 Nocturnal  쪽이 이것저것 잘 들어가 있으니 그냥 쓰면 좋을 거 같습니다.
     따로 따로 구성한다면 gpg 에서 본 미니덤프와 애서트는 기본으로 넣고,
     메모리 얼로케이터는  loki 나 인터넷에서 유명한 걸 가져다 써야 할테고.
     PhysX(+Visual Debugger) 를 주로 써왔으니 이걸 쓸 거 같습니다.(오픈소스인 ODE 를 써보기 싶긴 합니다만, 써본적이 없으니)
    위의 Nocturnal  을 쓴다면 컴포넌트 구성은 따로 할 필요가 없을 거 같습니다만, 따로 하게 되면 gpg 에서 보고 시작해야겠지요. 이쪽은 RTTI 부터 Serialization  까지 있어서 왠만하면 다 되어있는 걸 쓰고 싶군요!!)
   C# 을 쓰면 프로퍼티 그리드 라이브러리도 어디선가 멋진 걸 가져다 써야겠지요.

4. 데이타 !
   간단한 클라이언트 스타일의 DB 를 찾아서 써보고 싶은 생각이 있군요.
   그리고 JSON(Insomniac 에서 뭔가 편리해보는 걸 본거 같습니다.)  이나  FastXML 라이브러리등을 쓸 거 같습니다.
   메모리 맵드 파일 / 구글에서 공개한 크롬 패치 툴도 써보고 싶네요-ㅅ-

사실 만드는 방법이야 다양합니다만 뭘 만들지가 중요하겠지요 열심히 고민해봐야겠습니다.!! 그래도 개인 프로젝트는 제일 잘하는 방법으로 그리고 조금 최신의 경향으로 개발해보겠다는 생각입니다.~_~

lighting! lighting!

http://c0de517e.blogspot.com/2009/12/lighting-compendium-part-1.html

위의 글은 간단히 라이트 방식에 대해( 포워드/디퍼드/라이트 프리패스) 간단하게 설명하고 있습니다.

요즘  MMO 들도 슬슬 디퍼드라이팅을 적용하는 거 같은데요(타뷸라라자가 처음인가요?).

일단 제일 큰 장점은 라이트 갯수보다도 라이트맵을 매번 굽지 않고 테스트해볼 수 있는게 크지 않나 싶습니다. 디자이너가 프로그래처럼 빌드해야 되는 건--안타깝지요.(우리(프로그래머?)도 언제가 빌드 없는 세상이 되면 엄청나게 생산성이 높아지겠지요?).

1. 포워드 렌더링
   => 기본적으로 라이트를 많이 쓴다는 가정하에 => 열심히 baking 해서 쓰게 됩니다.
   => 물론 미리 구워진 녀석이니 다이내믹으로 뭔가 연동하기는 쉽지 않겠지요;;;
   일단 아티스트 분들의생산성이 지형이 클수록 뚝뚝 떨어지니(엄청난 빌드타임으로);
   그리고 덤으로 라이트 문제가 생길때마다 데이타가 제대로 구워졌는지 한번씩 체크해봐야되는 문제가 있지요.
  => 그래도 다이내믹 환경이 필요없고, 편하게 라이트 스태이틱으로 마구 넣어서 적절한 크기의 맵에 쓰기는 좋은 솔루션이 아닌가 싶습니다.
  일단 Beast 같은 미들웨어의 경우 최신 버전에서는 매우 Scalable? 해서, 사용성이 좋아보입니다. 포워드로 수십명의 아티스트와 일할 계획이라면 당연히 써야 되는 거 아니라는 생각이 들 정도입니다.(물론 비싸니, 소규모 프로젝트에서 쓰기는 좀 그런 거 같습니다.)

2. 디퍼드 렌더링.
   => 이런 류의 솔루션은 이상하게 관심이 안가서,  안 보고 있었습니다만, 시대의 흐름을 무시할 수 없어서,(질문도 많이 들어오고-  기존 블로그 참고;;) 공부하고 있습니다.
   => 뭐 장점은 많은 수의 라이트를 다이내믹하게 사용할 수 있다 일테이고,
   => 기타 g-buffer 를 이용해서 포스트 프로세싱시에 이것저것 해볼 수 있는 점도 있겠습니다.;
   => 아직 하드웨어적으로 지원되지 않는( MSAA?) 기능이 있어서, 좀 더 발전할 구석이 있는 거 같습니다.
   => 알파블렌딩 이슈 - 요즘 많은 질문으로 저를 괴롭히고 있습니다.(원래 전 렌더링이 아니라서요-_-;; 이제 흰띠를 메었는데..흐음) 해결방식도 다양해서 어렵네요. 일단은 디퍼드라이팅을 즐하거나, 포워드로 렌더링하거나-ㅁ-

3. 라이트 프리패스/인퍼드 라이팅
   => 뭐 쓰질 않아서 잘 모르겠습니다만, 일단 3 패스로 라이트를 적절히 미리 계산해두거나 하는 거 같습니다.
   => 어차피 디퍼드의 알파블렌딩 이슈등을 처리하기 위해서 등등 디퍼드의 단점은 어떻게든 메꾸어야 되니 비슷한 여러가지 알고리즘이 생기는 거 같습니다.!
  

라이팅하니까 또 다른 문제인 쉐도우쪽도(이쪽은 이제 공부중이라서-ㅁ-)
그래도 이쪽은 카스케이드 쉐도우 맵으로 거의 하고 있는 거 같습니다.

몇몇 분은 그래픽스 쪽은 이론 쪽으론 정립이 끝난다고도 하시는 듯, 전 그런 걸 잘 모르겠습니다만, 하드웨어의 변동에 맞추어서 앞으로도 쭈욱 변화가 지속될듯 하네요. 따라서 엔진 개발은 쉽지 않은 일일 거 같습니다. 그러니 한동안은 이렇게 미들웨어와 엔진에 의존해서 개발해야 되겠지요. 렌더링 엔진도 로직 부분 처럼 점점 컴포넌트+그래프(언리얼의 그래프로 연결 만능-_-) 세상이 되는 거 같습니다.

2010년 11월 26일 금요일

Clean Code 를 읽으며 #2.

Clean Code 를 읽는 내내 드는 머릿속을 떠나지 않는 생각은,
저자분 대답합니다. 얼마나 고민하며 코드를 짰는지 책속에서 제대로 느껴지네요.

코드를 짜는 건 글을 쓰는 것과 같고, 다른 사람의 입장에서 읽어보면서 계속 고쳐야 되는 거라는 비유도 참 맘에 들었습니다.(그러고보면 많은 실력있는 프로그래머 분들이 블로그등에서도 참 글 잘 쓴다는 생각이 든적이 많은 듯도 합니다.^^)

아무튼 저자의 클린 코드에 대한 열정을 보며,
회사에서 10년이나 짜오면서 얼마나 고민하면서 해왔는지 반성하게 됩니다.
(오래 일한게 중요한게 아니라는 생각이 많이 드네요 잠깐을 일해도 바짝 정신차리고 고민하면서 했어야 했는데 말입니다.^^지금 부터라도!!)

조금 더 읽기 쉽게, 우리 프로그래머도 소설가? 라는 생각이 느껴지는 글이네요.
고스트 바둑왕에서 바둑판이 우주라고 말하던 주인공이 생각납니다.
우리에게 우주는 한줄 한줄의 코드겠지요^^

그럼 다 잊기전에 몇가지 코드 지침을 적어봅니다.

1. 함수인자는 최대한 적게 -> 함수를 소리내어 읽어보면 확실히 알 수 있습니다. 인자가 없으면 확실히 읽기 좋다고 하네요.
     덤으로 테스트하기도 편해진다고 하네요.
     사실 인자가 있으면 인자값을 뭘 넣어도 돌아가야 할 거 같아서 이래저래 귀찮긴 한 거 같습니다.

2. 널을 인자로 받거나 리턴하지 말것 -> 널객체 쓰세요(널 체크 없는 코드 만세! 저도 개인적으로 널은 싫습니다만, 널객체 만드는 것도 일이라, 네 널객체 열심히 맏들겠습니다.^^ )

3. 의도가 드러나도록 함수이름 잘 지으셈 -> 영어 공부가 필요한 코드?

4. 클래스는 전체적으로 하나의 일을, 함수는 반드시 하나의 일만(인자가 없거나 하나여야 되는 이유와도 일치한다고 읽은 듯 하네요.)

5. 중복은 죄악(비슷한 스위치문이 함수의 여러군데서 쓰여야 된다면->팩토리 패턴 써야 되는 신호?)
    함수가 하나의 일만 하면 사실 중복 생기게 짜기도 어렵겠지요;;(후우 말은 쉽습니다만 지키려면 늘 머리속에 두고 고민해야되겠네요)

6. 주석은 필요악 - 코드를 보고 바로 아는게 제일 좋음(주석은 시간이 지나면 관리되지 않으니 나중엔 거짓말이 가득한 주석이 되기 쉽다 합니다.)

7. 코드 짜고 나면 독자의 눈으로 한 번 읽어보자. 글 쓰고 퇴고하듯이.(저도 이거 읽고 블로그글도 퇴고 처음으로 해보고 있습니다. 아 제 글이 뭔가 어설퍼보이는 이유중 하나인 거 같네요. 좋은 거 배웁니다.^^ 당연한건가요~)

코드 짜는 것도 어떻게 하면 노가다가 되고, 어떻게 하면 책 쓰는 것처럼 고상하게 되고 그런 게 아닐까 하는 생각이 드는 책이었습니다.

강추!!(이미 다들 보셨을지도^^)

2010년 11월 25일 목요일

XBOX 360 게임 개발

요즘에 어쩌다 보니 Wii / PS3 /XBOX 360 모두 가끔씩 디버깅 할 기회가 있네요.
가끔씩이다 보니 한번 세팅하는 데 제법시간이 걸리긴 합니다만,
최소한 엑박은 재밌네요,(네 나머지는,,음,, 개념이 쪼오끔 다른 듯 합니다.)

개발 환경이 다른 문제도 있습니다만 일반적으로 윈도우라는 운영체제에서 당연하게 생각되던 것들이 가끔씩 안되니 당황스러울 때가 많네요.

오늘은 말로만 듣던 쓰레도 고사를 처음 겪어 봤네요.
시간이 지나도 쓰레드의 우선순위가 올라가지 않나 봅니다.( 낮은 놈은 다른 놈이 바쁘면 영영 ㅃ)
윈도우처럼 그래도 오래 기다리면 차곡차곡 올려주는 거하고 다른 거 같습니다.(제가 아는 한;; )

다양한 환경에서 다양한 디버깅을 해보는 것은 서포트 엔지니어의 특권이 아닌 가 싶습니다.^^

2010년 11월 23일 화요일

[Book] Clean Code

오늘은 Clean Code 를 꺼내 들어서 일고 있는 중입니다.

얼마전에 게임코디 눈팅을 하다가 본 getter/setter
=> 최대한 클래스 내에서 처리하도록 해서 getter/setter 없는 세상을 - 멋진 말인듯 합니다.
=> 사실 엔진 회사에서는 쉽지는 않은 듯(인터페이스를 어떻게 제공해야 할지가 문제.)
=> 무작정 상속받아서 처리하라고 그러기엔-ㅅ-

return null, pass null
=> 사실 이런 저런 악의 근원인데요.  포인터가 없는 언어가 많은 것도 이런 이유이겠지요-ㅁ-
=> 뭐 최대한 안쓰고 널객체를 넣어주면 좋긴 한 듯 합니다.
=> 최근에 널 사운드 시스템을 넣었습니다. 널 렌더러등도 필요한듯 한데요(이건 뭐 일단 제 당담이 아니니; =_=) 크게는 여러 객체들이 널 타입을 갖는 것이 테스트 하기도 좋고 한 거 같습니다. MockObject (이 개념이 맞는지는 정확히 모르겠습니다만) 처럼 행동을 흉내내고 테스트 하는 하나의 요소가 될 수도 있을 거 같습니다.

함수 이름 잘 짓기
=> 일단 영어라는 압박이, 제가 요즘 코드 리뷰시 지적받는 사항이 함수 이름과, 코멘트입니다.
=> 일단 영어는 둘째 치고 뭐하는 지 고민하고 함수 이름 짓는게 중요한 거 같습니다.(생각보다 쉽지 않은 거 같습니다.

리팩토링의 생활화
=> 회사에서 자주 하는 일이 여러 군데 흩어진 비슷한 코드를 모아서 이쁘게 함수를 작성 후 테스트 돌리기(완벽한 유닛 테스트가 없어서 손 테스트도 해야 되긴 합니다만,,=_=) 어느 정도 규모가 되면 전체적인 코드양이 일정하게 유지 되야 하는 거 같습니다.(기존 기능들이 통폐합,,,비슷한 기능들을 묶다 보면---+)

클래스는 한가지일만, 함수도 한가지 일만,
컴포넌트 패턴하고도 잘 맞는 얘기인 거 같습니다.
요즘 대세는 리플렉션(뭔지 정확하게 이해는 안갑니다만,,,) 시리얼라이제이션, RTTI 그리고 멀티코어에 중요한 메시징 시스템 까지 이미 있는 컴포넌트 라이브러리가 많으니 잘 가져다 써야 할 거 같습니다. 결국 C#의 프로퍼티 그리드로까지 깔끔하게 연결;; gpg 책에도 내용이 많고, http://nocturnal.insomniacgames.com/   여기에는 깔끔하게 통짜로 제공하니 함 가져다 쓰면 좋을 거 같습니다.!!!

그리고 요즘 느끼는 건데, 소프트웨어라는게 어디서 만들 던 초반에 버그가 없을 수는 없나봅니다. 뭐든 x.0 버전을 쓰면 고생하네요 -ㅁ- 최소한 좀 기다렸다 작업하는 게 내 코드도 깔끔하게 만들고 마음도 편한 듯 합니다.!!><

2010년 11월 22일 월요일

[Book]Apprenticeship Patterns

That's a great book for me.

I'm reading for second time now.

I know I need to wear white belt for programming now since I need more & different knowledge.

I've been working for 10 year at game company already.
I realized that I didn't study enough. ><

But it's okay. I have a great passion for programming. And I really enjoy it.
And I'm working now in great environment.
I hopefully can wear yellow belt soon.

Now I know that the most important thing is the passion and study & research everyday.!!

2010년 11월 21일 일요일

렌더링 공부 스타일

원래 공부 스타일이 처음부터 쭈욱 하나하나 인데,
렌더링하고는 잘 안 맞는 거 같다.
아니 공부할 양이 방대해지면 효율이 급속도로 저하되는 느낌이다.
(나름의 장점은 있지만.)

생각해보면 GDC 나 GPG 등등을 다 읽어 본다고 도움이 많이 되진 않는 거 같다.

특정한 문제(예, Deferred Rendering 에서 DOF 버퍼 처리?)
뭐 이런 게 있다고 한다면,
위의 관련 자료를 검색해보고,
모르는 게 있으면 타고 들어가고 들어가다 보면
Grpahic Gems 도 몇개 거치고 GDC 논문도 몇개 거치고 하면서 어떻게 구현해야 될지 감을 잡는 거 같다.

그동안 공부를 너무 안했더니, 공부 방법도 계속 변해야 된다는 것을 잊었던 거 같다.!!!

이상 프로그래밍 공부 방법 패턴을 모아놓은 듯한,
프로그래머 멘토에게 묻다를 읽다가 생각난 것이었습니다.~~