loading...

=기타/펌= Microsoft Visual Studio: Visual C++ 10과 C++0x

마술감자 — Fri, 23 Apr 2010 17:03:01 +0900

원본 : http://lolisia.tistory.com/124

VC2010은 이미 정식출시, 편한게 많아보인다.

pdf는 한글이니까 보는데 오래 안걸림.

PDF : http://download.microsoft.com/download/1/9/4/194B6F74-8A72-482D-AF0E-31CE9D855372/VisualC.PDF

0. 서두

0.1 C++의 문제점

0.2 C++는 시대에 뒤 떨어진 프로그래밍 언어 일까요?

1. C++0x에 대해서

1.1 C++의 새로운 표준 C++0x

1.2 Visual C++의 이전 버전과의 호환성

1.3 Visual C++ 9와 Visual C++ 10

2. auto

2.1 정적 언어와 동적 언어의 차이

2.2 C#의 var

2.3 C++에서 STL(표준 템플릿 라이브러리)를 사용할 때 불편한 점

2.4 컴파일 타임 때 타입을 정하는 'auto'

2.5 auto를 사용한 예제

2.5.1 지역 변수로 사용

2.5.2 클래스 정의에 사용

2.5.3 STL에서 사용

2.6 핵심 요약

3. static_assert

3.1 assert와 #error

3.2 assert와 #error를 사용할 수 없을 때

3.3 static_assert의 형식

3.4 static_assert 사용예

3.4.1 프리프로세스 지시어 대체

3.4.2 템플릿에서 사용

3.4.3 변수의 크기 조사

3.5 핵심요약

4. 우측값참조(RValue Reference)

4.1 C++98/03에서의 실수

4.2 좌측 값(LValue)과 우측 값(RValue)

4.3 좌측 값 참조와 우측 값 참조

4.4 Move semantics

4.5 Move 생성자와 Move 대입연산자

4.6 Move semantics에 의한 성능 향상

4.7 move 생성자와 move 대입연산자 사용 예

4.8 std::move

4.9 VC 10에서의 STL과 우측 값 참조

4.10 우측 값 참조를 사용할 때 주의할 점

4.11 우측 값 참조와 좌측 값 참조의 함수 오버로드

4.12 우측 값 참조는 우측 값이 아니다

4.13 Perfect Forwarding

4.14 핵심요약

5. 람다(lambda)

5.1 C#과 람다

5.2 C++에서 STL 알고리즘을 사용할 때 불편했던 점

5.3 C++에서의 람다 사용법

5.3.1 문법

5.3.2 람다를 변수에 대입

5.3.3 람다를 함수의 인자로 사용하기

5.3.4 람다의 파라미터

5.3.5 반환 값 넘기기

5.4 캡쳐

5.5 클래스에서 람다 사용

5.6 STL의 find_if에서 람다 사용

5.7 람다 식을 STL 컨테이너에 저장

5.8 람다를 반환하 는함수

5.9 람다에서의 재귀

5.10 핵심요약

6. decltype

6.1 템플릿 프로그래밍 시 문제

6.2 decltype 사용하기

7. nullptr

7.1 nullptr이 필요한 이유

7.2 nullptr 구현 안

7.3 nullptr 사용 방법

7.4 nullptr의 올바른 사용과 틀린 사용예

8. 참고

=팁/플래시AS= 무비클립 계층구조 동적생성시 염두해 두어야 하는 것

마술감자 — Wed, 07 Apr 2010 06:21:15 +0900

팁1) 계층구조에서의 키 프레임과 액션스크립트 처리에 대한 고려사항

스케일폼을 이용해서 게임UI를 플래시와 연동할 경우 무비클립에 대한 동적생성이 필요할 때가 있는데,
이때 타임라인의 키 프레임이 어떻게 처리되는지를 이해해야 할 필요가 있다.

예시를 설명하면서 살짝 이해해보자.

게임UI를 플래시로 구현할 경우 각 다이얼로그의 시스템 버튼같은것들에 대해서
노가다를 피하기 위해 동적생성을 한다고 해보자.

예시로 드려는 구조는 다음과 같다.

MainStage - ControlContainer - TheControl

MainStage	플래시 최상위 스테이지
ControlContainer	임의의 게임UI 윈도우 (환경설정창, 친구목록창 등이 될 수 있다)
TheControl	시스템 버튼 (예시)

플래시의 타임라인의 키 프레임에 대한 이해가 필요한데,
키 프레임에 액션스크립트 요소를 고려해서 생각할 때 다음과 같은 방식으로 작동할 것이다.

1.0) 해당 키 프레임을 화면에 보여줄 때가 되어서 키프레임 처리 프로세스 진입
1.1) 해당 키 프레임의 액션스크립트를 처리
1.2) 해당 키 프레임의 인스턴스들을 화면에 출력

무비클립을 계층구조로 동적생성하는 비 추천 구조는 다음과 같다.

MainStage의 1번 키 프레임에서 ControlContainer를 동적생성
ControlContainer의 1번 키 프레임에서 TheControl을 동적생성

액션 스크립트의 실행 순서는 다음과 같이 된다.

Stage-1.0 > Stage-1.1 > Stage-1.2 > Container-1.0 > Container-1.1 > Container-1.2 > TheControl-1.0 > TheControl-1.2

위와 같은 형태로 각 무비클립의 첫 키프레임에 액션스크립트를 삽입할 경우, 각 스크립트에서는 '동적생성'만 할 수 있다.
예를들어 Stage-2.1 과정에서는 Container.TheControlA 가 생성된 상태가 아니기 때문에 속성을 설정하거나 얻을 수 없다.

플래시는 액션스크립트를 두가지 방식으로 작성할 수 있다. (얼핏 3가지였던걸로 기억하는데 아닌가?)

2.1) 스테이지, 무비클립별 타임라인
2.2) 외부 스크립트, 무비클립 심볼에 대응되는 클래스 스크립트[심볼이름.as 스크립트 파일 (SymbolProperties-Linkage-Class)]

이런 상황에서는 2.1 방식을 사용할 경우 동적생성 키프레임과 세팅하는 키 프레임을 나눠주어야 한다.
2.2를 사용할 경우 무비클립이 모두 로드되는 시점에 생성과 값설정을 몰아서 할수 있을것 같다. (안해봤음)

팁2) 다수의 UI를 관리하는 구조에 대하여

스케일폼이 2010년 후반기에 액션스크립트 3.0을 지원한다고 하는데,
당분간 게임업계 종사자들은 액션스크립트 2.0기반으로 작업을 할것 같다.

게임UI가 상당히 많아서 각 UI프로그래머가 이것을 어떻게 관리할지는 회사마다 다를것 같은데,

나는 createEmptyMovieClip() 과 loadMovie()의 조합을 권장한다. (더 좋은게 있는지 찾아보지는 않았음)

여러개의 fla로 UI를 개발했다면, attachMovie를 이용할 경우 취합하는 fla의 스테이지의 안보이는 영역에 모든 서브 컨트롤을 끌어 놓아야 하기 때문이다.
이것들은 게임 구동시 중복 인스턴스가 될 것이고, 유지보수를 하는데 불편하지 않나 싶다.

* 계층적 fla별 액션스크립트를 구현할 경우 lockroot 속성에 대해 알고 있어야 한다. (rootlock였나 -_- ㅈㅅ)

위 2가지 문제는 모두 액토즈소프트의 주정현님의 도움으로 해결했습니다.
형 고마워!

=사설= "그들에게 1+1은 2가 아니다" - 당신의 true는 어째서 그들에게 true가 아닌가, 개발철학과 시야에 대한 이야기 (ver2)

administrator — Wed, 24 Mar 2010 05:22:46 +0900

2010.03.29. ver2 명국진(http://magicpotato.com)

2010.03.24. ver1
2010.02.06. 초안

0. 들어가기
1. 준비하기 : 우리는 모두 사람-남으로부터 배운다.
2. 준비하기 : 우리는 어떤 사람으로부터 어떤 것을 배우는가?
3. 개발철학
4. 기술 오남용
5. 시야, 당신의 true가 그들에게 true가 될 수 없는 이유

0. 들어가기

이 글은 빈번하게 다른 사람들과 부딛히는데, 이유를 명확히 알지 못하겠는 프로그래머를 위한 글이다.

이런 프로그래머들은 주로 단방향 형태의 매체를 이용하여 숙련된 프로그래머들이다.
자신의 지식이 참이라는것에 자신을 갖고있고, 두려움이 없다.

또한, 자신이 일을 잘 하고 있다고 확신한다.

나는 이 글이 정말 자신이 일을 잘 하고있는지 재 확인하고 자신감을 갖거나, 생각을 고치는 계기가 되는 글이었으면 한다.

나는 이 글에서 2가지를 말하고자 한다.

프로그래머들의 충돌은 개발철학과 시야에 있다고 생각한다.

1) 개발철학
2) 시야

1. 준비하기 : 우리는 모두 남=사람으로부터 배운다.

우선, 우리가 알고 있는것이 정말 true인지 다시 생각해야 할 필요가 있다.

사람은 기본적으로 감정이 있으며 오류를 일으킬 수 있는 존재이며,
개개인별로 개발철학과 국가의 문화, 소속된 집단과 개발환경이 모두 다르다.

50여명의 학생들이 귓속말로 내용전달을 하는것을 기억해보자.
사람은 불완전한 존재이다.

무언가 물어봤을때 자존심때문에 모르는것을 안다고 할수도 있고,
돈받고 파는 책일지라도 귀찮고 졸려서 날려쓴 부분이 있을 수 있다.

텍스트를 맹신하는 사람들이 있다.
그것 또한 사람이 쓴 것이며 당신이 읽는 이 글 또한 사람이 쓰고 있다.

우리가 배운것의 출처는 불완전한 존재이며 절대 완전무결 할 수 없다.

2. 준비하기 : 우리는 어떤 사람으로부터 어떤 것을 배우는가?

프로그래머가 처음 읽는 사소한 C++입문서 한권도 그에게 큰 영향을 미친다.
코딩 습관과 개발 철학 또는 인생.

'코딩습관' 과 '개발철학' 이라는 각각의 네글자를 너무 쉽게 지나치는 사람들이 없기를 바란다.
개발철학, 그들의 개발문화, 그가 속한 개발환경을 항상 염두해 둬야 한다.

다음들을 보고 하나하나의 항목에 대해서 생각을 해보자.

- NASA처럼 수천명의 프로그래머들이 하나의 프로젝트를 진행하는 환경에서 나온 경험으로 쓴 책
- 한번 릴리즈되면 되돌이킬 수 없는 카트리지 기반의 가정용 게임기 개발자가 속한 개발 환경
- GNU정신을 너무 좋아해 GNU티셔츠를 입고 쓴 윈도우 프로그래밍 책
- DOS시절부터 어셈블러와 C를 이용해 20년간 프로그래밍을 하다 교수가 된 사람의 책
- 유명 대형 게임회사에 처음 입사해서 10년간 몸담고 아직도 실무로 뛰고있는 프로그래머의 책
- 엑셀을 만드는 팀의 프로그래머가 쓴 책

생각하기 쉽도록 과장되게 적어보았다.

우리는 이것을 책의 맨 첫 페이지에 있는 '저자약력'을 통해 어느정도 짐작할 수 있다.
당신이 습득한 특정 환경에 종속되어있던 그 지식은 지금 당신이 속한 환경에 정말 적합한 지식인가?

3. 개발철학

단원 1과 2를 통해 나는 우리가 알고있는 정보들이 우리의 개발환경에 맞지 않거나
적절치 못한 개발철학을 주입당했거나, 틀렸을 수 있으며, 우리는 불완전 할 수 있다는 것을 전달하고자 한다.

개발자들은 자신이 옳다고 믿는것을 행할때 어떠한 기준-개발철학을 갖고 행동해야 하는데,

이번 단원을 통해 그 개발철학을 재 점검하고, 당신의 조직의 목표와 당신이 가진 꿈을 적절히 타협한 맞춤형 개발철학을 새로 세울수 있길 바란다.

'철학을 어떤 기준으로 세워야 하는가'를 말하기 보다는 3단원과 4단원을 통해 구체적으로 나는 어떤 이유에 의해 내 개발철학이 이렇다는것을 설명하고자 한다.

추상적이고 이론적인 이야기를 해봤자 자기가 아는 범위 내에서밖에 생각을 하지 못하고 입맛에 맞게 바꿔서 듣기 때문이다.

같은 이야기를 해도 다르게 듣는것을 방지하기 위해서 실제로 나 개인의 환경을 전제시키고, 실 사례로 예시를 들면 더 이해가 빠를것이다.

3단원에서 나의 개발철학을 설명하고, 4단원에서 그것을 기반으로 실제로 어떻게 행동하는지 설명하겠다.

[내 개발철학]

어딘가에 소속되어 월급을 받는 프로그래머는 회사가 돈을 버는데 초점을 두고 일해야 한다.
나는 급여를 받고 그에 책임을 지는 프로그래머를 프로라 정의하며,
내가 맡은 업무 영역에서 코딩방식이나 설계등의 선택을 해야 할때
최우선적으로 회사라는 이익집단에 도움이 되는 선택을 한다.

개인의 기술개발, 호기심에 의한 시험, 스스로 보기에 부끄럽지 않고 객체지향의 원칙을 모두 지키고
중복이 하나도 없는 남을 보여줘도 부끄럽지 않고 완벽한 코드 구현은 절대 악이다.

내 개발 최우선 원칙은 최소비용 개발이다.

1) 정말 필요한 것만 해야한다.
2) 내 업무로 인해 동료의 노동력을 낭비시켜서는 안된다.
3) 내 업무의 딜레이로 인해 동료가 그에 종속된 일을 하지 못하게 해서는 안된다.

정말 필요한것만 하면서 동료의 노동력을 낭비시키지 않기 위해 다음과 같이 한다.

1) 코드를 쉽게 짠다 - 분석비용을 낮추기 위해 디자인패턴, 템플릿을 사용하지 않는다.
2) 모든 코드를 플랫폼/프로젝트 종속적으로 짠다. 확장성을 생각하지 않는다.

3) 어떤것(코딩기법/기술/툴)을 사용하는것에는 분명한 이유가 필요하며, 그것을 사용/적용할 때 기대한 결과를 객관적으로 얻을 수 없으면 그만둬야 한다.

4. 기술 오남용 - 철학과 관련된 세부 내용 (외전)

나의 true는 이렇다. 당신의 true와 비교해 보자.

