Ewan Shin's Blog

심즈, 심시티를 만든 윌 라이트의 TED 강연

2012-03-28T02:17:00.001-07:00

스포어를 플레이한지 3-4년이 지나긴 했지만.. 모노리스가 있었단 말인가? 나도 참 호기심이 부족했군. ㅠㅠ

1.0 데이터 주도적 설계의 마법

2010-12-03T01:58:00.001-08:00

제1부
프로그래밍 기법들

1.0 데이터 주도적 설계의 마법
아이디어 #1 기본
필요할때마다 텍스트를 읽어서 처리할수 있는 시스템을 만드는게 좋다
(최종 출시 시점에서는 이진 파일을 이용하겠지만, 개발 단계는 텍스트 파일을 사용하여 편집/수정이 쉽게 한다)

아이디어 #2 최소한의 원칙
상수들을 하드 코딩 하지 말고 텍스트 파일에 넣어야 한다

아이디어 #3 하드 코딩을 아예 없애라
게임을 단일한 용도로 설계하지 말고 최대한 범용적인 기능성을 담당하도록 분리한다

아이디어 #4 게임의 흐름은 스크립트로 제어할 것
게임 안에서의 어떠한 장면을 연출할 때는 스크립트를 사용하는 것이 좋다
단순한 원인-결과 로직 역시 스크립트의 대상이 된다
스크립트를 채용하면 시스템의 설계를 상당히 단순화시킬 수 있다

아이디어 #5 스크립트 남용의 해악
스크립트를 사용할때의 원칙: 로직과 데이터의 분리
복잡한 로직은 코드에, 데이터는 코드 외부에.

스크립트는 데이터의 성격과 로직의 성격을 함께 가지고 있다는 위험성이 있다.

경계가 애매하다는 것이 문제
로직이 복잡하면 코드에 넣어라
스크립팅 언어는 게임 개발에 필요한 시간과 자원을 너무 소비하지 않도록 해야 한다

아이디어 #6 데이터의 중복을 피해라
여러곳에서 쓰일 데이터를 전역적인 데이터로 만들어라

아이디어 #7 데이터를 만들어 내는 도구를 작성할 것
제대로 된 도구를 만들어 두면 게임 개발 속도가 훨씬 빨라진다.

C++를 이용한 크로스 플랫폼 개발 - 빌드 시스템과 툴 체인

2010-10-18T20:07:00.000-07:00

Chap2 빌드 시스템과 툴 체인

크로스 플랫폼 프로젝트의 성공 열쇠는 추상화

아이템7: 각 플랫폼에서 가장 잘 특화된 컴파일러를 사용하라

성능과 플랫폼 지원을 선택 기준으로 삼아 가장 뛰어난 컴파일러를 선택한다
프로젝트에서 여러가지 컴파일러가 사용되면 컴파일러 특화 코드를 사용할 가능성이 적어진다.

아이템8: IDE를 적절히 활용하라

플랫폼마다 빌드 방법이 다르므로 gmake와 같은 크로스 플랫폼툴을 사용하라

편집기나 디버깅을 위해 IDE를 사용하는 것은 좋으나, 빌드 시스템으로는 사용하지 말아야 한다
IDE에 기반한 빌드 시스템은 다른 플랫폼으로 이식되지 않으므로 Makefile을 사용해야 한다

아이템9: Windows에 Cygwin을 설치한다

Windows 또는 UNIX 계열의 시스템에서 빌드나 디버그를 해야하는 경우를 위해 Cygwin등을 사용한다

아이템10: 크로스 플랫폼 개발을 위해 make를 이용한다

특정 IDE를 사용하면 이식성과는 거리가 멀어지게 된다
이식 가능하도록 만들고 싶다면 크로스 플랫폼한 방식을 찾아야 한다

C++를 이용한 크로스 플랫폼 개발 - 정책과 관리

2010-07-21T07:38:00.000-07:00

Chap1 정책과 관리

아이템1: 모든 플랫폼을 동등하게 생각하라

Netscape 의 예

1군 플랫폼: Mac OS X, Linux, Windows

그 외: BSD, Solaris, AIX, HP/UX 등

1군 플랫폼에서 모든 기능이 구현되어야 하며, 릴리즈에 앞서 모든 내부 테스트를 통과해야 함

기준을 만족하지 못하면 릴리즈 불가

플랫폼간 차이는 동일한 구현을 어렵게 한다

1. 컴파일 타임의 에러를 체크한다

2. 스모크 테스트. 매일 아침마다 마지막 빌드된 바이너리로 QA에서 전체적인 테스트를 수행한다

아이템2: 공통된 코드베이스를 구축한다

