Replace Renderer::API switch case construction with RenderAPI factory like construct

[RamDav]

Currently all RendererAPI dependent constructions, e.g. VertexBuffer::Create are Implemented as static functions in the respective Base class implementation with a switch case statement for each RendererAPI.

Could this be implemented on a factory like pattern?

RendererAPI defines a virtual function virtual inline CreateVertexBuffer(..) { HZ_CORE_ASSERT(false, "Create Vertex Buffer Not implemented in RendererAPI") }

These would have to be implemented as override in each RendererAPI (OpenGLRenderAPI):

virtual inline CreateVertexBuffer(...) override { return CreateRefOpenGLVertexBuffer(...); }

Renderer would have to implement the method

RendererAPI GetRendererAPI() { return RendererAPI::GetRendererAPI(); }

and RendererAPI::GetRendererAPI returns a references to the current RendererAPI

The respective VertexBuffer Base class could then implement the static Create function like this:

Ref<VertexBuffer> VertexBuffer::Create(uint32_t size) { return Renderer::GetRendererAPI().CreateVertexBuffer(...) }

This would remove the RendererAPI dependant switch case code in the VertexBuffer class and would allow for certain RenderAPI to implement or not implement certain parts in a centralized location, the RenderAPI Implementation of this platform

[reductor]

Instead of having not implemented in the base it should just be pure virtual so new functions are easily detected for implementations and the implementation case be explicit about what it does not implement.

This likely also makes it easier if at some there is a desire to move it to a compile time define interface as the API interface you provide can be easily aliases to the actual implementation for ease of devirtualization.

Not to mention the potential performance improvements of using a virtual interface compared to a switch

I think when taking this approach it should also be considered where the virtual interface should live and if the there should be a split between the backend and frontend rendering API to make it easier for threading the rendering later.

[RamDav]

The reason to have it implemented in the base class is having a way to not implement the factory in another RendererAPI so it would still compile with an experimental build and run as long as this feature was not used. The other way to use this with pure virtual would be to have a save mechanism that all the functions are implemented in the new RendererAPI and it would have to generate an exception on a not implemented/supported factory