기술을 오남용 하는데 여러가지 이유가 있겠지만 내가 생각하기에 가장 큰 이유는 자기 자랑이다.
고의적이든, 본능에 의해 자기도 모르는사이에 그렇게 하는것이든 자신의 가치를 인정받기 위해, 자신의 실력을 과시하기 위한것. 그 이유가 가장 크다.

know-where를 알지 못하면 테크니션을 벗어날 수 없다.

4단원에서 다룰 몇가지 이슈는 다음과 같은것들이 있는데, 이 항목들은 모두 나의 3.개발철학에 종속되는 이슈들이다.

2단원에서 언급했던 '환경'을 염두해두고 봐야 한다.

1) 익스트림 프로그래밍의 페어프로그래밍은 환상이다.
2) 코드의 확장성을 정말 고려해야 하는가?
3) OOP는 정말 옳은가?
4) 하드코딩은 정말 나쁜가?
5) namespace
6) 1class당 1file
7) boost와 메타프로그래밍
8) 템플릿
9) 디자인 패턴

누군가 또는 책을 통해 어떤 기술을 소개할때 '단점'을 이야기 하는 책은 거의 없다.
각자의 환경에 정말 맞는 것인지 스스로 생각하고 걸러내지 않으면 안된다.

1) 익스트림 프로그래밍의 페어프로그래밍은 환상이다.

익스트림 프로그래밍은 절대 익스트림하지 않다.

한 코드를 두명이 붙잡고 의견을 교환하는건 프로젝트 초기에 단기적으로만 필요하다.
커밋 전에 관계가 전혀 없는 사람과 코드리뷰를 하는쪽이 훨씬 집중도 잘되고 이득이다.

익스트림에서 소개하는 정통 페어프로그래밍은 우리나라 문화에 절대 맞지 않는다.
페어프로그래밍은 그것을 할 수 있는 능력을 갖춘 사람들이 필요한 때(코드커밋 전을 권장)만 해야한다.

2) 코드의 확장성을 정말 고려해야 하는가?

나는 경험이 없는 영역에 대해 예측하지 않는다. 확장성을 고려하지 않는다.
그리고 절대로 멀티플랫폼을 고려하지 않는다. 우리회사는 절대로 온라인 게임만 만드므로.

경험해 보지도 못한 영역을 열심히 고민해서 코딩해놓고, 그 코드를 수정하지 않고
그대로 이어서 깔끔하게 사용해본 경험이 얼마나 되는가?
미지의 영역에 대해 미리 예측해 놓은 모든 코드를 프로젝트 완료하는 시점에 모두 연결했는가?

어떤 코드를 수정하면서 "확장성 있게 작성해 놨더라면, 지금 이걸 안하고 있어도 될텐데"라고 생각할 것이다.

아무것도 없는 상태에서 예상할 수 있는 코드는 지금 수정하고 있는 내용이 포함되지 않을 수도 있다.

지역적인 코드를 수정하는것은 오히려 문제가 명확해 진 상태에서 이루어지기 때문에 전체적인 비용이 낭비되지 않는다.

3) OOP는 정말 옳은가?

나를 만족시키는 완벽한 OOP는 게임기획서가 더이상 수정되지 않을 정도로 굳어지고,
정식 서비스와 해외서비스를 통해 검증된 다음 돈을 벌고 내 계좌로 인센티브가 들어오는 시점에 완성된다.

일반적으로 엔진 설계를 하지 않는 한 3단계 이상의 상속과 2클래스를 넘기는 다중상속은
코드 분석비용이 엄청나게 올라간다.

겨우 2개, 3개의 케이스가 나온 상태에서 코드중복 없앤다고 구체화된 구조를 만드는것은 시기상조다.
수정작업이 반드시 생길것이다. 본인의 경험에 있는 과거를 생각해보자.

왜 OOP를 만족해야 하는가부터 생각해야 한다.
쉽고 빠르게 게임을 만드는게 중요한가? 나를 만족하기 위한 코드가 중요한가?

이게 무슨헛소리야 라고 의문을 갖는다면 당신은 아마 OOP를 쓰지 않고 게임을 만들었을때의 고속개발을 경험해 본적이 없을것이다.

4) 하드코딩은 정말 나쁜가?

이것은 매 순간마다 작성하는 대상 코드의 성격마다 다르다.
단윈 5의 시야에서 하드코딩이 필요한 경우를 설명한다.

5) namespace

당신은 라이브러리 프로그래머인가?
당신이 코딩할 클래스 이름과 함수이름이 언젠가 붙일 라이브러리의 이름과 정말 겹칠까?
정말 겹친다면, 그 겹치는 라이브러리를 과연 동시에 2개를 사용할까?

혹시 멀티플랫폼에서 플랫폼별로 서로 다른 파일/소켓/오디오/렌더링 라이브러리를 사용하는가?

나는 윈도우 환경에서 게임브리오를 사용하고, winsock을 이용해 직접 짠 tcp, udp를 사용한다.
자료구조는 STL의 string, vector, map, list만 사용하며 다른것을 사용하지 않는다.

std::string이라고 적지 않아도 우리팀 모든이가 STL임을 아는데 왜 std::를 항상 붙이는가?
언젠가 super_library::string같은 것을 혼용으로 쓸 생각이 있는가?

.NET이 네임스페이스로 라이브러리를 카테고리화 한게 멋있는가?
.NET은 내가 최소 2년간 묶여있을 'IPv4 TCP,UDP, Win32 filesystem'환경만 고려하고 만든게 아니다.

'언젠가' '만약'이라는 이유로 코딩을 하는것은 전혀 생산적이지 않다.

6) 1class당 1file

어떤 기능집단에 대해서, 하나의 문서 또는 하나의 헤더파일만 보고
그 기능집단 요소간 협력구조(종속, 상속관계 등)를 파악할 수 있다면 분석비용이 낮은것이다.

클래스 하나를 어떻게 짰는지가 중요한게 아니라,
구조체나 클래스들이 서로 어떤 구조로 협력되는지를 아는것이 더 중요하다.

보통 코드분석은 다음과 같이 이루어진다.

1. 설계구조 파악
2. 클래스별 공개 인터페이스 파악
3. 클래스별 내부구현 (멤버와 private함수) 파악

자바에서 하니까, 남들이 하니까, 파일이 너무 크니까, 내가 그렇게 해 왔으니까라는 이유로
모든 클래스를 1개당 1개 파일로 매칭시키는것은 분석비용을 증가시킨다.

이렇게 일을 하는것은 동료의 업무량을 늘리는 것이다.

7) boost와 메타프로그래밍

일단 부스트의 기능은 개인적으로 너무너무 좋아하지만,
기능을 조금이라도 잘못쓰면 그것을 수정하거나 디버깅하는 비용이 너무 크다.

표준 라이브러리라고 해서 절대로 코드를 잘 짰다고 생각하면 안된다.
마소에서 짠건데, 국제적으로 공인받는 사람이 짠건데 욕하면 내가 실력없는 거겠지?
라고 절대 생각해서는 안된다.
지저분하게 짠건 분명 지저분하게 짠거다.

일반 CRT나 STL, boost같은 코드는 코드의 가독성이나 코드리뷰어를 절대 배려하지 않은
코딩철학도 80년대 수준인 이기적인 코드들이다.

제품을 돈받고 서비스하다가 새벽2~3시에 문제가 생기면 제정신일것 같은가?
그 제정신이 아닐때 부스트같은 코드를 들여다보고 있으면 어떨것 같은가?
눈감고 그 상황을 생각해보자.

짜증이 나는건 절대 사소하지 않다.

8) 템플릿

템플릿은 쓰지 말아야 한다.

사실 '정말 필요한 경우가 아니면 쓰지 말아야 한다'라고 말하고 싶지만,
이렇게 말하면 대부분은 정말 필요하지 않은데 사용하기 때문이다.

템플릿.. 쓸때는 깔끔하고 기분이 좋은데, 나중에 다시 쳐다보면 분석비용이 너무 높다.
특히 템플릿템플릿, 단위전략같은 기법은 학술적 차원에서 기분전환용으로 한번 보고 말아야 하는 것들이다.

컴파일타임에 뭐가 되서 좋다는 소리에 현혹되지 말자.
대부분은 가상함수 좀 쓰고, 클래스 통째로 복사해서 붙여넣기 하는게 훨씬 낫다.
가상함수의 성능이 걱정된다면 최적화 전략에 대해 따로 공부하기 바란다.

복사된 두개의 클래스를 고칠때마다 '이걸 어떻게 합칠수 없을까...'라는 생각이 들 것이다.
그것을 합치면 지옥문이 열린다.

9) 디자인 패턴

패턴책을 처음 볼때 왜 패턴이 좋은지 예시로 든 구문이 생각난다.

"님 이 코드는 뭐져?"
"xxx패턴을 찾아보세여"

커뮤니케이션을 단축시킨다는 차원에서 설명한 내용인데, 과장하면 다음과 같이 된다.

"님 이 코드는 뭐져?"
"아인슈타인의 상대성 이론을 보시면 이해가 되는 코드입니다."

디자인패턴의 개념이 나쁜게 아니라, 그 개개별 패턴이 대부분 복잡한 구현법을 갖는다.
게임프로그래밍을 할때 쓸만한 디자인패턴은 하나도 없다.

"하나의 인스턴스가 보장되므로"
싱글턴은 재앙의 시작이다.

싱글턴을 사용하는 대상 클래스들은 대부분 어떤 매니저이다.
파일매니저, 사운드매니저, 렌더러 등등..

이런것들은 모두 CApplication::Initialize() 같은 함수에 몰아져 있다.
이런 매니저를 실수로 중복 생성하는 일은 극히 드물다.

게다가 이런 매니저급 클래스들은 생성 순서가 보장되어야 하는데

싱글턴의 단 하나 이점인 '하나의 인스턴스 보장'을 위해 부속 코드가 엄청나게 딸려온다.

CApplication에 매니저급 클래스들을 다 때려박으면
g_App.FileMgr, g_App.SoundMgr 식으로 접근하면 된다.
해당 클래스의 인스턴스 관리도 어디서 하는지 분명하고, 코드 분석비용도 내려간다.

싱글턴을 쓰는것은 안해도 되는 일을 만들어서 하는것이다

비지터정도면 힘든 패턴이라고 말할 수 있다.
Functor를 사용하는 Traverse를 사용하면 똑같은걸 할 수 있는데 왜 어려운걸 사용하는가?

-마무리

배웠기 때문에, 어딘가에 써먹으려고 안달해서는 안된다.

대부분 무언가 가르치는 책은 절대 객관적이지 않기 때문에. 장점과 단점도 그 저자의 시야에서만 본 것이기 때문에.

테크닉을 많이 알지만, 절제할 줄 알고 누군가 그것을 잘못 남용할때 지적해 줄 수 있는 사람이 되어야 한다.

5. 시야, 당신의 true가 그들에게 true가 될 수 없는 이유

프로그래머들은 자기들 입장에서 정직하고 원칙대로 일한다.

몇가지 책들이 소프트웨어 개발을 이해하지 못하는 관리자나 외부팀에 대한
불신과 저항에 초점을 맞추고 있는데, 이런것들이 개발자를 더 무능력하게 만드는 것 같다.

그들은 소프트웨어 개발을 이해하고 있지 못하는것이 맞지만,
우리 또한 그들을 이해하고 있지 못하다.

경력이 적은 개발자들의 시야는 오직 프로그래밍적인 구현에 집중되어있다.
프로그래머뿐만 아니라, 게임을 만드는데 관련된 모든사람은 서로의 입장을 알아야 한다.

우리는 모든 기능이 순차적으로 구현되어야 한다는 생각을 버려야 한다.
기획자나 디자이너는 순서를 건너뛴 어떤것을 먼저 봐야만 다음 일을 진행할 수 있는 경우가 있다.

돈을 벌어본 퍼블리셔의 사업팀은 일반적으로 기획자보다 '대중'이 원하는것이 무엇인지 잘 안다.
개발자들이 보기에 말도 안되는 가격으로 유료화 정책을 세워도 잘 팔린다.

어떤 기능에 버그가 있어서 고치고 있는데, 몇일 후에 외부사람들이 와서 구경할거니까
일단 다른 기능부터 만들어달라고 하면 프로그래머는 짜증이 난다.
"버그가 안된 상태로 프로그램을 보여주는건 원칙이 아닙니다. 안됩니다" 말해서는 안된다.
그 외부 사람들은 당신의 월급을 주는 사람일 수 있다.
이럴때 하드코딩을 하자.

서비스 경력이 오래된 프로그래머들은 매 구현마다 방법을 선택하는데 있어서 매우 보수적이다.
그것이 효율적이지 않더라도 한번 검증된 방법이라면 그것을 택한다.

검증되었다는것은 서비스를 한번 마치고 돈까지 벌어본 코드를 의미한다.
어떤 예외에도 대처가 된 코드이며 일정에 가변적인 영향을 미치지 않는다.

게임을 완성하기까지 그 '구현'이라는것이 엄청나게 많다.

상당히 많은 개개의 기능들이 유기적으로 작동하는것이 게임인데,
그중 부분적인 기능에 새로운 구현을 적용할 경우 연동되는것에도 사이드 이펙트를 미칠 수 있다.

이미 검증된 구현으로 게임을 구현할 경우 어떠한 문제가 생기면
대부분의 경우 그것은 실수로 빠뜨렸기 때문인 것일뿐, 고려를 안해서 발생한것이 아니다.
실수로 빠뜨린것은 코드수준의 실수이며, 고려를 안한것은 설계상의 실수가 된다.

설계에러는 코드수준의 에러보다 훨씬 심각하고 리스크가 크다.

게임회사를 다니는 모든 사람이 당신만큼 일을 사랑한다고 생각해서는 안된다.
그들은 자신의 생활과 가정이 있고, 퇴근후에 친구를 만나야 하고, 애인과 데이트를 해야한다.
어영부영 살다가 '그냥' 회사를 다니는 사람도 있다.

프로그래머들은 아닌것은 아니라고 이야기 한다.

하지만 그들은 말해서 상대의 기분이 상하거나, 자신의 적을 만들게 되거나,
말해도 고쳐지지 않고 상황만 나빠지는 진실은 이야기 하지 않는다.

그들은 자신의 목이 중요하지, 옳고 그름이나 프로젝트가 더 중요한건 아니기 때문이다.

당신이 함께 일하는 그들은 감정과 자존심, 부양해야할 가족을 가진 직위와 연봉을 지켜야 하는 사람이다.