공통적으로 사용할 수 있는 코드와 플랫폼 특화 코드를 분리한다

팩토리 디자인 패턴을 사용한다.

플랫폼 특화 팩토리를 만든다

플랫폼 별의 차이는 폴더를 나누어 저장한다.

크로스 플랫폼 빌드에서의 주의해야 할 내용

- 해당 플랫폼에 맞는 컴포넌트와 라이브러리만 빌드한다

- 올바른 Makefile 파일을 사용하도록 한다

- #define이 잘 동작하도록 명령 행 인수를 이용한다

- 빌드된 컴포넌트와 응용 프로그램은 적당한 폴더에 복사한다. 테스트와 배포는 이 폴더를 기준으로 한다

아이템3: 개발자가 작성한 코드는 여러 컴파일러로 컴파일해봐야 한다

여러 컴파일러로 빌드하는 것의 중요성

- 컴파일러에 특화된 기능, 플래그, 매크로의 사용을 피할수 있도록 해준다

- C/C++ 표준의 구현 차이로 인한 충격을 최소한으로 막아주고 검증되지 않은 기능을 사용하지 않도록 해준다

- 각 컴파일러는 서로 다른 종류의 경고와 에러를 알려주기 마련이다. 이런 경고와 에러를 수정하면 개발이 좀 더 부드럽게 이루어질 수 있으며 코드도 건강해진다

- 각 컴파일러가 생성하는 이진 코드는 서로 다르다. 때문에 발견하기 어려운 문제들을 해명하는데 도움이 된다

아이템4: 여러 플랫폼에서 코드를 빌드한다

- 모든 플랫폼에서 빌드 테스트와 스모크 테스트를 하는 것은 빌드 트리를 깨끗하게 관리하는 것 이상의 의미를 가진다

- 모든 개발자가 모든 플랫폼에서 빌드해보길 원하지도 않고, 그럴수도 없다

- 소스 코드를 저장소에 체크인하기 전에 모든 플랫폼에서 빌드하고 테스트해볼것을 강제한다면 모든 플랫폼이 동일한 속도로 개발될 것이며, 그만큼 크로스 플랫폼 개발이 성공적으로 이루어질 가능성이 높아진다

아이템5: 각 플랫폼에서 빌드를 테스트한다

세 개의 메인 플랫폼을 매일 아침 테스트

스모크 테스트를 위해, 매일 아침에 Tinderbox 빌드들이 취합되어 QA에 전달(스모크 테스트 완료전까지 모든 체크인은 금지)

플랫폼 중 하나에서 새로운 문제 발견시 Tinderbox와 bonsai는 해당 문제와 관련된 체크인을 격리시킴

아이템6: 컴파일러 경고에 귀 기울이자

경고가 발생한 코드는 거의 이식 불가능하다

1. 일정 시간을 추자하여 경고를 수정하고 체크인한다

2. 빌드 과정에서 발생한 경고의 수를 확인하여 일정 수준을 넘어서면 체크인을 금지시킨다

컴파일러 옵션을 조정하여 언어 표준을 강제할 수 있다(언어 표준에 맞지 않은 모든 코드들을 경고나 에러로 출력할 수 있도록)

메모리 모델과 이름 공간

2009-06-30T10:54:00.001-07:00

보통의 지역 변수, auto를 사용하여 선언된 지역 변수, register를 사용하여 선언된 지역변수

같은 점	자동 기억 존속 시간, 지역 사용 범위를 가짐. 다른 번역 단위들에 이름을 공유할 수 없다
다른 점	register 제한자를 사용하면 변수가 메모리 스택이 아닌 CPU 레지스터 등에 저장된다

문제점: 아래와 같은 내용을 발견할 수 있었다

== register 변수

변수는 보통 컴퓨터의 메모리에 저장된다. 그러나 운이 좋으면 레지스터 변수는 CPU 레지스터 또는 더 일반적으로 가장 빠른 메모리에 저장되는데, 보통 변수보다 더 빠르게 접근하고 계산될 수 있다. 이외의 부분들은 자동변수와 똑같다. 이때 운이 좋으면 이라고 표현한 것은 레지스터 변수의 수가 제한되기 때문이다. 컴파일러는 레지스터 수와 선언된 변수의 수를 가중치에 따라 조정하기 때문에 레지스터 변수로 선언했지만 자동 변수로 되는 경우도 있을 수 있다. 그리고 레지스터 변수로 선언될 수 있는 형도 제한이 있다. 또한 & 연산자도 레지스터 변수에는 적용할 수 없다.

즉, 실제 레지스터 변수로 선언을 해도 레지스터 변수로 사용될지 안될지는 알 수 없다.

