18.Resource사용한 삼각형 출력/ResourceManager/SPtr,Entity,Resource 위치 변경/RBT operator[] 변경

1.Resource사용한 삼각형 출력

이전 시간에 기존의 CDxDevice Render 함수에 통째로 있던 코드를 Mesh,Shader로 분리하는 작업을 했다.

이번에는 분리된 Mesh,Shader를 이용해서 CDxDevice 에서 출력하도록 테스트 해봤다.

 

테스트할때 미세하게 틀린 부분이 있었는데,이것때문에 좀 시간을 잡아먹혔다.

vertex buffer 정보 설정. *m_VertexCnt 안해줌.

아무튼 성공!

DxDevice - InitDevice()

DxDevice - Render()

출력 잘 됨.

2.Resource Manager 만들기.

 

Resource Manager

원래 Engine에 위치 시키려 했는데 Resource 들에 대한 헤더 정보가 필요하기 때문에 문제가 발생한다.

그래서 Renderer 로 위치를 변경하도록 함.

 

FindResource

typeid 로 비교할때 hash_code를 쓰는 이유는 객체 자체를 비교하는 것보다 hash_code로 나온 정수를 비교하는게 더 빠를 수 있다.

 

template 특수화

그런데 dll 이다보니 template 특수화를 해줘야하기 때문에 위의 함수를 사용하지 못한다.

 

특수화

사용

DxDevice.cpp - InitDevice()

ResourceManager를 생성해서 Resource 등록한다.

DxDevice.cpp - Render()

ResourceManager를 통해서 Resource 찾아서 함수 호출.

3.SPtr,Entity,Resource 위치 변경 및 namespace General 추가.

옮긴 이유

첫번째, rokaSTL_Lib.lib 에서 해당 정보가 필요하다.

renderer.dll - ResourceManager

ResourceManager 구현 도중  내가 구현한 map을 사용하기 위해서는 STL.lib 쪽에서 해당 정보들을 알고 있어야 했다.

STL.lib라고 이름을 지었지만 이는 잘못된 이름이다.

생성 의도는 공용 라이브러리로 모든 dll 에서 정보를 이용할 수 있도록 하기 위함이다.

하지만 lib측에서는 Renderer의 정보를 알지 못하기 때문에 템플릿 클래스가 못만들어진다.

그렇다고 lib에 Renderer.h 정보를 넘겨주는거는 구조가 이상해 진다.

 

두번째,SPtr과 Entity, Resource의 경우 모든 라이브러리에서 사용하고자 하면 사용할 여지가 있다.

Engine 또는 Client에서 Resource 가 필요할때 SPtr<Mesh> resource 와 같은 형태로 받을 것이기 때문이다.

물론 사실 17의 작업 내역을 보면 나오는 dll 간의 관계도를 보면 renderer->engine->script 이런식으로 엮여있어서 

굳이 이렇게 하지 않아도 저런 형태로 호출이 가능할 것이다.

 

하지만 첫번째 이유와 두번째 이유를 생각했을때 어디가 더 적절할까 생각해보면 STL.lib에 위치 시키는게 적절하다고 판단했다.

 

 

 

4.RBT operator [] 값 못찾았을때 에러 대신 nilnode->data 반환.

ResourceManager에서 AddRes 함수를 보면 이미 동일한 키값으로 등록된 객체가 있는지 검사를 한다.

이때 nullptr이 반환되어야 비교가 가능하기 때문에 변경해주었다.

ResourceManager.h

 

RBT.h