Handling Complexity with Other Graphic APIs

[Just-Feeshy]

**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.

**

[player-03]

A promising start.

I wonder if we could find a more descriptive name for Definitions.h, though. GraphicsAPI.h? RenderBackend.h?

[Just-Feeshy]

That's a good idea!

[loudoweb]

Great! Looks interesting!

What is the easier way to test Vulkan with Lime?

[Just-Feeshy]

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)