위의 코드를 실행했을 때 레지스터의 변화는 아래와 같았다.

어셈블리 코드만으로 비교를 해보면 레지스터 변수와 일반 변수의 차이를 알 수 없었다. 해당 내용을 알 기 위해선 레지스터 값을 비교해 보았다

자동변수를 선언했을 때는 아래와 같이 값이 메모리에 저장되는걸 볼 수 있었다

그러나 레지스터 변수를 선언한 경우는 EAX에 값이 저장되는 걸로 파악되었다.

레지스터 변수에 대한 추가적인 내용은 아래와 같았다(출처: http://blog.daum.net/zzigee/5116707)

프로그램을 코딩하는 중에 자주 쓰는 변수들을 register 변수로 선언하여 사용한다. 하지만 똑똑한 Compiler는 직접 선언해 주지 않아도 register 변수로 잡기도 한다(Compiler에 의한 최적화 수행). Memory Mapped I/O(메모리의 특정 영역을 특정 장치와 연결해서 사용)의 경우에는 문제가 발생한다. 왜냐하면, 어떤 장치의 한 영역을 나타내는 변수가 있고 이 변수를 통하여 그 장치의 상황을 받아들여 특정한 일을 처리하는 경우 당연히 이 변수는 자주 쓰이는 변수가 되므로 Compiler에 의해서 Register 변수로 처리가 될 수 있는데 이를 미연에 방지하고자 volatile이라는 Keyword를 주게 되면 Compiler는 이 변수에 대한 최적화를 수행하지 않게 된다. 따라서, 원하는 결과를 얻을수 있게 된다.

메모리 변수(volatile variable)는 지역 변수를 선언할 때 레지스터가 아닌 반드시 메모리에 변수를 만들어 처리하도록 한다. 그러면 "할 수 있다면 빠른 레지스터 변수를 사용하는 것이 더 낫지 않느냐?" 라는 반론이 제기될 수 있는데 일반적으로 메모리 변수는 인터럽트 루틴 등의 변수에 사용된다. 레지스터 변수인 경우 인터럽트 루틴에서 그 변수의 내용을 바꾸면 레지스터에 있는 값이 바뀌므로 언제 그 레지스터의 값이 없어질지 알 수 없다. 이런 경우 메모리 변수로 선언하기 위해 volatile을 사용한다.

volatile은 컴파일러 키워드이다. 특별히 따로 최적화를 하지 않고 쓴대로 수행시키라는 의미이다. 함수에 이것이 있으면 함수 내부를 컴파일할때 최적화 옵션이 있어도 최적화를 수행 하지 않는다. 변수에 이것이 붙으면 속도를 위해서 변수를 레지스터에 올려놓고 쓰는일 같은 것을 안하게 된다. 보통 IO Port를 특별한 변수 이름으로 지정해놓고 사용하고자 할때 volatile키워드를 붙여서 쓴다.

일반적으로 컴파일러는 최적화를 하는 동안 불필요 하다고 생각되는 코드를 생략을 하게된다. 그러나 volatile을 사용하는 경우 이 변수와 관련된 내용은 생략하지 않는다. 키워드 volatile이 정의되어 있지 않으면 컴파일러는 마지막 명령만 남기고 이전 명령들을 생략할 수 있다.
예)

        char * Addr;

        Addr = (char *)0x10000;
        *Addr = 0x55; /*생략한다..*/
        *Addr = 0xAA; /* 이것만 인식한다*/

위의 경우 단지 0x10000에 0xAA만 쓴 것으로 컴파일러는 생각하게 된다. 일반적으로 같은 곳에 값을 써주거나 값을 읽을 일이 많은 메모리나 레지스터인 경우에는 volatile를 써주는 것이 좋다. 만약 컴파일러가 최적화 옵션을 사용하지 않는다면 써줄 필요는 없다.

volatile 선언은 디버그 모드에서는 작동하지 않고 보통 릴리즈 모드에서 최적화시에 발생한다. 쉬운 예를 들자면 for (;;) { int a = 1; .. .. } 이렇게 되어 있을때. 이 루프가 한 100만번 돈다고 하면. int a = 1;은 루프 밖으로 빼는게 실행 속도가 빨라진다. 컴파일러는 자기가 알아서 이런 것을 루프 밖으로 빼버린다. 그런데 이 문장을 빼는 것이 큰 문제가 되는 경우도 있다. 이럴때 volatile int a = 1 해주면 최적화 대상에서 제외 된다.

복합 데이터형

2009-06-28T10:15:00.001-07:00

스트링의 배열을 생성한다면 메모리의 주소는 어떻게 되는가?

