domme / fancy Goto Github PK

The EASTL is generally considered to be a better fit for high-performance applications such as games and renderers than the STL. However, at this point, we already have some select specialized containers. The main thing missing is a kind of "hybrid array" that could replace many/all usages of static and dynamic arrays since the avg. number of elements is usually known in most places.

We don't have much visual things to show yet - just some small test-projects that are meant for continous testing of the underlying API. We should add a small benchmark example project to change that. In its first iteration, it could be a simple scene with basic PBR lighting. In the future, it could be used to incorporate more and more features and eventually becomes a dedicated project that can be separated from FANCY and just uses it as a library.

Vulkan needs the same kind of linear memory allocator that is already in place for DX12. The memory visualization example should also be updated to suppport Vulkan

In order to support e.g. mapping a resource after it has been written by the GPU, we need to know on which fence to wait before reading the resource's data on CPU.

The rendering-files are currently contained in fancy_core. This is somewhat ugly from a code-architecture standpoint and also increases compile-times because the precompiled header needs to be recompiled frequently.

We might need to recompile some dependent libraries for that to work (mainly assimp?)

The current approach to Allocate/Free commandContext-pointers is error-prone (e.g. when forgetting to free a context) and smells a bit like C in a C++ environment.
Maybe refactor it to directly allocate / free the internal context-resources in the constructor/destructor?

At the time of writing, there can only be one single vertex buffer that assumes the same layout and binding as expected by the shader. We should add a way to specify vertex-buffer sources on the API-level and also support instancing.

Resources should only be re-bound if their CPU-side shadow-state change. The implementation in the DX12/Vulkan commandlist should roughly follow the same code-style and naming conventions.

Rather use the actual types to avoid a confusing mix & match in the code.