shader study

1. 이민웅

2.  코드의 패턴과 스타일이 어긋남
 개인적으로 선호하는 방식이 틀림
 객체 간 통신을 엄격히 규제하지 않으면 의존관계
들이 뒤엉켜 복잡한 스파게티 코드가 만들어짐
 실제로 의도하지는 않지만 다른 객체와 연결하려
면 반드시 필요한 헤더파일 의존성이 생기기 쉬움
 깨지기 쉬운 코드를 디버깅하다 보면 잡은 버그보
다 새로 생긴 버그다 더 많음

3.  하나의 간단한 기반 클래스(base class)를 상속
 개념적으로는 장면그래프와 비슷함
◦ 모든 노는는 부모-자식 관계를 유지
 코드 모듈들의 부모-자식 관계와 동기관계를 명시
적으로 정의
 계통구조 안에서의 객체의 형식을 손쉽게 파악할
수 있는 실행 시점 형식 식별(RTTI)시스템도 필요

6.  루트노드
◦ 관리자 클래스가 가짐
 객체 노드는 자신의 다음 동기 노드로의 링크와 자
신의 첫 자식 노드로의 링크를 가짐

7.  갱신순서
◦ 항상 자식들보다 부모를 먼저 갱신
◦ 동기들을 항상 앞에서 뒤의 순서로 갱신
 갱신방법
◦ 너비 우선(depth-first)
◦ 깊이 우선(breath-first)
 필자는 메모리 접근 패턴과 성능의 관점에서 선호

8.  코드가 갱신 주기에 유연하게 반응하게 하고 객체
들이 수직 동기화 사전으로부터 분리되게 하면 여
러가지 이득을 얻음
 가변 시간 간격의 지원
◦ 다양한 타이밍 요구사항을 처리 하는데 도움

9.  갱신 계통구조를 실행 시점에서 구축
◦ 하나의 동적 자료구조로 취급
 예를 들어 네트워크에 연결된 처리를 하고 싶지 않
으면 헤당 노드를 제거 하면 됨
◦ 자료파일을 읽어서 갱신 계통구조를 구축하는 것도 가능
◦ IF문을 쓸 필요가 없음
If(networkActive)
{
…Code…
}

10.  자기조사 시스템
◦ 객체들의 목록을 처리하는 기능
◦ 계통구조 안에서의 상대위치에 따라 객체를 걸러내는 기
능
 객체연결관계가 더 이상 코드에 명시적으로 박혀
있는 어떤 것이 아니라 실행시점의 동적인 속성이
됨
◦ 클래스의 어떤 한 인스턴스를 얻어올려면..
EX) ptrG = GetD()->GetA()->GetB()->GetF()->GetG();
◦ CEH면 간단하기 얻음
EX) ptrG = GetFirst<G>();

11.  CEH 관리자 클래스
◦ 호출 그래프와 실제 호출 순서를 관리자 클래스가 제어
◦ 코드의 행동방식에 대한 자료를 원하는 형태로 출력
 필자는 GraphViz 사용해서 코드가 연결되고 실행되는지를
한 눈에 볼 수 있는 그래프를 얻음

12.  계통구조 그래프를 운행하는 도중에 수행하기 매
우 위험한 것들
◦ 갱신 단계에서 계통구조를 변경(삭제,삽입,생성)하면 심
각한 문제 발생
 대기열등에 모아두어 갱신 단계 끝에서 실행
 추가적인 보호막의 도입

13.  코드를 일관된 패턴으로 구축
 갱신 순서를 쉽게 수정
 자기조사 기능을 이용해서 객체 인스턴스등을 쉽
게 찾음
 코드의 실행 순서와 계통구조를 가시화하기가 간
단

14.  코드만 봐서는 어떤 일이 일어나는지를 파악하기
힘듬
◦ 갱신순서가 동적, 소스코드를 조사하는 것은 도움이 안됨
 CEH와 잘 맞지 않는 코드도 있음
◦ 간단하고 유연하지만 틀에 맞지 않는 기능성은 있음
 CEH 적용 단위의 크기를 세심하게 설정하여야 함
◦ 파티클이나 비슷한것들에게는 CPU와 메모리 낭비가 심
해 적절한 조율이 필요
 CEH를 사용하는 도중 계통구조를 수정하면 심각
하고 찾기 힘든 버그가 발생

15. 감사합니다.