당신의 true는 그들에게 true가 아니다.

=날림팁/유틸= 간단히 윈도우 플랫폼에 SVN 서버 설치, 설정하는 법 (svn:// 주소로, 아파치 httpd 무관)

마술감자 — Sun, 07 Mar 2010 23:03:50 +0900

VisualSVN은 뭔가 나랑 안맞는것 같아...
기본적으로 svn 클라이언트를 사용해 보고 저장소의 개념이 있는 사용자를 위한 메모.

1. 다운받기

아파치 버전은 전혀 상관 없기때문에 아무거나 받으면 된다.

- http://subversion.apache.org/packages.html : 플랫폼별 URL
- http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100 : 아파치 2.2.x호환

- Setup-Subversion-1.5.6.msi 같은걸 하나 받고 막 설치한다.

2. 저장소 만들기

저장소는 아무데나 만들어도 되며, svnserv.exe 실행시 경로를 지정할 수 있다. Subversion을 설치하면 이미 클라이언트와 서버가 모두 설치된 상태이며,
이것들을 어느 경로에서나 사용할 수 있도록 PATH설정까지 완료된 상태이다.

2.1) 저장소를 위한 빈 폴더를 생성.

d:\svn_rep01

2.2) 저장소의 조건을 갖추는 폴더트리를 생성.

svnadmin create d:\svn_rep01

3. SVN 서버 실행 및 저장소 지정

3.way1) 서버실행법 : 서버주소(또는 ip)에 곧바로 저장소를 연결할 경우

svnserv -d -r d:\svn_rep01
> 저장소 주소는 svn://localhost/ 가 된다.

3.way2) 서버실행법 : 서버주소(또는 ip)에 저장소를 연결할 경우

svnserv -d -r d:\
> 저장소 주소는 svn://localhost/svn_rep01 이 된다.

* 서비스 등록방법

sc create SVN-SERVER binPath= "[svnpath]\svnserv --service -r d:\svn_rep01"

> binPath= 와 " 사이에 반드시 공백을 넣어줘야 한다.

4. 권한 설정

각 저장소의 conf 폴더마다 3개의 파일이 있는데, 이것으로 id/pass, 폴더별 권한을 설정한다.
d:\svn_rep01\conf\밑의 3개 파일을 메모장으로 직접 열어서 살펴보면 어떻게 하는지 다 나와있다.

끝.

=팁/문서화= 슈도코드로 시퀀스 다이어그램을 그려주는 사이트 (코드로 비지오 퀄리티 출력)

마술감자 — Fri, 26 Feb 2010 11:40:41 +0900

아 존내짱

2009년 3월 26일에 알고 지금 알려준 이근영은 반성하라

오늘 버스 돌아줘야함

이렇게 코드를 넣고 돌리면

alt 동일한 작업에 대한 병렬 처리
    ThreadManager->Thread: 생성 요청
    note right of Thread: Thread 생성
    note right of Thread: Thread 작업 완료
    Thread-->ThreadManager: 종료 대기
else 별도의 작업에 대한 이벤트 드리븐 처리
    ThreadManager->Thread: 생성 요청
    note right of Thread: Thread생성
    note right of Thread: Thread Event 발생
    Thread-->ThreadManager: Callback Function 호출
end

이렇게 나옴

흐어 ㅜ.ㅜ

링크 : http://www.websequencediagrams.com

=도서/목차= Mastering Unreal Technology TOC (Volume1~3) 전권목차

마술감자 — Tue, 23 Feb 2010 10:51:47 +0900

Volume1 : A Beginners Guide to Level Design in Unreal Engine 3

CHAPTER 1: Introduction to Unreal Technology . . . 1

History of Unreal . . . 2

June 1998: Unreal . . . 2

November 1999: Unreal Tournament . . . 3

March—July 2001: The Unreal Developer Network . . . 5

September 2002: Unreal Championship and Unreal Tournament 2003. . . 5

February 2003: Unreal II . . . 7

March 2004: Unreal Tournament 2004 . . . 9

April 2005: Unreal Championship 2: The Liandri Conflict . . . 10

November 2006: Gears of War. . . 11

November 2007: Unreal Tournament 3 . . . 12

Overview of the Unreal Engine. . . 14

Unreal Engine Components . . . 14

The Graphics Engine. . . 14

The Sound Engine. . . 15

The Physics Engine . . . 16

The Input Manager . . . 16

Network Infrastructure . . . 17

The UnrealScript Interpreter. . . 18

Overview of Component Interaction . . . 18

Engine Components at Work . . . 20

Creating Your Own Worlds with the Unreal Engine . . . 21

Game Assets . . . 21

Animations and Skeletal Meshes . . . 25

The Tools of the Trade . . . 26

CHAPTER 2: Overview of Game Development. . . 31

The Importance of Iteration . . . 32

Start with the Idea . . . 32

Story Treatment . . . 34

Considerations for Production Scheduling . . . 39

Communication . . . 41

Have Regular Meetings . . . 41

Make Yourself Heard. . . . 41

Respect Your Teammates . . . 41

Artists Versus Programmers: Round One, Fight! . . . 42

Pick Your Battles . . . 42

Stay Creative . . . 42

Testing and Feedback . . . 43

Ending Production . . . 44

CHAPTER 3: Up and Running: A Hands-On Level Creation Primer. . . 45

Starting Your First Level . . . 46

CHAPTER 4: A Universe of Brushes: World Geometry In-Depth . . . 117

Key Terms and Concepts: BSP and CSG . . . 117

Brush Types . . . 118

The Red Builder Brush. . . 118

Additive Brushes . . . 118

Subtractive Brushes . . . 120

A Quick Word on Building. . . 120

Cleaning BSP Materials . . . 21

Working with Brushes . . . 124

Additive and Subtractive Levels. . . 124

The Almighty Drag Grid . . . 124

Moving with Pivots . . . 125

Brush Order . . . 125

Building to the Proper Scale . . . 126

Primitives . . . 127

Cube . . . 127

Cone . . . 128

Cylinder . . . 128

Sheet . . . 130

Tetrahedron (Sphere) . . . 130

Curved Staircase . . . 130

Linear Staircase . . . 132

Spiral Staircase . . . 132

Volumetric . . . 133

Boolean Operations . . . 134

Intersect Tool. . . 134

De-Intersect Tool . . . 135

Brush Solidity. . . 135

Solid . . . 136

Semi-Solid. . . 136

Non-Solid . . . 136

Brush Manipulation . . . 137

Geometry Mode . . . 137

Selection Modes . . . 138

Toggle Modifier Window . . . 141

Working with Shadows. . . 164

CHAPTER 5: Static Meshes. . . 169

The Importance of Static Meshes. . . 169

Static Mesh Workflow Overview . . . 170

UV Texture Coordinates . . . 185

Considerations When Creating UV Layouts . . . 193

Creating Textures . . . 195

Importing Static Meshes. . . 197

Using the Static Mesh Editor . . . 200

Collisions . . . 202

Creating Custom Collisions. . . 205

Placing Static Meshes. . . 213

Static Meshes and Shadows. . . 216

CHAPTER 6: Introduction to Materials. . . 221

What Is a Material? . . . 222

Materials vs. Textures. . . . . 223

Texture Coordinates (UVs). . . . 223

Material Instructions. . . 224

Thinking About Color in Unreal. . . 225

A Quick Word on Lighting. . . 226

Anatomy of a Material . . . 226

Material Nodes . . . 227

Material Channels . . . 232

Material Expressions. . . 239

The Available Material Expressions. . . 244

Material Expressions List. . . 244

Parameter Expressions. . . 262

Material Creation. . . 264

Surface Properties . . . 274

The Surface Properties Dialog. . . 275

CHAPTER 7: Introduction to Lighting . . . 357

Light Placement. . . . 358

A Word on Building Lights. . . 358

Lighting Concepts . . . 375

Light Maps and Shadow Maps. . . 375

Static and Dynamic Lighting . . . 376

Per-Vertex Lighting and Lighting Subdivisions. . . 377

Types of Lights. . . 378

Toggleable Lights. . . 378

Moveable Lights . . . 378

Point Lights. . . 379

Spotlights . . . 380

Directional Lights. . . . 382

SkyLights. . . 382

Pickup Lights. . . 384

Light Properties . . . 387

General Properties. . . 387

Exclusive SpotLight Properties. . . 389

Exclusive DirectionalLight Properties. . . 389

Exclusive SkyLight Properties . . . 389

Lighting Channels . . . 390

Lighting Volumes . . . 394

Shadows . . . . . 394

Precomputed Shadows (Shadow Maps). . . . 395

Shadow Buffer Shadows . . . 396

Shadow Volume Shadows . . . 396

Shadow Modulation . . . 398

Light Environments . . . 405

Light Functions . . . 410

Workflow Tips . . . 415

CHAPTER 8: Terrain. . . 417

What Is Terrain? . . . 417

Accessing Terrain . . . 419

Terrain Anatomy and Properties . . . 427

Terrain Anatomy (Terminology) . . . 427

Terrain Properties . . . 428

TerrainMaterials and Layers . . . 433

TerrainMaterial Properties. . . 433

Terrain Layers . . . 434

Terrain Editor Dialog. . . 449

The Terrain Editing Dialog Interface Overview. . . 449

Terrain Editing Tools. . . 459

Decorating Your Terrain: Foliage and DecoLayers. . . 483

Foliage. . . 484

DecoLayers. . . 488

Terrain Workflow Considerations . . . 494

CHAPTER 9: Introduction to Unreal Kismet . . . 497

Kismet: The Big Picture. . . 497

Accessing Kismet . . . 498

Anatomy of a Sequence Object . . . 506

Types of Sequence Objects . . . 508

Events . . . 508

Actions . . . 509

Variables . . . 509

Conditions . . . 510

Matinee . . . 512

Kismet Sequence Flow . . . 512

Simple Kismet Sequences . . . 526

Commenting Kismet Sequences . . . 535

Intermediate Kismet Sequences . . . 536

CHAPTER 10: Unreal Matinee. . . 615

What Is Matinee? . . . 615

Matinee Terminology . . . 616

Accessing Matinee . . . 636

The Matinee Sequence Object . . . 636

Inputs . . . 637

Outputs. . . . 638

Variable Links . . . 638

Properties . . . 638

Matinee Data Object. . . 640

InterpActors . . . 641

Mover Kismet Event . . . 641

The Matinee Editor . . . 643

Toolbar . . . 644

Curve Editor . . . 644

Group/Track List . . . 644

Timeline . . . 645

Properties . . . 646

Types of Tracks. . . 647

Anim Control . . . 647

Color Property . . . 648

Event . . . 648

FaceFX . . . 648

Float Material Param. . . 648

Float Particle Param. . . 649

Float Property . . . 649

Morph Weight. . . 649

Movement. . . 649

SkelControl Scale . . . 650

Sound . . . 650

Effects Toggle . . . 651

Vector Material Param. . . . 651

Vector Property . . . 651

Director Group-Specific Tracks . . . 651

Matinee Considerations . . . 652

CHAPTER 11: Level Optimization . . . 705

General Optimization. . . 705

Understanding Overhead . . . 706

In-Game Performance Diagnostics . . . 706

Occlusion . . . 717

CullDistance and CullDistanceVolumes . . . 718

Levels of Detail . . . 719

Optimizing Lights and Shadows . . . 719

Light Maps . . . 719

Light Environments. . . 720

Light Functions . . . 720

Casting Light onto Unlit Materials . . . 720

The Primitive Stats Browser. . . 721

Dynamic Shadows and the Dynamic Shadow Stats Browser . . . 722

Material Optimization . . . 725

Multiple Materials per Object . . . 726

Material Instructions. . . 726

Unlit Translucency . . . 727

CHAPTER 12: Level Streaming. . . 731

Level Streaming Benefits. . . 732

Testing Level Streaming . . . 733

Streaming Methods . . . 733

Persistent Levels Versus Streaming Levels . . . 733

The Level Browser and Scene Manager . . . 734

Map Changing . . . 736

Level Streaming via Kismet. . . 757

Level Streaming via LevelStreamingVolumes. . . 758

Level Streaming via Distance. . . 767

Troubleshooting . . . 777

Level Streaming Considerations . . . 777

APPENDIX A: The Unreal Editor User’s Guide. . . 779

The Main Menubar . . . 779

The Toolbar . . . 781

File Options . . . 781

Undo and Redo . . . 782

Far Clipping Plane Distance . . . 782

Transform Tools . . . 782

Search for Actor . . . 783

Toggle Fullscreen . . . 783

Cut, Copy, and Paste . . . 783

Generic Browser . . . 783

Kismet . . . 783

Toggle Brush Polys . . . 783

Toggle Prefab Lock . . . 783

Use Curves Button . . . 783

Enable/Disable Socket Snapping. . . 783

Building . . . 784

Play Level Area . . . 784

The Toolbox . . . 785

Camera and Utilities Area . . . 785

Brush Primitives Area . . . 786

CSG Operations Area . . . 792

Additional Brushes Area . . . 793

Selections Area . . . 794

The Viewports . . . 795

Navigation . . . 796

Viewport Controls. . . 797

Viewport Toolbar . . . 798

Viewport Context Menu. . . 802

The Console Bar . . . 804

Command Line . . . 805

Selection Status . . . 805

Transform Status . . . 805

DrawScale Numeric Fields . . . 805

Drag Grid . . . 805

Rotation Grid . . . 805

Scale Grid . . . 806

AutoSave . . . 806

Browsers . . . 806

Generic Browser. . . 806

Actor Classes Browser. . . 811

Groups Browser . . . 813

Level Browser . . . 815

Referenced Assets Browser . . . 816

Primitive Stats Browser . . . 818

Dynamic Shadow Stats Browser. . . 819

Scene Manager . . . 820

Log . . . 822

Editors . . . 823

Static Mesh Editor. . . 823

Material Editor. . . 824

Kismet Visual Scripting Editor. . . 824

Matinee Editor . . . 826

PhAT (Physics Asset Tool) Physics Editor. . . 826

Cascade Particle System Editor . . . 826

User Interface Scene Editor . . . 828

SoundCue Editor . . . 828

Post Process Manager . . . 828

AnimSet Editor . . . 830

AnimTree Editor. . . 830

Search for Actors . . . 831

Property Windows . . . 832

Actor Properties . . . 832

Surface Properties . . . 833

APPENDIX B: The Curve Editor. . . 835

Animation Curves . . . 836

Controlling Interpolation Curves . . . 838

Auto . . . 839

User . . . 840

Break. . . . 840

