D3D12 래퍼 설계에 대하여 #2
2024. 2. 8. 20:46ㆍPot of Thoughts/Fragments of Think
기존 설계로는,
Wrapper::Ctor(Device, params...) 와 같은 식으로 객체를 생성했다만, 내부적으로 결국 Device의 네이티브 인터페이스인 ID3D12Device~을 GetNative로 받아와서 내부 객체를 생성해주는 방식이였다. 다만 이렇게 되면 API 설계에 대한 사견 #2, API 설계에 대한 사견 #3 에서의 2가지 아이디어를 위반한다.
변경할 설계,
Device 래퍼가, 기존 ID3D12Device의 책임을 그대로 이어 받도록 할 것. 즉 Device 래퍼 클래스가 명령어 할당자, 명령 목록, 명령 큐, 리소스 등등.. 을 생성/할당하는데 직접적으로 사용되도록 한다.
예컨데, Device::CreateFence(...) 와 같이.
기존 ID3D12Device와의 차별점은 기본 값, 내부적으로 캐싱 지원, 로깅, 에러 핸들링을 목표로 하고자 한다.
'Pot of Thoughts > Fragments of Think' 카테고리의 다른 글
StaticTransformTag (0) | 2025.02.06 |
---|---|
언리얼에서 활용한 Skeletal Mesh를 Blender FBX Export를 할 때 (0) | 2024.11.23 |
API 설계에 대한 사견 #3 (0) | 2024.02.08 |
API 설계에 대한 사견 #2 (1) | 2024.02.07 |
D3D12 래퍼 설계에 대해 #1 (0) | 2024.01.27 |