[Kopernikanische Wendung]

"Hey Bob - how's it going at UberGameSoft?"
"Hey Tom - it's goingwell. I'm figuring out a neat HDR system, Jim's doing a cool physicsengine, and Frank's got some awesome post-processing effects."
"Cool. So you guys must be well into production by now, right?"
"Kinda,but not really. We still have trouble with the whole export pipelineand there's a lot of pain getting assets into the game."

At this point, I usually start yelling at people and preparing another ranty blog entry. And thus...

There'sa bunch of stuff that is neat, and it's geekily cool, and we asengineers all love to play with them and they generate some killer GDCtalks and suchlike. But they're all unimportant next to the stuff thatis necessary to ship the game. We're now looking at team sizes of 50-150 people for 2-4 years, and that's a lot of assets.

Youneed the smartest coders in the building to be making sure thateveryone else can work efficiently. And that means they're toolscoders. Yes, "tools" - don't look at me like I said a dirty word.

Theproblem is that at heart a lot of us are still bedroom hackers. Andthat's a great mentality to have - it keeps us honest. But at thosenumbers, you have to have some of the dreaded word - "management". Butwe're smarter than the average bear, so we can use geek management, notPHBmanagement. And it's not management of people so much as management ofdata. Good people who like the work they do and the people they workwith will generally manage themselves pretty well. The problems comewhen the data flowing between them sets up dependencies. Now obviouslythat's inevitable - but people can cope with obvious dependencies -like you can't animate a character very well until the rigging is doneor whatever.

The problem is dependencies that aren't as obvious.They're obvious to us coders, because we're the ones who write thesystems. And unfortunately the easiest way to write most systems is tohave all the source data available at once, throw it in a bigpost-processing hopper and out comes the DVD image, and then we shipit. Fairly obviously, this is a disaster in practice. So instead weneed to think carefully about the chain of dependencies and how we canisolate one person's changes from another, and allow people to work onrelated objects at the same time without getting stalled.

Thisis almost exactly the other big problem coders are facing - parallelprocessing. And we all know that parallel processing is really reallydifficult, so we put our smartest coders on the problem. And the sameshould happen with the tools - it's an even bigger parallel processingchallenge, and the problem is not as well-defined as "make the physicsgo faster" because half the time when you start a game you don'tactually know where you're going.

So I'm going to do some moreposts on some of the detailed aspects once I get them straight in myhead. But the big message is really that the old days of the hero-codersaving the day with leet gfx skillz are over. Shaders just aren't thatdifficult to write, HDR is a matter of detailed book-keeping, andshadows may be a pain in the arse but they're not fundamentally goingto make or break your game. Good asset management on the other hand canmean the difference between shipping and going bankrupt. That's whatthe new breed of hero-coder needs to focus on.