Linear. . . 840

Constant . . . 842

Curve Editor Interface. . . 842

Curve Editor Toolbar. . . 842

Curve Editor Curve Key List. . . 844

Curve Editor Graph View . . . 846

Preset Curves . . . 847

Available Preset Curve Settings. . . 848

Index. . . 851

Volume2 : Advanced Level Design Concepts with Unreal Engine 3

CHAPTER 1: Introduction to Advanced Level Design . . . 1

Who Is This Book For? . . . 2

What Should You Know Before You Start? . . . 2

What We Mean By “Advanced” Level Design . . . 3

Included Assets and Game Assets . . . 3

Working with INI Files . . . 4

Future Software Changes . . . 5

CHAPTER 2: Advanced Material Construction . . . 7

Material Instancing and Parameters . . . 7

Blending . . . 9

UV Manipulation . . . 10

Normals . . . 11

Depth . . . 12

Special Lighting . . . 13

Reflections . . . 14

Distortion . . . 14

Transparency . . . 15

Subsurface Scattering . . . 16

Custom Lighting Models . . . 16

Summary . . . 151

CHAPTER 3: Working with Volumes . . . 153

Available Volume Types . . . 154

Basic Volume Properties . . . 156

BlockingVolumes . . . 156

PhysicsVolumes . . . 159

TriggerVolume . . . 170

PostProcessVolume . . . 186

LevelStreamingVolume . . . 188

LightVolume . . . 188

ColorScaleVolume . . . 189

ReverbVolume . . . 189

RB_ForceFieldExcludeVolume . . . 190

UTAreaNamingVolume . . . 190

UTAutoCrouchVolume . . . 190

FoliageFactory . . . 190

Summary . . . 192

CHAPTER 4: Physics Objects . . . 193

Types of Physics Objects . . . 193

The Concept of Rigid Bodies . . . 196

Working with Rigid Bodies in Unreal . . . 197

KActors . . . 200

KAssets . . . 208

Constraints . . . 211

The Physics Asset Tool (PhAT) . . . 229

Cloth . . . 245

Impulse and Force Actors . . . 252

Physics-Specific Kismet Sequence Objects . . . 258

Physical Materials . . . 263

Summary . . . 268

CHAPTER 5: Creating Special Effects with Particle Systems . . . 269

Anatomy of a Particle System . . . 271

TypeData Modules . . . 283

Modules . . . 286

Cascade Particle System Editor . . . 293

Particle-Specific Material Expressions . . . 301

Types of Particle Modules . . . 312

Beam Emitters . . . 356

Mesh Emitters . . . 374

Trail Emitters . . . 382

Fluid Emitters . . . 393

Levels of Detail . . . 397

Emitter Actor . . . 406

Modifying Particle Systems In-Game . . . 407

Troubleshooting the Effect . . . 480

Summary . . . 481

CHAPTER 6: Creating User Interfaces . . . 483

UI Components . . . 483

UIs Versus HUDs . . . 484

UI Design Workflow Overview . . . 485

The UI Scene Editor . . . 492

The UI Widgets . . . 496

Working with Widgets . . . 498

Widgets States . . . 513

Widget Navigation and the Focus Chain . . . 541

Working with User Inputs . . . 543

Data Stores . . . 548

Styles and Skins . . . 549

Fonts . . . 566

Adding Functionality . . . 569

Sounds . . . 598

Creating HUDs . . . 600

Summary . . . 601

CHAPTER 7: Sound System . . . 603

Sound Types . . . 604

USounds Versus SoundCues . . . 604

The AmbientSound Actors . . . 612

The SoundCue Editor . . . 613

SoundCue Nodes . . . 614

Kismet Sound Actions . . . 632

Working with Music . . . 638

Working with MusicTrackBanks . . . 642

Summary . . . 666

CHAPTER 8: Post-Process Effects . . . 667

The Four Key Methods of Controlling Post-Processes . . . 668

Accessing and Assigning PostProcessEffect Objects . . . 670

Types of Post-Process Effects . . . 675

Post-Process Editor . . . 681

Controlling Post-Process Effects In-Game . . . 715

Summary . . . 716

CHAPTER 9: The Unreal Animation System . . . 717

The Unreal Animation System . . . 718

Skeletal Animation . . . 723

Morph Animation . . . 734

AnimSet Editor . . . 737

Animation Blending . . . 753

AnimTree Editor . . . 754

AnimTree Editor Nodes . . . 770

Morph Nodes . . . 796

Facial Animation with FaceFX . . . 839

FaceFX Studio . . . 840

FaceFX Studio User Interface . . . 872

Physical Animation . . . 900

Setup Procedure for Physical Animation . . . 906

Skeletal Mesh Actors . . . 907

Skeletal Mesh Component . . . 907

Summary . . . 909

CHAPTER 10: Creating Cinematic Sequences . . . 911

Cinematic Sequences . . . 911

Camera Actor . . . 915

Camera Effects . . . 916

Image Separation Through Lighting . . . 920

DumpMovie Command . . . 920

Putting It All Together . . . 920

Summary . . . 999

APPENDIX A: Distributions . . . 1001

Overview . . . 1001

Distribution Types In-Depth . . . 1003

General Performance Cost Comparison . . . 1019

APPENDIX B: The Curve Editor . . . 1023

Animation Curves . . . 1024

Controlling Interpolation Curves . . . 1026

Curve Editor Interface . . . 1030

Preset Curves . . . 1035

Index . . . 1039

Volume3 : Introduction to Unrealscript with Unreal Engine 3

1. Introduction to UnrealScript

2. UnrealScript Baptism By Fire

3. Classes

4. Variables

5. Operators and Expressions

6. Functions

7. Control Statements

8. Loops

9. UnrealScript PreProcessor

10. Iterators

11. States

12. Delegates

13. Interfaces

14. Replication

Appendix A. Setting Up Your Coding Environment

Appendix B. Object Oriented Programming and UnrealScript

Appendix C. Building a Foundation in Unreal

=팁/VC++= strncpy()와 strncpy_s()에 대한 오해 + snprintf_s() VC8.0 버그 (_TRUNCATE)

마술감자 — Tue, 16 Feb 2010 13:42:32 +0900

