East Agent's Blog

The Brain Dump: Adding functionality to threaded subsystems으로부터 트랙백

Nebula3의 Feature과 프로퍼티

Nebula3에서는 프로퍼티(property) 시스템과 메시지들이 각각의 모듈에 종속되어 있다.

해당 모듈은 다음의 세 가지이다.

• basegamefeature
• graphicsfeature
• physicsfeatue

basegamefeature에는 게임 엔티티와 관련한 내용들이, graphicsfeature 에는 렌더링과 관련한 내용들이 마지막으로 physicsfeature에는 충돌 및 이에 따른 물리 반응과 관련한 처리들이 포함된다.

예를 들어 MoveTo 메시지는 basegamefeature 시스템에 속해 있고, CameraFocus, SetAnimation 등의 메시지는 graphicsfeature 시스템에, 그리고 ApplyImpulseAtPos 메시지등은 physicsfeatue 시스템으로 각각 분리되어 속해 있는 것이 Nebula2와는 다른 점이다. (Nebula2에서는 모든 메시지는 msg 폴더 내에, 그리고 property 들은 properties 폴더 내에 위치해 있다)


Nebula3 멀티 쓰레드 시스템과 메시지 시스템

Nebula3의 멀티 코어 시스템이 메시지를 통해서 구현되는 점으로 미루어 보면 위의 세 시스템은 서로 각기 다른 코어를 사용하는 시스템으로 예상된다. 즉, ___feature 별로 하나의 코어를 사용하지 않을까 생각된다. 일반적으로 코어당 복수개의 쓰레드 사용이 가능한데 경우에 따라서는 이를 이용해서 시스템 내에서 다중 쓰레드를 사용하는 방법도 고려해 봄직하다. 예를 들어 graphicsfeature 시스템 내에서 렌더링 모듈과 그림자 모듈을 두 개의 쓰레도로 분리해서 처리하는 것이다.

예를 들어 디버깅 메시지 혹은 디버깅 객체(shape)를 렌더링하는 시스템을 살펴 보면 이를 두 개의 모듈로 구분해서 처리한다.

1) 디버깅 메시지나 디버깅 객체에 대한 정보를 처리하는 모듈
2) 이를 렌더링 하는 모듈

이 두개의 모듈은 별도의 쓰레드로 각각의 처리를 한다. 여기까지는 큰 문제가 없다. 그런데 두 개의 쓰레드로 구분하는 경우 두 쓰레드간의 동기화의 문제가 발생한다. 하나의 쓰레드로 처리할 때 처럼 sync가 맞아 떨어지면 아무런 문제가 없겠지만 그렇지 않은 경우에는 문제가 발생한다.

1) 디버깅 정보 처리를 하는 모듈 > 렌더링 모듈
이 경우에는 디버깅 정보에 대한 메시지를 프레임마다 렌더링 모듈 쪽으로 전달해 주지 못하므로 실제 화면에서의 디버깅 정보가 깜박이게 된다.

2) 디버깅 정보 처리를 하는 모듈 < 렌더링 모듈
디버깅 정보에 대한 메시지 처리는 한 프레임에 한번의 렌더링으로 족하지만 디버깅 정보 처리를 하는 모듈의 프레임 레이트가 렌더링 모듈보다 높은 경우 디버깅 정보 처리에 대한 메시지가 필요 이상으로 발생하게 되여 불필요한 디버깅 메시지의 렌더링으로 퍼포먼스 저하(overhead)가 발생한다. 디버겅 메시지 렌더링은 렌더링 한 프레임 당 한번만 처리하면 되는데도 말이다. 그러므로 디버깅 정보를 처리하는 모듈에서는 메시지를 바로 렌더링 모듈로 전송하지 말고 렌더링 모듈의 프레임을 고려해서 필요한 메시지를 한번만 전송하도록 처리해야 한다.

이상 두 가지의 문제점에 대한 해결이 Nebula3의 멀티 쓰레드와 메시지 시스템의 핵심이다.

메시지 시스템에 대해서 한 가지 덧붙이자면 이 메시지는 NIDL(Nebula Interface Define Language)로 정의된다는 것이다. 이것은 XML에 생성해야 할 메시지를 정의하면 컴파일러에서 빌드시 NIDL 툴(idl.exe라는 별도의 nebula3 in-house 툴이 있다)로 지정된 XML을 읽어 들여 메시지에 대한 소스 코드를 자동으로 생성하게 된다. 즉, 메시지는 손으로 코딩하는 것이 아니라 미리 정의된 형식을 통해서 XML에 정의하면 이를 NIDL 툴을 사용하여 자동으로 생성하는 방식을 사용한다.