위와 같은 코드를 실행하였을 때 AaA, BbB가 저장되는 메모리의 주소는 아래와 같았다.

그렇다면 이미 메모리에 길이가 정해진 후 AaA에 있는 문자열 대신 길이가 긴 문자열을 사용한다면 어떻게 되는가?

해당 명령을 실행하면 아래와 같이 AaA가 저장된 0x0012FEBC의 메모리 값이 주소 값으로 바뀌는 것을 볼 수 있었다.

위와 같이 전혀 다른 내용으로 변화된다. 그렇다면 실제 데이터는 어디에 있는가? 변경된 데이터는 해당 주소에 있는 값을 주소로 한 0x00399518에서 발견할 수 있었다

위의 경우는 아래의 코드에서 보는 것과 같이 기존 길이보다 새로 할당된 크기가 크다면 새로 메모리값을 assign하면서 발생하는 경우이다.

자동공간, 정적공간, 동적공간

자동공간: 함수 안에서 정의되는 보통의 변수

정적공간: 프로그램이 실행되는 동안에 지속적으로 존재하는 공간

동적공간: 자유 공간 또는 힙(Heap) 이라고 불림
new와 delete 연산자를 사용하여 관리
자동변수와 정적 변수가 사용하는 메모리와 분리되어 있다

위와 같이 코드를 짰다고 가정해보자. 이 때 위의 코드는 아래와 같은 어셈블리어로 변환된다

nOuter의 값은 메모리상에서 아래와 같이 확인이 가능하였다

TRACE를 생활화 하자

2003-03-30T15:52:00.000-08:00

기본 중의 기본이지만, 의외로 책에는 설명이 잘 설명이 안되있는 편이라..
거기다 내공이 짧기 때문에...

일단 TRACE부터 시작하겠습니다.

함수를 짤때
void CTest::TestFunction(int nCode)
{
.. 실제 내용...
return;
}

보통 저렇게 짜게 됩니다. 이때 문제점은?? 프로그램을 돌리다 중간에 뻗으면 이 녀석이 어디서 뻗었는지 알 수 없다는 겁니다. 뭐, 어떤 함수에서 죽었는지야 대충 눈치 챌수도 있겠지만, 만약 그 함수가 100라인 이상이라면(사실 그렇게 짜면 잘못된거죠.. ) 이건 삽질하기 쉽습니다.

이 때, 초보일 경우 많이 쓰는 방법이 (또는 ASP 하는 분들도 많이 쓰더군요) 메시지 박스입니다.
그러나 이런 경우 메시지 박스를 쓸 것이 아니라 TRACE란 함수를 쓰는 것이 1만배 더 좋습니다.

위의 샘플을 예제로 과연 nCode라는게 제대로 들어온 값인지 알고 싶을 때라면

void CTest::TestFunction(int nCode)
{
.. 실제 내용
TRACE("n nCode value is %d", nCode);
.. 실제 내용...
return;
}

저렇게 구현해 주시면 됩니다. 이 때 어플리케이션의 실행 시점에서 (Debug 모드일때만 입니다. Release 모드에서는 동작하지 않음) 아웃풋 창에
nCode값을 보여주게 되죠.

참고1. TRACE의 특징은 _DEBUG 즉, Debug모드에서만 동작함. 즉 컴파일 옵션을 Debug로 할때는 컴파일이 되지만 Release 모드에서는 컴파 일러가 그 명령을 무시하고 컴파일 해 버립니다. 즉, 실제로 배포할 때는 빠지게 되는거죠.(여기서 나오는게 프리컴파일이란 개념인데 그건 어려우 니깐 무시. 그냥 컴파일러가 알아서 빼준다고 생각하면 됨) 메시지 박스를 쓰게 되면 이 녀석은 Release 모드에서도 남아 있죠. 덕분에 실제 배포할 땐 빼야하는 메시지 박스가 버젓이 남아있는 경우도 발생합니다. 거기다 실 배포시엔 코드 사이즈도 줄어들겠죠?

TRACE의 방법은 기본적으로 c의 printf랑 유사합니다.

TRACE("포맷된 문자열", 변수명);

저런 식이죠.

그럼 반론이나 부가 이야기 많이 해주세요

ps) 저번주에 알았던 황당한 사실. TRACE는 출력 문자열이 제한됨. 글쎄 500문자가 넘어가니 assert가 나 버리더라는.. ㅡ.ㅡ 이런 MS같으니라고. 그래서 찾아낸 것이 afxDump. 기본적으론 cout과 같은 스타일로 사용하면 되며, 출력에 제한은 없는 것으로 파악됨(현재 최고 길이 3700문자까지 이상없었음)