2008.04.01.명국진(http://magicpotato.com)

strncpy()는 복사되었으면 하는 문자열의 길이를 넘어서지 않게 복사해 준다.
그리고 대상 버퍼를 넘어서게 되면 NULL로 끝나지 않는 문자열까지 복사하게 된다. 예를 들면 아래와 같다.

strncpy(dest, 8, "1234567"); // dest == { '1', '2', '3', '4', '5', '6', '7', NULL }
strncpy(dest, 8, "12345678"); // dest == { '1', '2', '3', '4', '5', '6', '7', '8' }

strncpy_s() 는 대상 버퍼가 실제 수용가능한 크기와 복사되었으면 하는 문자열의 길이 두가지를 넘긴다.
strncpy()와 strncpy_s()의 다른점이 있다면 strncpy_s()는 '복사 되었으면 하는 문자열의 길이'를 넘어서서 복사를 할 때 마지막을 항상 NULL로 끝나게 해준다는 점이다.

다음과 같은 코드는 런타임 에러를 발생시킨다.

// 이 코드는 buf에 1, 2, 3, 4, 5, 6, 7, 8, NULL .. 총 9개의 문자열을 넣으려다가 에러가 나게 된다.
char dest[8];
strncpy_s(buf, _countof(buf), "123456789000", _countof(buf));

따라서 strncpy_s()를 사용할 때는 버퍼 크기와, 복사하고 싶은 길이를 다르게 주어야 한다.

char dest[8];
strncpy_s(buf, _countof(buf), "123456789000", _countof(buf)-1);

참고.

strcpy_s()를 사용하면 버퍼 크기를 넘어서는 데이터를 넘을 때
자동으로 막아준다고 착각하는 경우가 있다. (strncpy처럼)

strcpy_s()에 넘기는 2번째 인자인 dest_size는 '내가 이 정도까지만 복사하고싶다'의 의미가 아니라
'여기 지정한 크기를 넘어서 복사하려고 하면 프로그램을 멈추고 에러창을 띄워라' 의 의미로 보아야 한다.

// 이 코드는 이쁘게 dest에 1234567까지만 복사해 주는 것이 아닌, 프로그램을 뻗게 하는 코드다.
char dest[8];
strcpy_s(dest, _countof(dest), "123456789");

연장해서 sprintf_s() 와 _snprintf_s() 에도 똑같이 적용된다.

sprintf_s(buf, _countof(buf), "%s 1234567", "1212"); // 프로그램 오류를 내는 코드
_snprintf_s(buf, _countof(buf), _countof(buf), "123456789%d", 121212); // strncpy_s()와 같은 이유로 오류를 내는 코드
_snprintf_s(buf, _countof(buf), _countof(buf)-1, "1234567%d", 121212); // 정상적으로 작동하며, 이렇게 써야 하는 코드

* gpg의 비회원님의 내용 추가 - 보충 감사드립니다.

strncpy_s(), _snprintf_s() 함수의 복사하고 싶은 길이(size_t count)에 _TRUNCATE 를 넣으면

수용가능한 버퍼 크기(size_t sizeOfBuffer)에 지정한 값 -1 을 넣은것과 같게 동작한다.

다음 두개의 코드는 결과가 같다.

strncpy_s(buf, _countof(buf), "123456789000", _countof(buf)-1);
strncpy_s(buf, _countof(buf), "123456789000", _TRUNCATE);

** _TRUNCATE와 관련한 버그 안내 (2008-04-02, VS2005 VC8.0.50727.762 - SP.050727.7600 기준)

다음 프로토타입을 갖는 함수에는 count에 _TRUNCATE를 사용해도 된다.
int _snprintf_s( char *buffer, size_t sizeOfBuffer, size_t count, const char *format [, argument] ... );

다음 프로토타입을 갖는 함수의 count에 _TRUNCATE를 사용하면 스택이 깨진다.
template <size_t> int _snprintf_s( char (&buffer)[size], size_t count, const char *format [, argument] ... ); // C++ only

템플릿버전에서는 내부적으로 매크로를 사용하고 있는데 sizeOfBuffer와 count값 두가지가 모두 -1 로 넘어가면서 코드 내부적으로 buffer[(size_t)-1] = NULL; 이라는 코드를 실행하면서 잘못된 메모리를 쓰게 된다.

** 티벳의 독립을 지지하는 아이스닥님이 알려주신 버그 수정법

CRTDEFS.h 파일 열어서
모든 _Size를 _SUCKS_MS_BUG_Size 등 다른 이름으로 수정하면 된다. (원작자 표현 존중)

다만, 자기 컴퓨터의 버그만 고쳐지는 것이므로 되도록 혼자 작업하는게 아니라면 우회해서 사용하는것이 좋겠다.

- 버그내용 설명
stdio.h의 매크로 선언부와 crtdefs.h의 매크로 내용 정의부의 인자이름 _Size가 서로 겹쳐서 발생하는 버그라고 한다.

[stdio.h]

__DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_2_ARGLIST(int, _snprintf_s, _vsnprintf_s, __out_bcount(_Size) char, _Dest, __in size_t, _Size, __in_z __format_string const char *,_Format)

[crtdefs.h]

#define __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_2_ARGLIST(_ReturnType, _FuncName, _VFuncName, _DstType, _Dst, _TType1, _TArg1, _TType2, _TArg2) \
    extern "C++" \
    { \
        __pragma(warning(push)); \
        __pragma(warning(disable: 4793)); \
    template <size_t _Size> \
    inline \
    _ReturnType __CRTDECL _FuncName(_DstType (&_Dst)[_Size], _TType1 _TArg1, _TType2 _TArg2, ...) \
    { \
        va_list _ArgList; \
        _crt_va_start(_ArgList, _TArg2); \
        return _VFuncName(_Dst, _Size, _TArg1, _TArg2, _ArgList); \

끝.

=팁/루아= 한개의 lua_State기반에서 코루틴(lua_thread)마다 독립적인 전역환경을 갖게 하기

마술감자 — Tue, 02 Feb 2010 22:22:10 +0900

--------------------------------------------------------------------------------
-- 2010-02-02. code by magicpotato, advice by sunshine
--------------------------------------------------------------------------------
-- 하나의 luaState로 함수 하나하나를 각각 독립적인 전역환경에서 실행하게 한다.
-- 게임서버에서 스테이지를 루아스크립트로 구현할 때 유용하다.
--------------------------------------------------------------------------------
local entireStageChunks = {}
--------------------------------------------------------------------------------
 
function LoadStageScript(filename)
    table.insert(entireStageChunks, loadfile(filename))
end
--------------------------------------------------------------------------------
 
 
-- 이 함수는 코루틴으로 생성된다.
function StartStage(stageFuncName)
 
    -- 독립환경 생성 및 오리지널 환경 복사(상속)
    local per_game_env = {}
    setmetatable(per_game_env, { __index = _G } )
 
    -- 미리 로드된 모든 스크립트의 새로운 독립환경 지정, 스크립트를 새 독립환경에 적재
    -- stageFuncName에 종속된 함수만 평가하는 최적화가 필요하다.
    for i = 1, table.maxn( entireStageChunks ) do
        setfenv(entireStageChunks[i], per_game_env)
        entireStageChunks[i]()
    end
 
    -- 해당 스테이지의 스크립트 실행
    per_game_env[stageFuncName]()
end
--------------------------------------------------------------------------------

=팁/코드= MS VC 전용 #pragma TODO 매크로 코드 (__pragma 사용)

마술감자 — Fri, 22 Jan 2010 18:16:42 +0900

해야 할 일을 컴파일할 때 보여주고, 더블 클릭하면 해당 위치로 이동하므로 주석으로 적어놓는것보다 좋다.

 
//----------------------------------------------------------------------------------------
// MS-VC전용 TODO 매크로 구현 : #pragma TODO 식으로 구현하지 않아도 된다.
//----------------------------------------------------------------------------------------
#define __TOSTR__( x ) #x
#define __MTOSTR__( n ) __TOSTR__( n )
#define TODO(msg) __pragma(message(__FILE__"(" __MTOSTR__(__LINE__) ") : TODO : "msg ))
//----------------------------------------------------------------------------------------
 
void main(void)
{
        TODO("오늘은 피자를 먹자")
}

=팁/디버깅= 소프트웨어 가시화와 예외처리의 중요성

마술감자 — Fri, 22 Jan 2010 03:10:05 +0900

2010.01.22. ver2. 명국진(http://magicpotato.com)
2002.12.11. ver1

소프트웨어 가시화와 예외처리의 중요성

소프트웨어 가시화란 소프트웨어를 눈에 보이게 작성하는 것이다. (문서화가 아니다.)
쉽게 말하면 printf를 이용해서 프로그램이 어떻게 돌아가고 있는지 출력하면 된다.

일반적으로 2D Graphics를 비롯한 UI구현등은 프로그램 가시화에 신경쓰지 않아도
눈에 보이는 결과 자체가 프로그램의 올바른 작동 여부를 판단할 수 있다. (완전하진 않다.)

예외처리란 올바르게 작동하길 기대한 것과 다른 상황이 발생했을 때 다른 조치를 취하는것을 말한다.

프로그램을 작성할 때 개발자는 여러가지를 의도한다.

입력값의 범위나 선행조건, 그것이 처리되는 프로세스와 중간 결과값 및 결과처리의 형태, 후처리 등

따라서 "결과가 잘 나오는 것"은 반드시 프로그램이 잘 돌아가는것을 의미하지 않는다.
개발자가 의도한 중간과정을 포함한 모든 것을 만족해야 잘 돌아간다고 말할 수 있다.

온라인게임에서 로그인을 구현한다고 해보자
로그인 요청이 매우 다양한 원인때문에 실패 또는 성공할 수 있다.

[성공] DB가 완료되지 않아 임시로 return true를 한 코드에 의해 '임시' 로그인이 완료 되었다.(중복 로그인의 가능성)
[성공] DB쿼리까지 제대로 들어가서 모든것이 정상처리되고 로그인이 완료되었다.
[성공] (로그인정책) 기존에 접속된 유저가 있었으나 끊고, 로그인이 정상 완료되었다.
[성공] 운영자 권한을 가진 계정으로 로그인 완료 되었다.
[성공] password가 아닌 휴대폰 비밀번호 생성만을 이용해 로그인 되었다.
[실패] ID를 찾을 수 없다.
[실패] 패스워드가 틀렸다.
[실패] 이전에 패스워드가 3회 틀려 홈페이지에서 주민번호 인증을 해야 한다.
[실패] 해당 계정이 정지 또는 결제가 만료된 상태이다.
[실패] (로그인정책) 이미 로그인된 유저가 있어서 로그인 실패.
[실패] 서버의 유저가 너무 많아 로그인 실패 (혹은 대기자 순번 발급)
[실패] 연동 서버(DB, 로그인 서버)가 맛이 가서 로그인 실패

로그인 요청의 결과는 쉽게 '성공' 또는 '실패'로 정할 수 있지만,
위의 모든 사례는 실제 실행되는 코드와 함수(물리적 exe)의 협력 순서(프로세스)가 모두 다르다.

특히 맨 처음의 '임시 로그인'과 '운영자 권한 로그인'은 서비스를 할 시점에는 무진장 중요한 내용이다.
로그인만 성공했다고 로그인 기능이 제대로 작동하고 있다고 말할 수 없는 것이다.

가시화에는 정도가 있는데, 어떤 요청으로부터 결과가 처리되기까지 거치는 모든 함수 이름을 출력할 수도 있고
각각의 함수의 if, else의 판단결과나 한줄한줄 처리할때마다 '처리 들어간다' '처리가 어떻게 됐다'를 출력할 수도 있다.

위의 로그인 구현에서 말하고자 하는것은 2가지인데,
모든 상황에 대한 예외처리를 해야 한다는것과 그 예외처리의 과정을 적절히 가시화 해야 한다는 것이다.

제대로된 개발자들은 라이브러리를 만들 때 로그를 최우선적으로 개발한다.
이미 좋은 글이 있으므로 로그시스템에 대한 다른 글을 소개한다.

http://xevious7.com/142 : 로그시스템 (Log System)에 대한 고찰

실제 판매되고 서비스되는 제품을 개발할 때
핵심기능 구현을 하는 비용과 예외처리를 하는데 사용되는 비용은 큰 차이가 없다.

C/C++이나 윈도우 API, VisualC++같은 툴을 배우기 위한 서적의 학습용 코드는 예외처리가 거의 없다.
모든 코드가 제대로 처리된다는 가정으로 작성되어 있지만 실무코드는 if와 else의 떡칠이라고 보면 된다.

구현을 했으면 성공하는 케이스만 테스트하는게 아니라 코딩한 모든 예외에 대한 코드들도 함께 테스트 해야 한다.
즉, 코딩한 모든 코드를 한번씩은 다 테스트 해야 한다는 뜻이다.

브레이크 포인트를 잡아서 시행한 검증은 순간이기때문에 이것을 이용한 디버깅 습관은 갖지 않는것이 좋다.
이미 구현된 코드 근처에 다른 코드가 끼어들어도 이미 작성해 놓은 로그는 프로그램이 어떻게 돌아가는지 정확히 알려준다.

로그를 남기자!

프로그램 가시화, 로그, 예외처리등과 관계된 다른 키워드는 다음과 같다.

- 로그 시스템
- ASSERT, VERIFY, RAISE
- 에러 리포팅 시스템
- 에러 핸들링
- 덤프 남기기

끝.

=팁/3D지형= ROAM의 이해 : Realtime Optimally Adapting Meshes (2003)

마술감자 — Thu, 21 Jan 2010 22:24:48 +0900

*** 현재 ROAM은 실무에서 보편적으로 사용되고 있는 기술이 아닙니다. 공부를 위한 용도로만 사용 하시길 권장합니다. ***

2003. 09. 29. 명국진 (http://magicpotato.com)

ROAM의 이해 : Realtime Optimally Adapting Meshes

ROAM 은 광범위한 지형을 효과적으로 표현하기 위한 3D 알고리즘/자료구조를 제시.

본인은 g-Matrix(www.g-matrix.pe.kr) 에서 ROAM 번역글을 보고 공부했다. 해당 사이트의 원문은 3D에 관한 기반지식 요구수준이 높아서 3D 프로그래밍에 입문중인 본인이 이해하기에는 많은 시간이 필요했다. 또, 번역의 특정부분이 매끄럽지 못해, 여러번 생각해야 이해가 되었다. 따라서 좀더 쉽게 다른분들에게 도움이 되고자 이 문서를 작성한다.

이 문서는 ROAM에 관한것은 모두 인용/재구성 하였지만, 그 외의 기초정보나 사견은 제거하였으므로, 원문의 목적과 거리가 있을수 있다.

번역자인 이봉식님과 이해에 도움주신 손희승,박준태님께 감사드립니다.

3D입문자가 작성한 것이므로, 틀린부분이 있다면 지적편지를 부탁 드립니다.

번역문 URL : http://www.g-matrix.pe.kr/feature/3dengine/lod.htm

차례

1. ROAM 이전의 LOD(Level of Detail) 알고리즘의 기초정보
2. ROAM의 전체적인 내용을 이해하자.
3. 용어 설명
4. 주요 동작 미리 보기
5. LandScape, 패치, 삼각형의 구조설명 및 분할방식 안내
6. 편차
7. 번역문에 포함된 소스코드 가이드

1. ROAM 이전의 LOD(Level of Detail) 알고리즘의 기초정보

이 문서를 작성하기 전에 보게된 Bryan Turner(번역/이봉식님)의 ROAM 글에는 3가지의 논문이 있다고 한다. (Hoppe논문, Lindstorm논문, Duchaineau논문)

Hoppe논문의 방법은 기초지형에 삼각형을 추가해 그리는 방법인듯 하며, Linestorm논문은 지형을 재귀적으로 분할하고 사용하기 위해 쿼드트리를 사용한다. Duchaineau논문은 2번째 개념과 비슷하나, 이진 삼각형트리(Binary Triangle Tree) 자료구조를 사용한다. 우리는 이 3번째 논문에 대한 것을 공부하는 것이다.

2. ROAM의 전체적인 내용을 이해하자.

ROAM 은 Realtime Optimally Adapting Meshes 의 약자로써, '동적 매쉬 최적 조합' 정도로 해석한다.

3D 상에서 '카메라'의 위치에 따라서 폴리곤 정보를 동적으로 생성하는 기술이다. 카메라로부터 가까운 곳의 지형은 세밀하게 폴리곤을 많이 사용하고, 카메라에서 멀리 있는 곳의 지형은 대충대충 폴리곤을 적게 사용한다.

이 방법을 사용하면 넓은 지형을 렌더링(그리기)하는데 자원을 적게 소모할수 있다.

ROAM기법으로 폴리곤을 동적으로 생성할때 참조해야 하는 자료가 있다. 이것은 지형에 관한 정보를 갖고 있어야 하며, ROAM은 HeightMap 이라는 자료구조를 이용한다. (아래에 설명하였으니, 모르시는분은 먼저 이해하고 보십시오)

ROAM을 실시간 렌더링에 이용할때 다음의 3가지 정보를 참고한다.

1) HeightMap 자료구조로 된 2차원 배열의 지형 높이값 정보
2) ROAM 초기화시 구축되는 이진 삼각형 트리(BTT) 정보와 각 영역의 편차정보
3) 2의 자료 비교될 카메라의 위치정보

(2) 정보(이진삼각형트리)를 구축하고, 이용하는것이 ROAM의 핵심이다.

HeightMap자료를 적당한 척도로 분할하고, 분할된 각 영역(Patch)을 이진 삼각형 트리로 가상분할(데이터 구축이 아닌 참조분할?-차후설명)한다.

즉, 큰 영역을 2개의 삼각형으로 쪼개고, 이 삼각형을 또 2개의 삼각형 으로 쪼개고, 프로그래머가 생각하는 레벨(깊이)까지 쪼갠다.

렌더링 하는 순간, 이 쪼개진 영역이 카메라와 가까우면, 세밀하게 표현하기 위해 깊은 분할 영역까지 순회하며 폴리곤 정보를 생성하고, 그려야 하는 쪼개진 영역이 카메라와 멀면 깊이 들어가지 않고, 낮은 레벨의 정보만 참조해서 폴리곤 정보를 생성한다.

이것이 ROAM의 이론이며, 다음 단원에서 세부이론을 알아보겠다.

참고: HeightMap (HeightMap/HeightField) 란 무엇인가?

3D공간상의 지형을 높이 정보들로 표현한 구조이다.

실생활에서 볼수 있는 '지도'의 '등고선'을 적절히 바둑판 식으로 나눠서 색상이 진할수록(지형이 높을수록) 높은 숫자가 되고, 색상이 옅을수록(지형이 낮을수록) 낮은 숫자가 된다.

게임공간상에서 가로/세로 크기가 1000px * 1000px 인 맵을 헤이트 맵 자료형으로 표현할 경우 10x10 의 디테일로 표현할수도 있고 100x100, 1000x1000 의 디테일로 표현할수가 있다.

즉 하늘위에서 땅을 정면으로 내려다보고, 적당한 간격으로 자른다음, 잘라진 각 구역의 높이를 2차원 배열로 저장한 것이 헤이트 맵의 자료형이다.

    # 예시 데이터

    00 00 00 00 00    좌측의 헤이트맵 자료형은
    00 01 01 01 00    지형 한가운데에 모든 방향으로의 기울기가 같은
    00 01 02 01 00    산 하나를 갖고 있는 자료형이다.
    00 01 01 01 00
    00 00 00 00 00    해당 맵의 크기를 50x50 이라고 가정한다.

위의 데이터를 기초로 폴리곤을 생성할때 각 점을 3D 좌표화 시킨다면.. (3x3 의 크기만을 좌표화 시켜보겠다. 순서대로 x,y,z 이며 z가 높이값이다)

    공식 = x * SCALE, y * SCALE, z

    (0 x 50, 0 x 50, 00), (1 x 50, 0 x 50, 00), (2 x 50, 0 x 50, 00)
    (0 x 50, 1 x 50, 00), (1 x 50, 1 x 50, 01), (2 x 50, 1 x 50, 01)
    (0 x 50, 2 x 50, 00), (1 x 50, 2 x 50, 01), (2 x 50, 2 x 50, 02)

해당 3D좌표들로 폴리곤을 구성하면 된다.

3. 용어 설명

구역 : 사각형 또는 삼각형의 개념적인 공간 (헤이트 맵을 덮는...)

패치 : HeightMap을 2차원 배열로 나눈 조각중의 하나, 사각 구조 형태의 개념 공간

삼각형 : 3D에서 말하는 폴리곤이 아니며, 삼각형 개념의 분할된 공간을 뜻한다.

Landscape : 번역문에 포함된 소스내에 있는 클래스로써, 큰 지역 하나를 담당한다. 소스를 안봤다면, 그냥 전체를 의미한다고 생각하면 된다.

4. 주요 동작 미리 보기

ROAM의 주요 동작은 3가지 인데 다음과 같다.

1) 각 구역에 대한 편차트리 (어디까지 분할을 할것인지 비교할 테이블) 구축
2) 카메라와의 거리에 따라 작은 구역들을 알맞게 분할한다.
3) 그려야할 구역의 삼각형 트리를 순회하며 폴리곤을 생성해 낸다.

각 구역과, 삼각형트리는 개념적인 구조이지, 직접적인 좌표 데이터가 아니다. 헤이트맵과 이 개념적 구조를 합쳐서 실제 폴리곤 데이터를 뽑아내는데, 우선은 개념적인 구조먼저 설명한 다음, 좌표를 만드는법을 배울것이다.

하지만 어느정도 알고 봐야 이해가 되기때문에 대략적인 설명을 하겠다.

- 각 패치(나눠진 사각영역)는 자신이 HeightMap 내에서 어느 부분을 담당하는지 안다.
- 또, '패치'는 HeightMap 데이터에 대한 포인터를 갖고있다.
- 한개의 패치가 HeightMap에서 어느정도의 Width,Height를 담당하는지 상수등으로 정해져 있다.

ROAM은 이런 근거에 기반해서 좌표를 생성한다.

5. LandScape, 패치, 삼각형의 구조설명 및 분할방식 안내

번역문의 ROAM은 LandScape-패치-삼각형 의 개념으로 나뉘어서 구현되어있다. 이 구조들의 세부사항을 이해하면서 분할을 어떻게 하는지 알아본다.

LandScape 클래스의 주요 데이터 구조는 다음과 같다.

1) HeightMap데이터에 대한 포인터
2) HeightMap데이터를 특정 척도(SCALE)를 기준으로 잘라낸 2차원 배열의 Patch 클래스들

본인이 ROAM을 처음 공부할때 작동구조가 다음과 같은줄 알았다.

