[발표자료] Deferred Shading Overview
Deferred Shading의 간략히 소개를 하는 발표자료. 라이팅에 필요한 재료들을 G-buffer에 쓰고 라이팅을 할 때 G-buffer를 참조하는 게 핵심이다. 개념은 간단하지만 Transparency, AA 등 극복해야 할 난관들이 존재한다.
자료 조사를 하다 보니 Deferred Shading - Wikipedia의 레퍼런스 단락에 설명을 잘해놓은 참고 자료들이 많았다.
[발표자료/SICP] 4.4 논리로 프로그램 짜기
논리 중심으로 프로그래밍하는 개념이 어떤건지 배우는 챕터인데,평소 아무 생각 없이 써오던 DB 쿼리 언어에 관해 다시 한번 되짚어 볼 수 있었다. 쿼리 언어 실행기를 하는 일에 비해 적은 양의 소스 코드로 뚝딱 만들어 내는 것 보면 정말 놀랍다.
[리뷰] 초보 개발자를 위한 오픈 소스 라이선스 길잡이 - developerWorks
특허는 ... 알고리즘이 같다면 어떤 컴퓨터 언어로 표현되었는지에 상관없이 침해로 규율할 수 있기 때문이다. ... 그러나 출원 및 등록유지 비용이 든다는 점이 단점이다.
이에 비해 저작권은 알고리즘이 표현된 것을 보호하므로 보호받는 범위가 좁고 프로그램 저작물을 의도적으로 보고 베꼈다는 것도 따져봐야 한다는 단점이 있다.
특허법에서는 연구 또는 시험 목적으로 사용하거나 비사업적으로 사용하는 것이면 설령 특허와 동일한 것을 사용해도 침해가 되지 않는다. 이와 비슷하게 컴퓨터 프로그램 보호법에서도 특정 교육 기관의 수업용 또는 교과서 게재, 개인적 사용 등의 경우에는 저작권 침해가 되지 않는 것으로 규정하고 있다.
저작권은 알고리즘을 컴퓨터 언어로 표현된 것을 보호하는데, 컴퓨터 프로그래밍 언어로 표현된 소스코드만을 보호하는 것이 아니라, 상기 소스코드를 0과 1로 구성되는 기계어로 표현한 실행 코드도 당연히 보호 대상이 된다.
특허가 걸려있는 알고리즘을 연구, 비사업적 목적으로 사용하면 침해가 되지 않는다. 그래픽스 그림자 알고리즘인 Trapezoidal Shadow Maps(TSM)은 알고리즘 특허가 발명한 대학에 있는데, 상업적인 목적이 아니면 자유롭게 연구, 시험해 볼 수 있다. 게임에 넣으려면 문제지만...
저작권은 연구고 뭐고 없다. 닥치고 지켜줘야 하는 권리이다.
[STL] VS 2005의 std::string 구현(딩컴웨어 STL)
Effective STL 항목 15에서 string이 여러 가지 방식으로 구현되어 있다는 걸 상기시키고 있다. 구현 방법까지 표준 문서에 정의하지 않았기 때문에 당연한 결과이기도 하다. VS 2005에 포함된 딩컴웨어 STL은 어떻게 구현되었나 궁금해서 찾아봤다.
책에서는 4가지 타입의 구현 방법을 설명해놨는데, 딩컴웨어의 string 구현을 보고 D 타입을 적었던 거 같다. 짧은 문자는 동적 할당을 하지 않고 내부 버퍼를 사용하는 단문자열 최적화(small string optimization) 구현이 되어 있었다.
[STL] copy_if 알고리즘 구현
STL 알고리즘 이름의 _if 접미사는 술어 함수(predicate)를 인자로 받는 것을 의미한다. 이 술어 함수를 알고리즘 안에서 호출해서 돌려받은 반환 값에 따라 동작을 수행할지 말지를 결정하게 된다. 예를 들면 count_if()는 술어 함수 호출결과가 true인 원소들의 개수를 세는 알고리즘이고 remove_if()는 술어 함수 호출 결과가 true인 원소들을 제거하는 알고리즘이다.
시퀀스(Sequences - vector, list, deque) 알고리즘 중에 _if 가 있을만한 알고리즘인데 없는 알고리즘이 있다. 가장 단순한 형태인 복사를 수행하는 copy() 알고리즘이 주인공인데, 정말 있을법한데 없는 알고리즘이다. Effective STL 항목 36에서 이 사실을 알게 됐는데, 혹시나 싶어서 TC++PL을 보니 이 책에도 copy_if()에 대한 언급이 있었다. 표준 위원회가 STL 명세를 결정할 때 제거한 알고리즘이다. Where is copy_if (was: STL question: where is find_first_not_of?)에서 비야네 스트롭스트룹의 답변을 볼 수 있다.
[STL] 정렬 알고리즘(sort, stable_sort, partial_sort, nth_element)
컨테이너 정렬이 필요할 때, sort를 사용하고 순서가 유지돼야 하면 stable_sort를 사용했다. partial_sort와 nth_element는 한 번도 사용해본 적이 없는데, 일부분만 정렬이 필요하거나 몇 번째 원소를 뽑을 때 유용하게 사용할 수 있을 것 같다. 예를 들면 최고 작은 수 10개만 차례대로 혹은 차례 상관없이 뽑는다던지, 9번째로 작은 수만 뽑는다던지 할 때에 사용하면 좋을 거 같다. 구현하는데 시간을 추가로 쓰는 것도 아니고 이미 구현되어 있는데, 딱 필요한 만큼만 정렬해서 시간을 절약할 수 있다. 아무리 작은 시간이라 하더라도 그냥 낭비하는 건 죄를 짓는 거.
nth_element는 정렬 기준에 따라 몇 번째 원소만 정확히 뽑아준다. 원소를 기준으로 정렬 기준에 맞게 좌우를 나눠주기는 하는데, 그 원소들 사이에 정렬은 되어 있지 않은 상태이다. partial_sort는 시작점부터 지정한 위치까지만 정렬해준다. 나머지는 정렬되지 않은 상태로 놔둔다. sort와 stable_sort는 시작점에서 끝점까지 정렬하는데, 정렬되고 난 뒤 stable을 보장 여부가 다르다. 동일한 정렬 기준을 가진 녀석들의 순서가 정렬 후에도 바뀌지 않으면 stable하다고 하는데, 뒤에 소스 코드 예를 보면 단박에 이해된다. 참고로 merge sort, insertion sort가 대표적인 stable sort 알고리즘이고 unstable sort의 대표적인 알고리즘은 quicksort 이다.
수행 시간은 nth_element < partial_sort < sort < stable_sort 이다.
[발표자료/SICP] 3.4 병행성 : 시간은 중요하다
프로시저를 병행으로 돌릴 때, 줄 세우개(serializer)를 사용해 줄 세우개를 사용한 프로시저 그룹에서는 여러 프로시저가 실행되지 않게 한다. 줄 세우개를 사용한 동기화, 데드락의 이슈를 스킴(Scheme)으로 설명한 챕터.
PS : 역자 주석에도 밝혔듯이 serialize를 직렬화라고 번역하면 Input/output 에서의 직렬화와 헷갈릴 수 있기 때문에 줄 세우기라는 단어를 썼다고 하는데, 이해가 되는 좋은 단어라고 생각된다.
[STL] auto_ptr - 조심히 사용해야 하는 스마트 포인터
변태적인 복사 동작을 하는 스마트 포인터다.
꼭 필요한 경우가 아니라면 레퍼런스 카운팅을 하는 스마트 포인터를 사용하자.
스마트 포인터?
In computer science, a smart pointer is an abstract data type that simulates a pointer while providing additional features, such as automatic garbage collection or bounds checking.
스마트 포인터란 자동으로 자원 해제를 하는 등의 추가적인 동작을 하는 포인터의 추상 데이터 타입(abstract data type)이다.
[STL] accumulate - 수치 알고리즘
for_each 알고리즘으로 대체 구현이 가능한 거라 한 번도 사용해보지 않은 알고리즘이다. Effective STL의 37번 항목에서 accumulate알고리즘에 대한 언급이 나오는데, 으.. 읽고 보니 좋은 걸 안 쓰고 있었구나.
시작과 끝점을 주고는 그 범위를 요약(summarize)하는데 사용하는 알고리즘이라는 걸 온몸으로 말하고 있다. for_each라는 친근한 알고리즘으로 대체 구현이 가능하지만, for_each는 컨테이너의 원소에 대해 하나하나 연산을 하는 의미로 다가오는 반면 accumulate 원소들을 연산해서 하나의 값으로 만드는 의미로 다가온다.
accumulate 관련된 글을 읽으니 예전에 짠 코드가 떠올랐다.
[리뷰] 이슈 트래커 개발자가 들려주는 이슈 트래커 이야기 - developerWorks
맨티스(Mantis), 버그 질라(Bugzilla), 트랙(trac) 등 유명한 이슈 트래커가 팀 요구 사항에 맞지 않아 ECUS라는 사내 이슈 트래커를 개발하면서 겪은 경험담을 적어 놓았다. 많이 쓰이는 오픈 소스 기반의 이슈 트래커들의 장단점과 ECUS에서 어떤 걸 버리고 개선했는지에 대한 얘기를 1부에서 다뤘고 이슈 트래커를 사용하면서 겪은 경험에서 얻은 사용 노하우를 2부에서 다뤘다.
이슈 트래커를 개발하면서 고민한 것들을 적어놔서 새롭게 배우는 점도 있었고 나도 겪은 일이라서 공감이 가는 점도 있었다. 경험담을 쏟아 놓은 글이라서 재미있게 술술 읽힌다. 뭐~ 이슈 트래커들의 특징이라던지 장단점을 비교한 글들은 인터넷에서 쉽게 찾을 수 있겠지만, 이슈 트래커를 개발하는 입장에서 벤치 마킹 대상으로 이슈 트래커들을 비교한 글은 찾기 어려운데, 이 글에서 짧지만, 그에 대한 시각도 볼 수가 있었다.
