2013년 1월 17일 목요일
[또자랑] 제 셰이더 서적에 대한 너무나 좋은 평
제 블로그의 셰이더 입문강좌 페이지에 실린 댓글입니다. 이 댓글 받고 나서... '아, 책 쓴 보람이 있구나.' 생각이 들어.. 또 제자랑겸 여기다도 올립니다. 이런 기회를 제가 놓칠리가 없죠 -_-;
----------------------------------------------------------------------------------------
정헌 2013년 1월 14일 오후 11:00
안녕하세요~ 다시 와보니 바로 윗글에 글 남긴 사람이네요 ㅎㅎㅎ
Appendix A 까지 다 보고 코드로 적용해본다음 후기 올리려 왔답니다
지금으로부터 한.. 7일 전, 처음 이 책을 서점에서 목차를 봤던 기억이 나네요 ㅎㅎ
처음엔 그냥 셰이더 책 또 하나 나왔구나 라고 생각을 하고 지나쳤더랬죠
그런데 저 개인적으로 프로젝트를 진행하던 중이였습니다, 그동안 수학,물리를 공부해서
실질적으로 뭔가 보려고 했지만, 막상 시간이 지나다보니 셰이더를 넣어야겠다는 생각에
봉착하게 됐습니다, 그런데 2,3년 전 셰이더를 본적이 있긴 하지만 다시 시작해볼려고
하니깐 막상 주변엔 셰이더 관련 책이 있긴 하지만 셰이더 책들 분량이 대부분 많아
다시 보기에도 귀차니즘이 승리할 것 같아 그냥 필요한 부분만 보면서 넘어가자라는 식으로 하려고 했으나 원래 성격이 그렇지 못한지라 결국 다른 방법이 없을까 생각을 했죠
생각을 하던중 셰이더 프로그래밍 입문 책의 목차가 머리속에 사~~악 지나가더군요,
그때 드는 생각이 그래! 이거다! 라는 생각이 들어 바로 서점으로 튀어가서
한권 구입했더랬죠 ㅎㅎ
처음엔 챕터8 정도까지만 본 다음 다시 본래 프로젝트로 돌아가려 했지만
8 장을 vs로 코딩하던 중 드는 생각이
"어.. 이 책 뭔가 다르다" 는 생각이 들게 되더군요
처음 해본다면 오랜 시간 투자해야되는 여러가지 DX 설정들과 셰이더와의 상호
상태와 값과 그 의미들이 간단 명료하고 잘 연결 되어있다는 느낌을 받게 되더군요
결국 한챕터 더 보까? 더보까? 더 보까? 하다가 끝까지 보게 됐습니다
인터넷 뒤져가며 두꺼운 셰이더 책 뒤져가며 찾아 설정해야 되는 것들에 대한 시간
절약과 셰이더 소스코드들의 간략하면서도 이해가 잘가는 설명은
처음 앞뒤 뭐 대락 소개나 이런 저런것 빼면 2백 50~60 페이지 정도 되는 분량이
좀 적은거 아닌가? 조금 비싼거 아닌가? 라는 생각을 완전히 뒤바꿔 주더군요
기본적인 탄탄한 노하우가 담겨져 있는 책이라는 느낌이 들었습니다
게임관련 많은책을 보긴했지만 이렇게 직접 사이트에 찾아와 후기를 남기는건 처음이네요
또 질문 하나 하고싶어서 글을 남기기도 한건데요
Q:
대부분 프로그래머는 자신이 익힌 것을 잘 공개하려는 마인드를 갖고 있진 않다고
생각 하곤 합니다, 그런데..
사이트에 보면 이 책의 일부 챕터가 올라와있는것도 볼 수 있고 책 또한 기본적인
내용들을 담았다곤 했다고 하셨지만 노하우가 많이 묻어나온 책이라는걸 느낄 수가
있었습니다, 책을 보면서 이렇게 까지 이 한권의 책으로 도움을 받아도 되나
라는 생각을 하게 되었는데요, 왜 이리 적지 않은 부분을 공개한것인지 궁금하네요 ㅎㅎ
p.s 렌더몽키를 소스코드로 옮기는 과정은 감탄이 나오더군요 ㅎㅎ
스승으로 모셔도 될까요?? ㅎㅎㅎㅎ
2013년 1월 10일 목요일
Subversion에서 Private Depot 사용하기(Mercurial을 이용)
Private Depot 얼마나 오랫동안 꿈꾸어 오던 것인지... -_-;
SVN과 같이 중앙 public depot을 사용하면 잘못된 코드를 체크인 했을때 그 때문에 피해를 입는 사람이 많다. 고로 제대로 작동안하는 코드를 집어넣으면 졸 욕을 쳐먹는다 -_-;
그래서 보통 코드가 제대로 돈다고 확인할때까지, 또는 코드를 보기 좋게 잘 다듬을 때까지 check-in을 안하곤 한다..... 이것의 문제는 한 1주일정도 체크인 없이 로컬 컴퓨터에서 계속 작업하는 경우가 있는데.. 그러다가 어느순간...
'아... 3일전에 만들어놨다가 제대로 안돌아서 지워버린 코드를 다시 쓰고 싶은데...'
라는 후회가 드는 경우가 있다는 것.... 이걸 미리 체크인 해놓았다면 단순히 버전 되돌리는 걸로 끝날 일... 중앙 depot시스템 때문에 못한거지... 퉤... - _-;
그래서 git이나 mercurial(hg)등의 DVCS (Distributed Version Control System)이 나름 각광을 받고 있었다. 하지만 게임개발을 하는 나에게 중앙서버가 없는 중구난방식의 분산 방식은 좀 별로였다. 내가 원한 것은 완전한 분산방식이 아니라.... 개인(private) depot에는 아무때나 내 맘대로 체크인 해놓고..... 나중에 준비가 되면 여태까지 해왔던 일들을 한번에 중앙 서버에 집어넣는 거였다. 한마디로 매일밤
"오늘까지 한 일. 어쩌구 저쩌구... 현재 컴파일은 안됨 ㅋㅋ"
이라는 commit log를 작성하고 싶었다고나 할까....
Perforce에서는 perforce sandbox를 사용하여 이 문제를 해결했었다. 하지만 Subversion을 사용할 때는 마땅히 어떻게 할 방법이 없었다. git-svn이라던가 hg-svn 등의 놈들이 있지만 이렇게 그다지 믿음이 가지 않았다. 난 모든간에 단순하고 간단한걸 좋아해서 이렇게 두가지 기능을 대충 합치는 프로그램을 안좋아한다. 사용하다가 말도 안되는 곳에 문제가 생겨서 골치만 아픈 경우가 너무 많거든...
하드디스크에 체크아웃 해둔 SVN 루트 디렉토리에 git이나 mercurial을 local depot를 만드는 법도 한 때 생각해봤으나.. 각 폴더마다 들어가 있던 .svn 폴더때문에 그것도 쉽지 않았다... 그래서 한동안 손을 들고 있었으나... 이게 왠일 SVN 1.7부터 폴더 구조가 바뀌었다. 이젠 루트폴더에 .svn폴더 하나만 넣는다.
이거 때문에 신나서 재빨리 시도해보았다.. 잘된다.. ㅠ_ㅠ
방법은 간단... 난 mercurial(HG)를 사용했다. 윈도우즈에서 git 쓸려면 SSH 설치며 뭐며 머리가 졸라 아픈데.. mercurial은 그냥 TortoiseHg만 깔면 된다.. 다른거 신경쓸거 하나도 없다...
SVN과 같이 중앙 public depot을 사용하면 잘못된 코드를 체크인 했을때 그 때문에 피해를 입는 사람이 많다. 고로 제대로 작동안하는 코드를 집어넣으면 졸 욕을 쳐먹는다 -_-;
그래서 보통 코드가 제대로 돈다고 확인할때까지, 또는 코드를 보기 좋게 잘 다듬을 때까지 check-in을 안하곤 한다..... 이것의 문제는 한 1주일정도 체크인 없이 로컬 컴퓨터에서 계속 작업하는 경우가 있는데.. 그러다가 어느순간...
'아... 3일전에 만들어놨다가 제대로 안돌아서 지워버린 코드를 다시 쓰고 싶은데...'
라는 후회가 드는 경우가 있다는 것.... 이걸 미리 체크인 해놓았다면 단순히 버전 되돌리는 걸로 끝날 일... 중앙 depot시스템 때문에 못한거지... 퉤... - _-;
그래서 git이나 mercurial(hg)등의 DVCS (Distributed Version Control System)이 나름 각광을 받고 있었다. 하지만 게임개발을 하는 나에게 중앙서버가 없는 중구난방식의 분산 방식은 좀 별로였다. 내가 원한 것은 완전한 분산방식이 아니라.... 개인(private) depot에는 아무때나 내 맘대로 체크인 해놓고..... 나중에 준비가 되면 여태까지 해왔던 일들을 한번에 중앙 서버에 집어넣는 거였다. 한마디로 매일밤
"오늘까지 한 일. 어쩌구 저쩌구... 현재 컴파일은 안됨 ㅋㅋ"
이라는 commit log를 작성하고 싶었다고나 할까....
Perforce에서는 perforce sandbox를 사용하여 이 문제를 해결했었다. 하지만 Subversion을 사용할 때는 마땅히 어떻게 할 방법이 없었다. git-svn이라던가 hg-svn 등의 놈들이 있지만 이렇게 그다지 믿음이 가지 않았다. 난 모든간에 단순하고 간단한걸 좋아해서 이렇게 두가지 기능을 대충 합치는 프로그램을 안좋아한다. 사용하다가 말도 안되는 곳에 문제가 생겨서 골치만 아픈 경우가 너무 많거든...
하드디스크에 체크아웃 해둔 SVN 루트 디렉토리에 git이나 mercurial을 local depot를 만드는 법도 한 때 생각해봤으나.. 각 폴더마다 들어가 있던 .svn 폴더때문에 그것도 쉽지 않았다... 그래서 한동안 손을 들고 있었으나... 이게 왠일 SVN 1.7부터 폴더 구조가 바뀌었다. 이젠 루트폴더에 .svn폴더 하나만 넣는다.
이거 때문에 신나서 재빨리 시도해보았다.. 잘된다.. ㅠ_ㅠ
방법은 간단... 난 mercurial(HG)를 사용했다. 윈도우즈에서 git 쓸려면 SSH 설치며 뭐며 머리가 졸라 아픈데.. mercurial은 그냥 TortoiseHg만 깔면 된다.. 다른거 신경쓸거 하나도 없다...
모든간에 졸 간단한 방법:
- SVN checkout이 되어있는 root folder로 간다. SVN 버전이 1.7 미만이라면 1.7이상으로 업글한 뒤 현재 checkout 되어있는 소스트리를 최신버전으로 업데이트 해줘야 한다.
- 빈공간에 오른쪽 버튼을 누르고 TortoiseHg > Create Repository Here를 해준다.
- Init 대화창이 나오면. 뭐 다른 거 손 볼 필요 없다. 그냥 Create를 눌러준다.
- 이제 모든 파일이 제대로 보인다....
- 이제 private depot에 체크인 할때는 Hg Commit을... 중앙 depot에 체크인할때는 SVN Commit을 해주면 된다.
아, 정말 단순하고.. 깔끔한 방법이다.... 맘에 들어.. ㅠ_ㅠ
이 방법의 단점은 mercurial로 private depot에 체크인 했던 것은 changelist description을 자동으로 복사해올 방법이 없다는건데... 음.... 난 차라리 이 방법이 낫다. 매일 일하며 체크인 해 놨던 내용들을 쭈욱 살펴보면서 요약해서 적을 수 있으니까. 중앙서버까지 mercurial로 만들어 놓으면 local depot에 체크인 했던 changelist들이 전부다 개별적으로 submit된다. 맘에 안든다.... 뭐 collapse 익스텐션을 쓰면 이것도 해결 된다지만.. 역시 기본기능이 아닌 건 사람들이 그닥 많이 사용안하니 제대로 검증되지 않아서... 골치아픈 일이 많기 마련.... 따라서 extension은 그닥 쓰고 싶지 않아.....
어쨌든 이 방법 좋다... 만세~
2013년 1월 7일 월요일
XNA의 몰락. 그리고 대안
XNA가 처음 나왔을 때부터 열심히 사용했었다. 첨에는 PC와 Xbox 360용으로 돌 수 있는 게임을 만들 수 있다는게 맘에 들어서였고, 또 Xbox 360에 올리면 수익모델이 있다는 것도 맘에 들었었다. 하지만 불행히도 엑박에서 XNA 게임이 차지하는 비중이 매우 미미한 수준에서 그친 이후 XNA는 여러번 변화를 겪게 된다. XNA 4.0부터던가... 윈폰 7.0용으로 게임을 만들려면 XNA를 써야 했다. 모바일 플랫폼을 지원하려고 노력을 퍼붓다 보니 당연 PC나 엑박용 지원은 미미해졌고 그로 인해 XNA의 입지가 조금씩 애매해져갔다.
물론 그럼에도 난 XNA를 자주 사용했는데... 스크린 스페이스 데칼 프리젠테이션에 사용한 데모 프로그램도 XNA로 만든 거였다. XNA가 가지고 있는 컨텐츠 파이프라인이라던가 C#으로 쉽게 DirectX 기능을 사용할 수 있다는 사실이 프로토타입을 만드는데는 아주 적합했다고 할까...?
하지만 이제 윈폰 8이 XNA 지원을 중지한다고 한다. 그 대신 WinRT를 사용한다고... Visual Studio 2012도 XNA를 지원하지 않는다.. (뭐 어떻게 사용할 수 있는 꼼수는 있다.) 물론 Visual Studio 2010을 사용하며 XNA 4.0을 계속 사용할 수는 있지만 XNA에는 다음과 같은 제약이 있다.
C#을 지원하는(정확히 말하면 어떤 .NET 언어 라도 지원하는) DirectX 로는 SharpDX와 SlimDX가 있다. 둘다 API도 매우 비슷하고 사용법도 거의 같다. 그리고 둘다 64비트를 지원한다. 최근에 64비트용 프로토타입을 만들 일이 있어서 둘다 사용해봤는데... 사용해본 바로는 SharDX가 SlimDX보다 낫다. 이유는 다음의 2개:
물론 그럼에도 난 XNA를 자주 사용했는데... 스크린 스페이스 데칼 프리젠테이션에 사용한 데모 프로그램도 XNA로 만든 거였다. XNA가 가지고 있는 컨텐츠 파이프라인이라던가 C#으로 쉽게 DirectX 기능을 사용할 수 있다는 사실이 프로토타입을 만드는데는 아주 적합했다고 할까...?
하지만 이제 윈폰 8이 XNA 지원을 중지한다고 한다. 그 대신 WinRT를 사용한다고... Visual Studio 2012도 XNA를 지원하지 않는다.. (뭐 어떻게 사용할 수 있는 꼼수는 있다.) 물론 Visual Studio 2010을 사용하며 XNA 4.0을 계속 사용할 수는 있지만 XNA에는 다음과 같은 제약이 있다.
- 64비트를 지원하지 않음
- DirectX 9기능까지만 지원함. (즉 DX11 기능을 쓸 수가 없음)
이제 대안을 찾을 때... 결국 XNA가 좋았던 이유는 다음의 두가지였다.
- C#지원
- 컨텐츠 파이프라인
그러니 이것만 어떻게 해결할 수 있는 대안을 찾으면 되는게 아닌가...?
C# 지원
C#을 지원하는(정확히 말하면 어떤 .NET 언어 라도 지원하는) DirectX 로는 SharpDX와 SlimDX가 있다. 둘다 API도 매우 비슷하고 사용법도 거의 같다. 그리고 둘다 64비트를 지원한다. 최근에 64비트용 프로토타입을 만들 일이 있어서 둘다 사용해봤는데... 사용해본 바로는 SharDX가 SlimDX보다 낫다. 이유는 다음의 2개:
- SharpDX가 속도가 더 빠름 (API 호출의 부하가 적음)
- SharpDX가 설치가 더 쉬움(그냥 DLL파일만 복사해놓으면 끝)
고로 SharpDX를 사용하면 C# 지원문제는 해결..
컨텐츠 파이프라인
사실 이 부분은 딱히 방법이 안보인다. 아직... 물론 C#자체 또는 SharpDX자체에서 텍스처 파일 로딩기능은 거의 다 구현해놨으니 이건 큰문제가 아닌데... 오디오 라던가 메쉬 같은건 여전히 좀 문제다.
하지만 비주얼 스튜디오 2012에 FBX를 이용하는 예제가 이미 포함되어있고, MS에서 WinRT를 더 제대로 지원하려면 컨텐츠 파이프라인을 좀더 낫게 만들어 주지 않을까? 하는 기대만 한다...
아니면 내가 시간이 좀 나면 짬짬이 이런걸 만들어서 공개하고 싶기도 한데... 현재 내 스케줄을 봤을때 그건 거의 불가능할듯...
결론 - SharpDX
난 일단 SharpDX로 갈아타기로 했다. 프로토타입이나 툴에서 필요한 메모리가 32비트에서 지원할수 있는 용량을 이미 넘어섰기때문이다. 컨텐츠 파이프라인은 텍스처나 메쉬정도는 이미 지원되니.. 나머지거야 어떻게든 닥칠때마다 해결하면 되겠지.
피드 구독하기:
글 (Atom)