> HeightMap데이터인 맵을 큰 삼각형 2개로 나누고, 또 2개를 각각 2개로 나누고, 이것이 계속 재귀된다.

하지만, 본인이 본 논문에서는 그 방법이 아니었다.

> HeightMap데이터인 맵을 2차원 배열로 구역을 나눈다음, 그 구역을 이진 삼각형 트리로 나누고, 나누고, 나눈다.

논문에서는 이렇게 처음부터 이진삼각형 트리를 구축하는것이 아닌, 2차원 배열(Patch)로 구역을 등분한다음 삼각형 구조로 나누는데 그 이유는 2가지가 있다.

1) 삼각형이진트리는 그 트리가 깊어질수록 메모리 요구량이 지수적인 크기로 늘어난다. 따라서 구역화 하면, 이진트리 깊이가 줄어들기 때문에 그런것이다.
2) 높이맵을 동적갱신 할때 해당지역의 분할을 다시 해야하는데 트리구조가 깊은 경우에는 분할에 대한 계산을 하는데 시간이 오래 걸린다. 하지만, 작은 구역으로 여러개 나뉘어져 있다면, 필요한 구역 몇개만 계산하면 되고, 그 구역조차 작은 깊이로 트리를 구성하기 때문에 속도가 빠르다.

각각 나뉘어지는 패치(Patch/전체맵중 한곳인 사각형 구역)는 2차원 배열이다. 이 패치는 x,y,z같은 좌표값을 갖지 않고, LandScape클래스의 HeightMap데이터를 참고한다.

이번에는 작은 구역인 '패치'를 '이진삼각형트리'로 나누는것을 알아야 한다. 먼저 이진삼각형 트리 자료구조를 구성하는 삼각형 구조에 대해서 알아보자.

다음을 숙지하고 이 부분을 살펴봐야 한다.

1) 전체맵을 2차원 배열 형식으로 구역분할 한것이 Patch 이다.
2) Patch는 작은 지역을 '개념적'으로 관리한다.
3) Patch는 '사각형 영역'을 의미한다.
4) Patch는 최소 2개의 '삼각형 영역'을 갖는다.
5) Patch가 갖는 2개의 '삼각형 영역'은 서로 이웃 관계가 된다.
6) 각 삼각형들은 2개의 자식으로 분할, 또한 재귀분할 할수 있다.

그럼 '삼각형 영역' (Triangle Node)에 대해서 알아보겠다. 삼각형 영역을 줄여서 삼각형이라고 정의하며, 이 삼각형은 개념적인 값이며, 직접적인 x,y,z 와 관련된 값을 갖지 않는다.

삼각형은 다음 구조체로 정의된다.

삼각형 이진트리에 사용되는 삼각형 (영역 개념) 구조체

     struct TriTreeNode
     {
     　　　　 TriTreeNode *LeftChild;        // Our Left child
　   　　　 TriTreeNode *RightChild;       // Our Right child
　　   　　 TriTreeNode *BaseNeighbor;     // Adjacent node, below us
　　　   　 TriTreeNode *LeftNeighbor;     // Adjacent node, to our left
　　　　    TriTreeNode *RightNeighbor;    // Adjacent node, to our right
     };

패치(Patch/사각영역)가 반으로 나뉘면 역시 삼각형 두개가 되는데, 이것은 패치의 자식이라기보다는 왼쪽노드, 오른쪽 노드가 되며, 패치 바로 하부의 두개 삼각형은 서로 베이스 이웃(BaseNeighbor)이 된다.

삼각형이 반으로 나뉘면 나뉜 2개는 나뉘기전 영역의 자식이 되고, 이 2개의 자식이 왼쪽,오른쪽 차일드(Left/Right Child)가 된다.

자식,베이스이웃 관계 이외의 관계가 '왼쪽이웃/오른쪽이웃'이 되는데 이 왼쪽/오른쪽 이웃은 같은 패치안의 삼각형끼리 될수도 있고, 서로 다른 패치에 있는 삼각형간에 이루어 질수도 있다.

자세한 내용은 다음 그림을 참고하라.

베이스 이웃, 양쪽자식에 대한 필요성은 알지만, 왼쪽,오른쪽 이웃의 필요성에 대해서 아직 알수가 없는 상태이다.

이것은 폴리곤 생성중에 깨짐짐 현상을 해결하기 위한것인데, 본인은 왜 깨지는지만 설명하고, 자세한 해결법은 번역문을 참고하기 바란다. (다이아몬드에 대한 설명은 번역문을 봐도 난해하지 않을꺼라고 생각하기 때문이다)

다음 그림을 참고하며 아래 설명글을 봐야 이해가 빠르다.

서로 이웃인 삼각형 A 와 B 가 있다.

A가 2단계 깊이까지 삼각형 이진트리를 구축하고, B는 구축하지 않는다면 A의 자식 삼각형 정보를 기준으로 폴리곤을 그릴때, B의 폴리곤과 높이가 맞지 않기때문에 중간이 붕 뜨게 된다. 따라서 다이아몬드라는 규칙을 사용해서 반대편도 같이 강제분할 해 주어야 한다.

6. 편차

편차는 분할을 어디까지 할것인가를 결정할때 사용된다. 기존의 ROAM에서 그릴때는 사용되지 않는다. (본인의 입장은 그렇지 않다.)

편차를 이해하기 위해서는 삼각형의 구조체 대해서 분명히 알아야 한다. 삼각형은 4개의 기준점이 있는데 다음과 같다. (폴리곤 구성요소가 아니다)

- Apex Point (삼각형의 상단 꼭지점의 x,y,z)
- Left Point (삼각형의 왼쪽 점의 x,y,z)
- Right Point (삼각형의 오른쪽 점의 x,y,z)
- Center Point (삼각형의 왼점,오른점 사이의 x,y,z - 상단 꼭지점 수직 아래)

편차는 Left Z + Right Z 를 2로 나눈값과 Center Z 와의 차이값이다. 번역문상의 설명글은 다음과 같다.

> 이진 삼각형트리의 빗변의 중점의 보간된 높이와 그 지점에서의 실제 높이 필드값의 차이이다.

더 자세히 설명하자면 삼각형 노드가 20x20크기 패치를 반으로 나눈 삼각형 지역을 논리적으로 담당(덮는다)한다고 할때 20x20 에는 다양한 높이값이 있을수 있으므로, Left Z, Right Z, Center Z 의 값은 큰 차이가 나거나, 안날수가 있다.

ROAM은 좁은 지역에서 심하게 울퉁불퉁 한 지형보다는.. 큰 계곡과 산이 있다고 가정하고 작성된 알고리즘이라고 생각한다.

이런 큰 계곡은 특정 지역에서 점점 높아지거나, 점점 낮아질텐데, LeftZ,RightZ,CenterZ 의 크기가 크게 차이가 난다면, 중간지점에 보간할 정보가 더 있다는 뜻이 된다.

큰 편차의 삼각형 분할시 편차가 더 줄어들게 되고, 편차가 적당히 줄어들때까지 삼각형 트리로 재귀 분할을 하면 세밀한 곡선 형태의 지형을 만들수 있다. (편차가 클수록 뾰족하고 삭막한 지형이 만들어 진다)

번역본에서 설명하는 소스에서는 편차트리 라는것을 사용하는데, 패치(Patch/작은 사각영역) 클래스에서 하부 트리에 대한 모든 편차를 갖는다.

편차를 갖는 편차트리(자료형은 1차배열이나, 이론이 트리다)의 설명 그림

해당 그림에서 Index 값이 CurNodeIdx 라고 생각하고, 그림 우측 아래 있는 공식이 있는데, 이것을 이해하면 소스분석할때 편하다. 잘 모르겠으면 숫자 4를 Index에 넣고 공식을 계산해 보면 될것이다.

- Index로 부모 구하기 : Index >> 1
- 왼쪽/오른쪽 자식 Index구하기 : Index << 1 , Index << + 1

7. 번역문에 포함된 소스코드 가이드

번역문에 포함된 소스코드를 분석할때 다음을 알고 보면 편하다.

1) 시작시에 편차트리를 만든다. (분할구조에 상관없이 특정레벨까지 만든다)
2) 그릴때 다음과 같은 3가지 동작을 한다.
2.1) 나뉘어졌던 삼각형 이진트리를 리셋한다. (없애버린다)
2.2) 패치 루프를 돌며, 카메라와의 거리로 적정편차값을 만든후, 편차트리와 비교하며, 만족하는 수준의 레벨까지 분할을 한다.
2.3) 패치 루프를 돌며, 분할된 삼각형을 순회하며 폴리곤을 생성해 넣는다.

끝.

=강좌/디버깅= .dmp를 이용한 디버깅시 컴파일당시 소스코드 리비전을 SVN에서 받아오는 법 (MS Source Server 사용법) - ver2

마술감자 — Thu, 21 Jan 2010 21:49:30 +0900

2010.01.21.ver2.명국진(http://magicpotato.com)
2008.03.27.ver1

.dmp를 이용한 디버깅시 컴파일당시 소스코드 리비전을 SVN에서 받아오는 법 (MS Source Server 사용법)

(source code revision matching from svn-server automatically when debugging by the dump file, using MS source server)

0. 문서 개요

1. 소스서버 소개

2. 소스서버를 사용하는 전체 프로세스 요약

3. 소스서버 구해서 설치하고 세팅하기

4. 소스서버 실제 사용

5. 참고자료

0. 문서 개요

이 문서는 소스코드 버전관리 시스템을 사용하는 개발팀을 위한 디버깅 관련 문서이다.

개발팀이 제품을 컴파일해서 배포하더라도 소스코드는 버전업을 계속 하게 된다.
그래서 기존에 배포한 제품에서 오류가 났을 때 MiniDump()같은 기능으로 만들어낸 dmp로
디버깅을 하려고 하면 기존 바이너리와 현재의 소스코드 버전이 일치하지 않아서 디버깅에 어려움을 겪는다.

(예:exe는 1월1일 빌드, 현재 소스코드는 3월1일의 버전인 경우)

MS의 소스서버는 이 문제를 해결해 주는 유틸리티인데, 펜타비전 재직 당시 아노아씨에게 소개받았다.
국내에 소스서버를 처음 접하는 사람을 위한 문서가 없어서 작성하게 되었다.

이 문서에서는 소스서버를 소개하고 설치해서 사용하는것까지를 설명한다.

원서를 손쉽게 읽을 수 있는분은 MS Debugging Tools를 받아서 sdk/srccvr/srcsrv.doc 를 읽으면 된다.

MiniDump()
   마소가 제공하는 Platform SDK: Debugging and Error Handling 의 함수로 dbghelp.dll이 제공하는 기능이다.
   보통 컴파일러를 켠 상태에서 에러가 나면 콜스택과 현재 프로그램의 상태를 디버깅할 수 있는데

  일반 유저에게 배포한 프로그램에서 에러가 나면 어떻게 할 수 없기 때문에 개발자가 재현할 수 있도록
.dmp 파일을 남겨서 http등으로 에러 업로드를 받아서 VC++에서 디버깅을 할 수 있게 해주는 함수이다.
.dmp를 이용하기 위해서는 exe파일와 pdb파일과 추가적으로 소스파일들이 필요하다.

소스코드 버전 관리 시스템
   주로 팀 작업시 소스코드를 관리하는 중앙 서버를 따로 두고, 작업한 내용을 업로드 하고,
   남이 작업해 올려놓은 코드를 다시 다운로드(업데이트받기)하는것을 하게 해준다.
   소스파일이 변경될 때마다 버전이 증가되는데 이것을 리비전 이라고도 부른다.

   관련된 툴로는 Subversion, SourceSafe, StarTeam, Perforce, Alienbrain등이 있다.

1. 소스서버 소개

'소스서버'라는 이름을 들으면 웹서버처럼 어떤 서버처럼 느껴지는데 전혀 그렇지 않다.
이것은 분명히 이름을 잘못지은것이며, 개인적으로 RevisionMatching등의 이름을 넣으면 어떻지 않았나 싶다.
소스서버는 클라이언트에서만 작동하는 단순 유틸리티이다.

소스서버는 크게 2가지 유틸리티로 구성된다.

1) 빌드되어있는 pdb파일에 관련 소스코드 정보를 삽입하는 유틸리티
(삽입되는 정보 : 어떤 소스파일을 버전 관리 서버로부터 어떻게 받을 수 있는지)

2) pdb의 소스코드 버전정보를 얻어서 소스코드를 받는 기능

2. 소스서버를 사용하는 전체 프로세스 요약

[설치]

1) 필요한 유틸리티 및 환경변수 설정 (DebuggingTools, SVN, ActivePerl) 및 (PATH)

[사용]

2) 컴파일러를 사용해서 exe와 pdb 생성
3) (매 릴리즈마다) SourceIndex 툴을 사용해서 생성되어있는 pdb에 svn의 소스파일과 버전 정보를 삽입 (SVN저장소는 건드리지 않는다)
4.1) (디버깅시)pdb에 있는 리비전 정보를 이용해 VC8+의 SourceServer통합기능을 사용해 소스를 받아 콜스택을 본다.
4.2) (디버깅시)pdb에 있는 리비전 정보를 이용해 srctool.exe를 사용해서 해당 버전과 일치하는 소스를 받아 수동작업을 한다.

[주의사항]

ssindex.cmd를 사용해서 pdb에 소스파일/리비전 정보를 넣을 때 유틸리티는 exe와 소스파일이 일치하는지 확인하지 않는다.
따라서 ssindex(SourceIndexing)는 한번만 해야 하며, ssindex를 2번째 실행 할 때 이미 인덱싱된 pdb에 영향이 가지 않도록
완전 다른 폴더에 따로 보관해 둬야 한다.

3. 소스서버 구해서 설치하고 세팅하기

1) 소스서버

    소스서버는 그 자체로 제품이 아니라 Microsoft Debugging Tools에 포함되어있는 서브툴이다.
    http://www.microsoft.com/whdc/devtools/debugging/default.mspx 에서 적당한것을 다운받아서 설치하면
    C:\Program Files\Debugging Tools for Windows\sdk\srcsrv 같은 위치에 소스서버 유틸리티들을 찾을 수 있다.

2) Perl (ActivePerl)

    소스서버는 폴더 탐색이나 소스컨트롤 사용등 기타 작업을 쉽게 하기위해 perl 스크립트를 사용한다.
    여기서는 무난한 ActivePerl을 사용하겠다. (http://www.activestate.com/Products/activeperl/)

3) SVN (버전 관리 시스템)

    SVN에 대해 자세히 설명하는것은 이 문서의 범위를 벗어나므로 링크만 기록한다.

       http://subversion.tigris.org/project_packages.html

