Closed Just-Feeshy closed 3 months ago
A promising start.
I wonder if we could find a more descriptive name for Definitions.h, though. GraphicsAPI.h? RenderBackend.h?
That's a good idea!
Great! Looks interesting!
What is the easier way to test Vulkan with Lime?
Great! Looks interesting!
What is the easier way to test Vulkan with Lime?
The easier way I found was by putting these macro definitions (This is the sudo code for the example). It won't conflict with OpenGL bindings when using Vulkan or any other Graphics API.
#ifdef LIME_VULKAN
#define Context std::shared_ptr<lime::vulkan::ContextVulkan>
#define CreateContext lime::vulkan::GraphicsHandler::CreateContext
#define DeleteContext lime::vulkan::GraphicsHandler::DestroyContext
#define MakeCurrent lime::vulkan::GraphicsHandler::MakeCurrent
#define SetSwapInterval lime::vulkan::GraphicsHandler::SwapInterval
#define GetDrawableSize SDL_Vulkan_GetDrawableSize
#define WINDOW_GRAPHICS SDL_WINDOW_VULKAN
#define SetAttribute EMPTY
#define SwapWindow EMPTY
#endif
While these macro definitions significantly contribute to the solution, further steps must be undertaken to implement it entirely, but I believe this is a promising starting point.
(This is a repost with the quote reply)
**I plan to extend capabilities beyond OpenGL to new potential graphic APIs like Vulkan, DirectX, or Metal. As the first step, I plan to make the backend more modular using macro definitions. To showcase the concept, I've applied these changes in my project using a forked version of Lime called: lib-lime-project. This allows my project beyond GL APIs and paves the way for new graphical interfaces.
For illustration, please look at the following screenshot, where I've applied macro definitions for Vulkan.