-- from TomF`s Tech Blog

팀을 옮기고 집들이겸 간 자리에서 이루어진 "사발식"
목숨을 걸고 받은 사발이기에 그만큼 진한 동료애를 느낄수 있었다는..
뭐 결국 드래곤바이트를 쏴 대야 했지만..^^

character 관련 FSM 을 realization 하면서 와우정도의 상태머신은 아니더라도, 국내 출시작인 AION만큼의 상태체크를 하고 싶어서

요새 새로운 Task를 진행하면서도 character에 관하여 가장 중요하다고 할수 있는 status machine 이기에 꾸준히 

Improve 하던중 우연잖게 좋은글을 보고 동감하는 부분이 있어 링크를 겁니다.

-----------------------------------------------------------------------------------------------------------

[origin likn : http://www.gisdeveloper.co.kr/entry/Template을-이용한-Observer-패턴-1단계]

C++의 template을 이용해서 Observer를 구현하는 것에 대한 단계적 설명입니다. 원본은 데브피아에서 김태현(tipani)님이 올려 놓으신 글을 기반으로 작성했으며 한단계 더 업그레이드 했습니다. 제가 늘 느껴오는 것이지만 C++의 template은 기존의 클래스간 관계도에 한정해 볼적에 그 디자인을 획기적으로 개선한다는 점에서 그 판도를 확 바꿀 수 있는 강력한 개념이라고 생각합니다. 아무쪼록 제가 김태현님의 글을 보고 매우 재미있게 template에 한발짝 다가섯듯이 여러분도 제 글을 통해 template에 한발짝 다가 설수있다면 정말 기쁘겠습니다. 참고로 이 글을 읽기 전에 Observer 패턴이 무엇인지 패턴입문서를 살펴보시길 바랍니다. 또한 이 글의 진행은 단계 단계 개선해 나가는 흐름으로 진행된다는 점에 유의하시길 바랍니다.

먼저 1단계입니다. 아래의 코드는 Observer들의 관리에 대한 책임을 맡고 있는 Observed 클래스입니다.

template <class T>
class Observed {
public:
  Observed() {}
  typedef std::list<T *> typeObservers;
  virtual ~Observed() {}

  void RegisterObserver(T *pOb) {
  m_listObserver.push_back( pOb );
  }

  void UnRegisterObserver(T *pOb) {
  m_listObserver.remove(pOb);
  }

protected:
  typeObservers m_listObserver;

};
Observed가 관리하는 Observer 클래스인 Observabe 입니다. 단순히 Observed가 호출할 Observer의 OnEvent 함수가 순수가상함수로 선언되어 있습니다.

class Observable {
  virtual void OnEvent(int a) = 0;
};
그리고 아래는 Obserable를 상속받아 구현한 클래스들입니다.

class Observable_A : public Observable
{
  virtual void OnEvent(int a) {
  std::cout << "Fire_A -> " << a << std::endl;
  }
};

class Observable_B : public Observable
{
  virtual void OnEvent(int a) {
  std::cout << "Fire_B -> " << a << std::endl;
  }
};
이제 마지막으로 Observed가 자신이 관리하고 있는 Observable의 OnEvent를 호출해 줘야 하는데, Observed 클래스는 자신이 관리하고 있는 Observable의 타입을 모르기 때문에 Observed와 Observable의 관계를 연결해 주기 위한, Observed로부터 상속받은 EventSrc 클래스가 필요합니다.

class EventSrc : public Observed<Observable>
{
  void Fire(int a)
  {
  typeObservers::itrator it;
  for(it=m_listObserver.begint(); it!=m_listObserver.end; ++it) {
  (*it)->OnEvent(a);
  }
  }
};
드디어 1단계의 Observer 패턴의 구현이 완성되었습니다. 실제 사용하는 예는 다음과 같습니다.

int main() {
  EventSrc *pES = new EventSrc();
  Observable *pO_A = new Observale_A();
  Observable *pO_B = new Observale_B();

  pES->RegisterObserver(pOA);
  pES->RegisterObserver(pOB);

  pES->Fire(99);


  delete pO_B;
  delete pO_A;
  delete pES;

  return 0;
}
1단계에서 산출된 소스만으로도 충분할 수도 있겠지만, 큰 문제점이 하나 있습니다. 그것은 바로 SRP(Single Responsiblity Principle)를 위반한다는 사실입니다. 즉, Obserable를 관리하는 책임을 Observed와 EventSrc라는 두개의 클래스가 책임을 나눠서 지고 있다는 점입니다. 그럴수밖에 없는 이유는 본문에 언급을 했구요. 

이제 다음 2단계 이후부터는 이러한 SRP의 원칙을 지켜나가는 것을 해결문제로 다뤄나가면서 점차적으로 개선된 Observer 패턴을 구현해보겠습니다.

이 글이 도움이 되셨다면, 짧은 댓글이라도 달아주시길, 큰~ 힘이 됩니다. ^^*

종종 점심을 나가서 먹을때가 있다..점심을 먹으며 우연히 나온 된장남놀이 이야기..
우리도 멋지게 그날 점심먹고 된장남 놀이를 했다..커피빈에서..
손에는 멋지게 커피빈을 들고,,,,
허나 발에는 아주 헝그리한 슬리퍼가 신켜져 있었다는...^^

이런 저런 수식의 계산으로 펜을 잡을 일이 많다..
처음엔 샤프에 볼펜을 사용했었으나, 아들녀석이 연필을 지는것을 보고 하나 몰래 훔쳐서(?!^^;) 요즘엔 연필을 사용하고 있다.
볼펜이나 샤프를 사용하는 것 보다 힘도 덜 들어가고 그립감도 좋고...
훗 훗 무엇보다 종종 연필을 깍을 때면 예전 군대에서 총을 닦던 느낌이랄까?!
웬지 집중도 되는것 같고, 스트레스도 풀리는것 같고..
옛 추억이 회상되는듯 해서 앞으로도 쭈~욱 연필을 사용할 듯 하다.

Doxygen 설치 부터, 사용법 까지 간단한 매뉴얼을 제작해 보려 했는데, 검색하다 보니 정리가 잘 된 사이트가 있어서
"수레바퀴는 다시 개발하지 않는다" 란 모토하에 링크로 대처합니다.

Doxygen으로 프로젝트 문서화하기 : 작성자님의 수고에 감사말씀드리고요.^^

 - 뭐 Doxygen 말고도 Kingtools 라는 .Net 에 맞춰나온 툴도 있습니다.
그래서 저 같은 경우는 .Net 에서는 Kingtools 를 그리고 툴관련 코딩 할때 VC6++ 을 사용할때는 Doxygen 을 사용합니다.

요즘 Effect관련해서 렌더하는데 렉을 유발한다고 해서 이펙트관련 툴들을 수술하고 있다..
근데..항상 알고 있다고 생각하는 몇몇의 MFC 매크로의 혼동으로 종종 MFC관련 작업을 진행할 때 마다 검색을 해 보게 되는듯 하다
그래서 간단하게 나 자신만을 위한 Document 작업을 해 보려한다. 이하는 업무일지로 작성하는 DOC에서 일부 발췌한것이다.(이늠의  VNC를 통하여 뭘 하려면 제대로 되는게 없다..;;)

CRuntimeClass 이란?

► CRuntimeClass는 본질적으로 특정 클래스에 대한 정보를 담고있는 구조체이다. RTTI는컴파일러 레벨에서 제공되는 반면,CRuntimeClass 는 MFC에서제공된다.

또한 RTTI와달리 객체 생성 기능,객체 저장을 위한 직렬화 기능도 제공을 한다.

▪ 일반화된 객체 생성 :클래스 이름을 사용하지 않고 객체를 생성하는기능

▪ 메모리 상의 객체 자료형검사 : RTTI 와같은 기능

▪ 메모리 상의 객체 데이터유효성 검사 : 메모리상에서의 유효한 영역을 점유하고 있는지 검사

▪ 객체 직렬화 및 이를 위한정보 제공 : 객체를저장 매체에 일관된 방법으로 저장하는 기능

CRuntimeClass사용 요구 조건.

► CRuntimeClass구조체를 클래스의 정적 멤버 변수로 선언해야한다.일반 멤버변수는 객체가 생성되어야 사용을 할 수가 있다.객체가생성되지 않은 상태에서도 사용할 수 있어야 하므로정적 멤버로 선언한다.

MFC는CRuntimeClass 를 정적멤버로 쉽게 선언할 수 있도록 세 종류의 매크로를제공한다.

이하는 다음에...VNC.. ㅎㄷㄷ 훗훗..

► 종종 라이브 업데이트 일을하다 보면 분명 작업을 해서 배포를 했는데,거짓말과도 비슷한 버그 리포팅이 들어올때가 한두번이 아니다..

그래서 생각을 한게 레지나정보파일을 따로 둬서 버젼체크를 하는 방식이 아니고,(요즘 어지간한 유저들은 레지를 만져 버젼이나 기타 정보를 수정함으로서 업그레이드 서버를 안 거치고 그냥 인증으로 가는 경우가 많은듯 하다...;;;)클라이언트 파일 자체에 버젼 리소스를 할당함으로써 버젼체크를 하도록 구조를 변경하였다.

이제 거짓말장이 유저와 거짓말장이운영진과도 안녕이군..하하하.

이하는 아주 간단하게 WinEntry에서 버젼리소스의 값을 검사한 코드이다....

또한 안정성을 위해서 역시런쳐에서도 이와 비슷한 작업을 해 주었다.

TCHAR szPath[_MAX_PATH];

///search directory

GetModuleFileName(0,szPath, _MAX_PATH);

DWORD dwSize = GetFileVersionInfoSize(szPath, 0);

LPVOID lpData = malloc(dwSize);

///Get fileversioninfo resource

GetFileVersionInfo(szPath,0, dwSize, lpData);

structLANGANDCODEPAGE

{

     WORDwLanguage;

     WORDwCodePage;

}*lpTranslate;

UINTcbTranslate = 0;

VerQueryValue(lpData,_T("\\VarFileInfo\\Translation"), (void**)&lpTranslate,&cbTranslate);

TCHARszKey[256];

_stprintf(szKey,_T("\\StringFileInfo\\%04x%04x\\FileVersion"),

lpTranslate->wLanguage,lpTranslate->wCodePage);

TCHAR*pszValue = 0;

UINTuLen;

VerQueryValue(lpData,szKey, (void**)&pszValue, &uLen);

//_putts(pszValue);

free(lpData);

함수의원형이다... 다른함수의 원형에 대해서도 궁금하시면...MSDN을 만나세요..^^

boolAPIENTRY VerQueryValue( const LPVOID pBlock, LPSTR lpSubBlock,LPVOID* lplpBuffer,

PUINTpuLen);

앗 하나더 중요한것이 ...#pragma comment (lib, "version.lib") 훗훗

[항목.5]컴파일러가 만드는 함수들을 주의하자.

► 컴파일러는 기본적으로 복사생성자, 복사 대입연산자를 선언하지 않고 외부에서 호출할 경우 자동으로public 선언을 한다.

► 참조자를 멤버로 갖고 있는클래스에 대입연산을 지원하려면 직접 복사 대입연산자를 정의해 주어야 한다.

ex)

classDev{

public:

string&m_strName;

}

Deva;

Devb;

a= b;

컴파일 에러 :C++참조자는 원래 자신이 참조하고 있는 것과 다른객체를 참조할수 없다.

► 상수 멤버에 대해서도 위와같은 동작을 한다.

[항목.6]컴파일러가만들어낸 함수가 필요 없으면 확실히 이들의 사용을막자.

► 컴파일러는 복사 생성자,복사 대입 연산자를 자동으로 public선언을할수 있다.

그러므로,해당 클래스에 대해서 복사관련 작업을 막고싶다면, 직접Private로 선언하자.

► 하지만 위와 같이 할경우 또하나의 문제는 멤버로써 호출을 하거나,friend 함수가 호출될수 있다....그래서선언만 하되 정의는 하지 않는 방법이 있다.

ex)

classDev{

private:

Dev(constDev&);

Dev&operator=(const Dev&);

}

► 더좋은 방법 :링크시의 에러를 컴파일시로 옮겨보자..에러를빨리 잡자..

ex)

classUnCopy{

procted:

UnCopy(){}

~UnCopy(){}

private:

UnCopy(constUnCopy&);

UnCopy&operator=(const UnCopy&);

}

classDev : private UnCopy{ ... }

► 위와 같이 기본 클래스를상속하여서 사용한다면......멤버로써호출이 안 된다.

흠..
하루 하루가 무료하다.
도통 시간도 안 가고, 일을 아무리 빡세게 해도,,집중이 되기 보다는 짜증만나고..
공부하려고 책을 잡아도 들어오지도 않고,
뭔가 대책을 세워야 하겠건만..^^

날씨 탓인가?!....

Nokia 의 N810 에 이어 너무도 갖고 싶은...
요새 한참 N810 과 ASUS의 eeePC를 놓고 고민하던중.
아직 출시 미정이지만..