4. 소스서버 실제 사용 (예제)

1) 세팅

SrcSvr과 Perl, svn을 어디에서나 실행할 수 있도록 환경변수 PATH를 수정해 줘야 한다.
또한 SrcSvr이 어떤 svn에 접근해야 하는지를 알려줘야 한다.

[경로 세팅]

PATH = C:\Perl\bin;C:\Program Files\Subversion\bin;C:\Program Files\Debugging Tools for Windows\sdk\srcsrv

[소스서버정보 세팅]
대상파일 : C:\Program Files\Debugging Tools for Windows\sdk\srcsrv\srcsrv.ini 내의 MYSERVER 값 수정
수정 예 : MYSERVER=svn://MyteamSource

SVN을 기반으로 소스서버 유틸리티를 사용하면 C:\Program Files\Debugging Tools for Windows\sdk\srcsrv\svn.pm 을 실행하는데
한글과 관련된 문제를 해결하기 위해 2줄을 수정해 준다. (경로와 리비전을 추가)

if ( $curline =~ m/^Path:[\s\t]*(.*)$/i ) { 를 if ( $curline =~ m/^Path|경로:[\s\t]*(.*)$/i ) { 로

if ( $curline =~ m/^Revision:[\s\t]*(\d*)$/i ) { 를 if ( $curline =~ m/^Revision|리비전:[\s\t]*(\d*)$/i ) { 로

2) 샘플 프로젝트 생성후 빌드, SVN에 업로드 (2번 작업은 3번 작업과 병행하게 된다)

일부러 오류를 일으키는 간단한 프로젝트를 생성해서 SVN에 소스파일을 업로드 해 놓는다.
그리고 빌드를 해서 exe와 pdb를 만들어 놓는다.

SVN의 저장소 위치나 이름은 어떻게 지어도 상관없다.
이 예제에서는 서로 다른 버전의 소스파일로 컴파일된 바이너리 2 쌍을 백업해 놓는다.

솔루션 및 소스파일 위치 : D:\...\SrcSvrTestByMagicPotato
exe 및 pdb 파일 위치 : D:\...\SrcSvrTestByMagicPotato\Debug

3) ssindex를 실행해서 pdb에 SVN 정보 삽입

테스트 프로젝트의 루트에서 ssindex를 실행하면 서브 폴더를 모두 돌면서 .pdb를 갱신시켜준다.
이때 SVN에 어떤 파일을 올리거나, 기존에 올라간 파일을 전혀 건드리지 않는다.

아래 예시에서는 ssindex를 한번만 사용했지만, 실제로는 2번 사용한다.

3.1) 버전1에 대한 빌드를 만들고 소스를 모두 올려놓고 ssindex를 사용한 다음 exe와 pdb를 다른곳에 백업.
3.2) 로컬 소스에 수정을 가하고 버전2에 대한 빌드를 만들고 소스를 모두 올려놓고 ssindex를 사용한 다음 exe와 pdb를 다른곳에 백업.

D:\...\SrcSvrTestByMagicPotato)ssindex -system=svn
--------------------------------------------------------------------------------
ssindex.cmd [STATUS] : Server ini file: C:\Program Files\Debugging Tools for Windows\sdk\srcsrv\srcsrv.ini
ssindex.cmd [STATUS] : Source root    : D:\...\SrcSvrTestByMagicPotato
ssindex.cmd [STATUS] : Symbols root   : D:\...\SrcSvrTestByMagicPotato
ssindex.cmd [STATUS] : Control system : SVN
ssindex.cmd [STATUS] : SVN Executable : svn.exe
ssindex.cmd [STATUS] : SVN Revision   : N/A
ssindex.cmd [STATUS] : SVN Username   : N/A
ssindex.cmd [STATUS] : SVN Password   : N/A
--------------------------------------------------------------------------------
ssindex.cmd [STATUS] : Running... this will take some time...
ssindex.cmd [STATUS] : Processing svn.exe properties output ...

4) pdb에 리비전 정보가 제대로 들어갔는지 수동으로 확인

D:\...\SrcSvrTestBackup) srctool v1\srcsvrtestbymagicpotato.pdb

[d:\...\srcsvrtestbymagicpotato\stdafx.cpp] cmd: cmd /c svn.exe cat "svn://.../SrcSvrTestByMagicPotato/stdafx.cpp@7229" --non-interactive "D:\...\SrcSvrTestBackup\...\SrcSvrTestByMagicPotato\stdafx.cpp\7229\stdafx.cpp"
[d:\...\srcsvrtestbymagicpotato\stdafx.h] cmd: cmd /c svn.exe cat "svn://.../SrcSvrTestByMagicPotato/stdafx.h@7229" --non-interactive "D:\...\SrcSvrTestBackup\...\SrcSvrTestByMagicPotato\stdafx.h\7229\stdafx.h"
[d:\...\srcsvrtestbymagicpotato\srcsvrtestbymagicpotato.cpp] cmd: cmd /c svn.exe cat "svn://.../SrcSvrTestByMagicPotato/SrcSvrTestByMagicPotato.cpp@7230" --non-interactive "D:\...\SrcSvrTestBackup\...\SrcSvrTestByMagicPotato\SrcSvrTestByMagicPotato.cpp\7230\srcsvrtestbymagicpotato.cpp"

v1\srcsvrtestbymagicpotato.pdb: 3 source files are indexed - 160 are not

D:\...\SrcSvrTestBackup) srctool v2\srcsvrtestbymagicpotato.pdb

[d:\...\srcsvrtestbymagicpotato\stdafx.cpp] cmd: cmd /c svn.exe cat "svn://.../SrcSvrTestByMagicPotato/stdafx.cpp@7229" --non-interactive "D:\...\SrcSvrTestBackup\...\SrcSvrTestByMagicPotato\stdafx.cpp\7229\stdafx.cpp"
[d:\...\srcsvrtestbymagicpotato\stdafx.h] cmd: cmd /c svn.exe cat "svn://.../SrcSvrTestByMagicPotato/stdafx.h@7229" --non-interactive "D:\...\SrcSvrTestBackup\...\SrcSvrTestByMagicPotato\stdafx.h\7229\stdafx.h"
[d:\...\srcsvrtestbymagicpotato\srcsvrtestbymagicpotato.cpp] cmd: cmd /c svn.exe cat "svn://.../SrcSvrTestByMagicPotato/SrcSvrTestByMagicPotato.cpp@7233" --non-interactive "D:\...\SrcSvrTestBackup\...\SrcSvrTestByMagicPotato\SrcSvrTestByMagicPotato.cpp\7233\srcsvrtestbymagicpotato.cpp"

v2\srcsvrtestbymagicpotato.pdb: 3 source files are indexed - 160 are not

5) VC8+(VS2005+)에서 자동으로 소스를 받아서 보여주게 하기 위한 세팅

컴파일러 없이 EXE만 실행해서 오류를 낼 것인데, 오류가 나면 디버거를 띄울것이다.
이때 VC8+이 소스서버 유틸리티를 사용해서 소스를 자동으로 받게 하려면 세팅이 필요하다.

[Tools] - [Options] - [Debugging] - [Enable source server support] 의 체크를 켜준다.

6) 2쌍의 exe를 실행해서 오류가 나면 디버거를 실행시켜서 소스를 제대로 받는지 확인해 본다.

pdb와 연결된 소스코드는 SVN으로부터 받으며, 저장위치는 임시폴더이다.

VC8에 소스서버 사용 옵션을 켜 놓으면 다음과 같이 소스를 받을건데 실행하냐고 물어본다.

cmd /c svn.exe cat "svn://.../SrcSvrTestByMagicPotato/SrcSvrTestByMagicPotato.cpp@7230" --non-interactive "C:\Documents and Settings\magicpotato\Local Settings\Application Data\SourceServer\...\SrcSvrTestByMagicPotato\SrcSvrTestByMagicPotato.cpp\7230\srcsvrtestbymagicpotato.cpp"

소스를 받겠다고 한 다음 첫번째 버전에 대한 디버깅 화면 (printf에 Hellp mp? 라고 적혀있다.)

소스를 받겠다고 한 다음 두번째 버전에 대한 디버깅 화면 (printf에 Hello MagicPotato? 라고 적혀있다.)

5. 참고자료

1) http://msdn2.microsoft.com/ko-kr/magazine/cc163563(en-us).aspx

2) C:\Program Files\Debugging Tools for Windows\sdk\srcsrv\srcsrv.doc

3) http://hyperlightz.tistory.com/entry/SourceServerSetup

끝.

=공지= 다용도 쓰레드 (안부인사, 방명록, 잡담등 성격의 댓글은 이 글에 부탁드립니다)

마술감자 — Tue, 01 Dec 2009 23:48:57 +0900

헤헤 0등

=이슈= 루아 스크립트와 OS 멀티쓰레드 이슈 요약 [ver2]

마술감자 — Thu, 22 Oct 2009 14:07:05 +0900

