19.Script ReLoad 버그/Manager/빌드 종속성/ConstBf,Transform/namespace , DLL간의 종속성을 줄이기 위한 생각.

0.Script ReLoad 버그 생김 고치기.

Engine.dll - CScriptReLoad

Script 재 빌드 하기 전에 Dll 해제를 안해줘서 발생한 버그임.

또 Dll 해제 후 재 빌드를 했으면 다시 Load 해 놓도록 했음. 

Load에 실패하면 경고 메세지 출력.

 

ReLoad 잘 된다.

 

ReLoad 조건 1) application focus가 해제되었다가 다시 focus in 되었을때 Script 변경점을 조사한다.

              조건 2) time stemp 가 달라졌다면 변경점이 있다는 것으로 script를 다시 빌드해서 load 한다.

인데 현재는 조건 2가 아니어도 조건1만 충족되면 해당 함수가 호출되도록 했다.

나중에 코드를 더 구현하고도 문제가 없다면 해당 부분은 지울 예정.

 

콘솔창이 로딩 끝나면 사라지길 바라면 아래 사진에서 pause 부분을 지우면 됨.

Engine.dll - CScriptReLoad

 

추가로 Engine 이 Release 될 때 FreeDll() => Dll All Free 를 하는데

이때 만약 이때 Dll이 nullptr 이 아닌지 검사를 한 뒤에 Free 하도록 변경함.

 

1. Manager들의 위치를 옮김.

ResourceManager를 어디에 위치시킬까 고민하다가 만약 내가 컨텐츠를 구현한다면 RokaProj에서 구현할 것이다.

그럼 Engine 에 관련된 매니저들은 Engine에서 초기화 하는게 맞다는 생각이 들어서

MainManager에서 하던 초기화 하던 Manager 를 Engine에서 하도록 했다.

LoadDllManager 는 MainManager에서 해야함.

Engine.dll CRKEngine.h

Engine에서 생성(CreateManager)하는 Manager는 Engine에서 초기화(InitManager)

변경전(위)/후(아래)

변경된 코드

Init에서 MonitorSize 함수로 화면 사이즈 설정해놓는 함수 호출이 있어서 위에서 먼저 호출했다.

그런데 바뀐 구조에서는 engine과 device가 서로를 참조해야 Initmanager 할때 오류가 발생하지 않기 때문에
SetHWND 내부에서 HWND 가 Main Type 이면 해상도 정보를 저장하도록 했다.

1-추가: 빌드 종속성 변경해줌

원래 종속성 설정 안해줘서 따로 따로 순서대로 빌드해줘야 했는데
종속성 순서를 지정해줘서 솔루션 빌드하면 순서대로 빌드됨.

2.ResourceManager Init에서 Triangle,Rect,Circle Mesh 만들기.

Triangle Mesh

Circle Mesh 사용.

3.ResourceManager 객체 생성 및 여러 dll 에서 쓸 수 있도록 참조 해놓기.

는 1번 하면서 처리함.

 

4.Struct - ConstBuffer , Component - Transform

만드는중..

Renderer.dll - global.fx

Engine.dll - Transform.h

5. namespace 호환성 문제

나는 Engine 의 경우 RKEngine 이라는 namespace를 쓴다.

그런데 만약 RKEngine 이 아닌 다른 엔진으로 변경하지만 Script.dll 에 대한 호환성은 좋았으면 좋겠다.

 

이럴때는 이렇게 구현한다.

class IScript
{
public:
...
}

AEngine.dll

namespace AEngine
{
 class CScript : public IScript
 {
 }
}

BEngine.dll

namesapce BEngine
{
 class CScript : public IScript
 {
 }
}


Script.dll

IScript* GetScript(){return m_Script;}

Script.dll 에서 이런 부분이 맘에 안들었음.

이러한 Interface 는 공용 공간에 넣는게 좋을 것 같다.

만들어야 할 것 - IScript, IEngine, IDevice 등..

근데 이렇게 하려는 이유가 종속성을 줄이기 위함인데  그럼 해줘야 할게 너무 많은데 다 일일히 interface 화 해줘야 하는건가?

Engine.dll 종속적인 예시..

 

 

생각을 좀 해봤는데 

const buffer를 예시로 들면 Engine,Renderer,Script 모두 필요할 수 있다.

이런 경우 공용 공간에 배치하는게 좋을 것 같다.

 

또, 현재 Engine,Renderer,Script 모두 rokaSTL_Lib.lib 를 링크하는데

이러면 각 dll 마다 개별적으로 코드가 붙는 것이기 때문에 메모리 낭비가 심할 것이라 생각한다.

 

따라서 rokaSTL_Lib.lib 에는 진짜 template library 만 놓고 (Singleton, MemoryPool, Queue,Map .. )

공용 데이터를 관리하는 dll 을 만들도록 한다.

그곳에 Interface와 enums,struct 등을 넣도록 한다.

 

근데 또 생각해보면 유니티는 각 Script들을 빌드해서 .dll 로 만든다고 알고있는데,

거기서는 dll 임에도 namespace를 Unity로 딱 특정해서 쓰는데 굳이 바꾸지말고 사용해도 되지 않을까?

아니면 만약에 내가 자체 엔진 쓰는 게임회사인데 기존에 쓰던 Engine을 새로 구현한 Engine으로 교체할 수도 있다고 생각해서 interface화 하는게 맞을까?

고민을 해봤는데 Unity는 상용 엔진이고 나는 자체 엔진이니 2번째가 옳은거 같다.

마비노기를 봤을때 자체엔진 -> 언리얼로 교체하는 것처럼 확 바뀔 수 있으니까..?

Renderer는 Dx -> OpenGL로 바뀔수도 있고..

그게 아니어도 Dx11 -> Dx12 로 버전 업 할 수도 있는거고..

 

6.Interface 할 목록

Engine 

Engine

Component

Transform 등의 모든 컴포넌트

Script

ScriptReLoad

 

 

Renderer

Device

Resource

Mesh

Shader들

Material

ResourceManager

Script

의 경우 Engine에 종속적일 수 밖에 없을듯.

Script 상속을 받기 때문에..

그리고 Engine과 Renderer는 생성될 경우의 수가 정적이지만 ,

Script 는 얼마나 생길지 모르는데 모두 interface화 할 수 없음.