2009.10.22.명국진(http://magicpotato.com/)

루아 스크립트와 OS 멀티쓰레드 이슈 요약

1. 공식적인 루아의 OS멀티쓰레드 지원 내역
2. 루아 State 구조
3. 참고방안
4. 참고자료

1. 공식적인 루아의 OS멀티쓰레드 지원 내역

루아는 공식적으로 OS멀티쓰레드를 지원하지 않는다.

개인적으로 lua 소스코드를 확인하고 테스트해본 결과
OS쓰레드마다 lua_open()를 사용해서 lua_State얻고 각각 사용하는것은 문제가 없다.

lua_newthread() 는 루아에서 제공하는 논리적인 개념의 쓰레드(코루틴)일 뿐, OS쓰레드와 관계가 없다.
lua_newthread(lua_open()) 형태로 얻은 lua_State는 OS쓰레드세이프하지 않다.

lua_newthread()를 이용해 얻은 lua_State들은 서로 다른 OS쓰레드에서 각각 이용될 수 없다.

2. 루아 State 구조

멀티쓰레드 이슈와 관련된 부분만 코드로 살펴보면 lua_State는 global_State와 상호참조하고 있다.

lua_State *mainL = lua_open();
lua_newthread(mainL)->l_G->mainthread == mainL 이 성립한다.

struct global_State
{
     struct lua_State *mainthread;
};

struct lua_State
{
     global_State *l_G;
};

#define G(L)    (L->l_G)

위와같은 이유로 루아쓰레드들은 서로 다른 OS쓰레드에서 각각 이용될 수 없다.

3. 참고방안

루아 개발자는 공식적으로 루아의 OS멀티쓰레드 지원을 하고 있지 않지만,
루아 소스코드를 확인해보면 동기화 매크로를 오버라이드 할 수 있도록 마련해 놓았다.

---------- llimits.h
#ifndef lua_lock
#define lua_lock(L) ((void) 0)
#define lua_unlock(L) ((void) 0)
#endif

---------- luaconf.h
/*
@@ LUAI_EXTRASPACE allows you to add user-specific data in a lua_State
@* (the data goes just *before* the lua_State pointer).
** CHANGE (define) this if you really need that. This value must be
** a multiple of the maximum alignment required for your machine.
*/
#define LUAI_EXTRASPACE 0

/*
@@ luai_userstate* allow user-specific actions on threads.
** CHANGE them if you defined LUAI_EXTRASPACE and need to do something
** extra when a thread is created/deleted/resumed/yielded.
*/
#define luai_userstateopen(L) ((void)L)
#define luai_userstateclose(L) ((void)L)
#define luai_userstatethread(L,L1) ((void)L)
#define luai_userstatefree(L) ((void)L)
#define luai_userstateresume(L,n) ((void)L)
#define luai_userstateyield(L,n) ((void)L)

그런데 문제는 루아 소스코드에서 L->l_G 로 접근할때는 global_State에 대한 락 매크로가 없다는 것이다.
따라서 위 기능을 모두 구현해도 OS차원의 멀티쓰레드 이슈는 해결되지 않을것 같다.

가장 편한 방법은 쓰레드마다 lua_open()만 사용하는것 같다.

4. 참고자료

참고사항 (v2)

LUAI_EXTRASPACE 매크로를 재정의해서 사용할 경우, 루아 소스코드를 새로 컴파일 해야 한다.

http://lua-users.org/lists/lua-l/2003-04/msg00185.html : Roberto Ierusalimschy(루아 개발자)

Overhead. To call a funtion (or simply check its existence) in every
entry/exit to a Lua function is a waste for the majority of programs
that do not need it. (Support for OS threads is not an "official"
feature of Lua; it is more like a bonus.)

-- Roberto

http://www.tecgraf.puc-rio.br/~diego/professional/luathread/

- The library runs both on Unix systems supporting the Pthreads standard and on Win32 systems (natively).

: 루아스크립트만 사용하는 사람이 루아쓰레드를 쓸 경우 실제로 OS멀티쓰레드 형태로 작동하게 하는것이지,

: 프로그래머가 바인딩을 할때 멀티쓰레드상에서 제대로 작동하게 하는지는 보장해 주는 제품이 아니다.

=도서/목차= GPU Gems 전권 목차 (1~3)

마술감자 — Mon, 12 Oct 2009 23:02:57 +0900

1. GPU Gems1------------------------------------------------------------------------------------------------------------------------------------------------------------------------

NATURAL EFFECTS

Effective Water Simulation from Physical Models
Mark Finch (Cyan Worlds)

Rendering Water Caustics
Juan Guardado (NVIDIA) and Daniel Sánchez-Crespo (Universitat Pompeu Fabra / Novarama Technology)

Skin in the “Dawn” Demo
Curtis Beeson and Kevin Bjorke (NVIDIA)
Animation in the “Dawn” Demo
Curtis Beeson (NVIDIA)

Implementing Improved Perlin Noise
Ken Perlin (New York University)
Fire in the “Vulcan” Demo
Hubert Nguyen (NVIDIA)
Rendering Countless Blades of Waving Grass
Kurt Pelzer (Piranha Bytes)
Simulating Diffraction
Jos Stam (Alias Systems)

LIGHTING AND SHADOWS

Efficient Shadow Volume Rendering
Morgan McGuire (Brown University)

Cinematic Lighting
Fabio Pellacini and Kiril Vidimce (Pixar Animation Studios)

Shadow Map Antialiasing
Michael Bunnell (NVIDIA) and Fabio Pellacini (Pixar Animation Studios)

Omnidirectional Shadow Mapping
Philipp Gerasimov (iXBT.com)

Generating Soft Shadows Using Occlusion Interval Maps
William Donnelly (University of Waterloo) and Joe Demers (NVIDIA)

Perspective Shadow Maps: Care and Feeding
Simon Kozlov (Softlab-NSK)

Managing Visibility for Per-Pixel Lighting
John O’Rorke (Monolith Productions)

MATERIALS

Real-Time Approximations to Subsurface Scattering
Simon Green (NVIDIA)

Ambient Occlusion
Matt Pharr and Simon Green (NVIDIA)

Spatial BRDFs
David McAllister (NVIDIA)

Finite-Radius Sphere Environment Mapping
Kevin Bjorke (NVIDIA)

Texture Bombing
R. Steven Glanville (NVIDIA)

IMAGE PROCESSING

Real-Time Glow
Greg James (NVIDIA) and John O’Rorke (Monolith Productions)

Color Controls
Kevin Bjorke (NVIDIA)

Depth of Field: A Survey of Techniques
Joe Demers (NVIDIA)

High-Quality Filtering
Kevin Bjorke (NVIDIA)

Fast Filter Width Estimates with Texture Maps
Matt Pharr (NVIDIA)

The OpenEXR File Format
Florian Kainz, Rod Bogart, and Drew Hess (Industrial Light & Magic)

A Framework for Image Processing
Frank Jargstorff (NVIDIA)

PERFORMANCE AND PRACTICALITIES

Graphics Pipeline Performance
Cem Cebenoyan (NVIDIA)

Efficient Occlusion Culling
Dean Sekulic (Croteam)

The Design of FX Composer
Christopher Maughan (NVIDIA)

Using FX Composer
Christopher Maughan (NVIDIA)

An Introduction to Shader Interfaces
Matt Pharr (NVIDIA)

Converting Production RenderMan Shaders to Real-Time
Steve Marshall (Sony Pictures Imageworks)

Integrating Hardware Shading into Cinema 4D
Jörn Loviscach (Hochschule Bremen)

Leveraging High-Quality Software Rendering Effects in Real-Time Applications
Alexandre Jean Claude and Marc Stevens (Softimage)

Integrating Shaders into Applications
John O’Rorke (Monolith Productions)

BEYOND TRIANGLES

A Toolkit for Computation on GPUs
Ian Buck and Tim Purcell (Stanford University)

Fast Fluid Dynamics Simulation on the GPU
Mark Harris (University of North Carolina at Chapel Hill)

Volume Rendering Techniques
Milan Ikits (University of Utah), Joe Kniss (University of Utah), Aaron Lefohn (University of California, Davis), and Charles Hansen (University of Utah)

Applying Real-Time Shading to 3D Ultrasound Visualization
Thilaka Sumanaweera (Siemens Medical Solutions USA, Inc.)

Real-Time Stereograms
Fabio Policarpo (Paralelo Computação Ltda.)

Deformers
Eugene d’Eon (University of Waterloo)

2. GPU Gems2------------------------------------------------------------------------------------------------------------------------------------------------------------------------

GEOMETRIC COMPLEXITY

Towards Photorealism in Virtual Botany
David Whatley (Simutronics Corporation)

Terrain Rendering using GPU-Based Geometry Clipmaps
Arul Asirvatham and Hugues Hoppe (Microsoft Research)

Inside Geometry Instancing
Francesco Carucci (Lionhead Studios)

Segment Buffering
Jon Olick (2015)

Optimizing Resource Management with Multi-Streaming
Kurt Pelzer and Oliver Hoeller (Piranha Bytes)

Hardware Occlusion Queries Made Useful
Michael Wimmer and Jiri Bittner (Vienna University of Technology)

Adaptive Tessellation of Subdivision Surfaces with Displacement Mapping
Michael Bunnell (NVIDIA Corporation)

Per-Pixel Displacement Mapping with Distance Functions
William Donnelly (University of Waterloo)

SHADING, LIGHTING, AND SHADOWS

Deferred Shading in STALKER
Oles Shishkovtsov (GSC Game World)

Real-Time Computation of Dynamic Irradiance Environment Maps
Gary King (NVIDIA Corporation)

Approximate Bidirectional Texture Functions
Jan Kautz (Massachusetts Institute of Technology)

Tile-Based Texture Mapping
Li-Yi Wei (NVIDIA Corporation)

Implementing the Mental Images Phenomena Renderer on the GPU
Martin-Karl Lefrançois (mental images)

Dynamic Ambient Occlusion and Indirect Lighting
Michael Bunnell (NVIDIA Corporation)

Blueprint Rendering and "Sketchy Drawings"
Marc Nienhaus and Jürgen Döllner (University of Potsdam)

Accurate Atmospheric Scattering
Sean O'Neil

Efficient Soft-Edged Shadows Using Pixel Shader Branching
Yury Uralsky (NVIDIA Corporation)

Using Vertex Texture Displacement for Realistic Water Rendering
Yuri Kryachko (1C: Maddox Games)

Generic Refraction Simulation
Tiago Sousa (Crytek)

HIGH-QUALITY RENDERING

Fast Third-Order Texture Filtering
Christian Sigg (ETH Zurich) and Markus Hadwiger (VRVis Research Center)

High Quality Antialiased Rasterization
Dan Wexler and Eric Enderton (NVIDIA Corporation)

Fast Prefiltered Lines
Eric Chan and Frédo Durand (Massachusetts Institute of Technology)

Hair Animation and Rendering in the Nalu Demo
Hubert Nguyen and William Donnelly (NVIDIA Corporation)

Using Lookup Tables to Accelerate Color Transformations
Jeremy Selan (Sony Pictures Imageworks)

GPU Image Processing in Apple's Motion
Pete Warden (Apple)

Implementing Improved Perlin Noise
Simon Green (NVIDIA Corporation)

Advanced High-Quality Filtering
Justin Novosad (discreet)

Mipmap Level Measurement
Iain Cantlay (Climax Entertainment)

GENERAL PURPOSE COMPUTATION ON GPUS: A PRIMER

Streaming Architectures and Technology Trends
John Owens (University of California, Davis)

The GeForce 6 Series GPU Architecture
Emmett Kilgariff and Randima Fernando (NVIDIA Corporation)

Mapping Computational Concepts to GPUs
Mark Harris (NVIDIA Corporation)

GPU Computation Strategies and Tips
Ian Buck (Stanford University)

Implementing Efficient Parallel Data Structures on GPUs
Aaron Lefohn (University of California, Davis), Joe Kniss (University of Utah), John Owens (University of California, Davis)

GPU Flow Control Idioms
Mark Harris (NVIDIA Corporation) and Ian Buck (Stanford University)

GPU Program Optimization
Cliff Woolley (University of Virginia)

Stream Reduction Operations for GPGPU Applications
Daniel Horn (Stanford University)

IMAGE-ORIENTED COMPUTING

Octree Textures on the GPU
Sylvain Lefebvre, Samuel Hornus, and Fabrice Neyret (GRAVIR/IMAG - INRIA)

High-Quality Global Illumination Rendering Using Rasterization
Toshiya Hachisuka (The University of Tokyo)

Global Illumination using Progressive Refinement Radiosity
Greg Coombe (University of North Carolina at Chapel Hill) and Mark Harris (NVIDIA Corporation)

Computer Vision on the GPU
James Fung (University of Toronto)

Deferred Filtering: Rendering from Difficult Data Formats
Joe Kniss (University of Utah), Aaron Lefohn, and Nathaniel Fout (University of California, Davis)

Conservative Rasterization
Jon Hasselgren, Tomas Akenine-Möller, and Lennart Ohlsson (Lund University)

SIMULATION AND NUMERICAL ALGORITHMS

GPU Computing for Protein Structure Prediction
Paulius Micikevicius (Armstrong Atlantic State University)

A GPU Framework for Solving Systems of Linear Equations
Jens Krüger and Rüdiger Westermann (Technische Universität München)

Options Pricing on the GPU
Craig Kolb and Matt Pharr (NVIDIA Corporation)

Improved GPU Sorting
Peter Kipfer and Rüdiger Westermann (Technische Universität München)

Flow Simulation with Complex Boundaries
Wei Li (Siemens Corporate Research), Zhe Fan, Xiaoming Wei, and Arie Kaufman (Stony Brook University)

Medical Image Reconstruction with the FFT
Thilaka Sumanaweera and Donald Liu (Siemens Medical Solutions USA, Inc.)

3. GPU Gems3------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Chapter 1: Generating Complex Procedural Terrains Using the GPU
Ryan Geiss, NVIDIA Corporation

Chapter 2: Animated Crowd Rendering
Bryan Dudash, NVIDIA Corporation

Chapter 3: DirectX 10 Blend Shapes: Breaking the Limits
Tristan Lorach, NVIDIA Corporation

Chapter 4: Next-Generation SpeedTree Rendering
Alexander Kharlamov, NVIDIA Corporation
Iain Cantlay, NVIDIA Corporation
Yury Stepanenko, NVIDIA Corporation

Chapter 5: Generic Adaptive Mesh Refinement
Tamy Boubekeur, LaBRI–INRIA, University of Bordeaux
Christophe Schlick, LaBRI–INRIA, University of Bordeaux

Chapter 6: GPU-Generated Procedural Wind Animations for Trees
Renaldas Zioma, Electronic Arts/Digital Illusions CE

Chapter 7: Point-Based Visualization of Metaballs on a GPU
Kees van Kooten, Playlogic Game Factory
Gino van den Bergen, Playlogic Game Factory
Alex Telea, Eindhoven University of Technology

Chapter 8: Summed-Area Variance Shadow Maps
Andrew Lauritzen, University of Waterloo

Chapter 9: Interactive Cinematic Relighting with Global Illumination
Fabio Pellacini, Dartmouth College
Miloš Hašan, Cornell University
Kavita Bala, Cornell University

Chapter 10: Parallel-Split Shadow Maps on Programmable GPUs
Fan Zhang, The Chinese University of Hong Kong
Hanqiu Sun, The Chinese University of Hong Kong
Oskari Nyman, Helsinki University of Technology

Chapter 11: Efficient and Robust Shadow Volumes Using Hierarchical Occlusion Culling and Geometry Shaders
Martin Stich, mental images
Carsten Wächter, Ulm University
Alexander Keller, Ulm University

Chapter 12: High-Quality Ambient Occlusion
Jared Hoberock, University of Illinois at Urbana-Champaign
Yuntao Jia, University of Illinois at Urbana-Champaign

Chapter 13: Volumetric Light Scattering as a Post-Process
Kenny Mitchell, Electronic Arts

Chapter 14: Advanced Techniques for Realistic Real-Time Skin Rendering
Eugene d’Eon, NVIDIA Corporation
David Luebke, NVIDIA Corporation

Chapter 15: Playable Universal Capture
George Borshukov, Electronic Arts
Jefferson Montgomery, Electronic Arts
John Hable, Electronic Arts

Chapter 16: Vegetation Procedural Animation and Shading in Crysis
Tiago Sousa, Crytek

Chapter 17: Robust Multiple Specular Reflections and Refractions
Tamás Umenhoffer, Budapest University of Technology and Economics
Gustavo Patow, University of Girona
László Szirmay-Kalos, Budapest University of Technology and Economics

Chapter 18: Relaxed Cone Stepping for Relief Mapping
Fabio Policarpo, Perpetual Entertainment
Manuel M. Oliveira, Instituto de Informática—UFRGS

Chapter 19: Deferred Shading in Tabula Rasa
Rusty Koonce, NCsoft Corporation

Chapter 20: GPU-Based Importance Sampling
Mark Colbert, University of Central Florida
Jaroslav Kr?ivánek, Czech Technical University in Prague

Chapter 21: True Impostors
Eric Risser, University of Central Florida

Chapter 22: Baking Normal Maps on the GPU
Diogo Teixeira, Move Interactive

Chapter 23: High-Speed, Off-Screen Particles
Iain Cantlay, NVIDIA Corporation

Chapter 24: The Importance of Being Linear
Larry Gritz, NVIDIA Corporation
Eugene d’Eon, NVIDIA Corporation

Chapter 25: Rendering Vector Art on the GPU
Charles Loop, Microsoft Research
Jim Blinn, Microsoft Research

Chapter 26: Object Detection by Color: Using the GPU for Real-Time Video Image Processing
Ralph Brunner, Apple
Frank Doepke, Apple
Bunny Laden, Apple

Chapter 27: Motion Blur as a Post-Processing Effect
Gilberto Rosado, Rainbow Studios

Chapter 28: Practical Post-Process Depth of Field
Earl Hammon, Jr., Infinity Ward

Chapter 29: Real-Time Rigid Body Simulation on GPUs
Takahiro Harada, University of Tokyo

Chapter 30: Real-Time Simulation and Rendering of 3D Fluids
Keenan Crane, University of Illinois at Urbana-Champaign
Ignacio Llamas, NVIDIA Corporation
Sarah Tariq, NVIDIA Corporation

Chapter 31: Fast N-Body Simulation with CUDA
Lars Nyland, NVIDIA Corporation
Mark Harris, NVIDIA Corporation
Jan Prins, University of North Carolina at Chapel Hill

Chapter 32: Broad-Phase Collision Detection with CUDA
Scott Le Grand, NVIDIA Corporation

Chapter 33: LCP Algorithms for Collision Detection Using CUDA
Peter Kipfer, Havok

Chapter 34: Signed Distance Fields Using Single-Pass GPU Scan Conversion of Tetrahedra
Kenny Erleben, University of Copenhagen
Henrik Dohlmann, 3Dfacto R&D

Chapter 35: Fast Virus Signature Matching on the GPU
Elizabeth Seamans, Juniper Networks
Thomas Alexander, Polytime

Chapter 36: AES Encryption and Decryption on the GPU
Takeshi Yamanouchi, SEGA Corporation

Chapter 37: Efficient Random Number Generation and Application Using CUDA
Lee Howes, Imperial College London
David Thomas, Imperial College London

Chapter 38: Imaging Earth’s Subsurface Using CUDA
Bernard Deschizeaux, CGGVeritas
Jean-Yves Blanc, CGGVeritas

Chapter 39: Parallel Prefix Sum (Scan) with CUDA
Mark Harris, NVIDIA Corporation
Shubhabrata Sengupta, University of California, Davis
John D. Owens, University of California, Davis

Chapter 40: Incremental Computation of the Gaussian
Ken Turkowski, Adobe Systems

Chapter 41: Using the Geometry Shader for Compact and Variable-Length GPU Feedback
Franck Diard, NVIDIA Corporation