Open capnkenny opened 2 years ago
What would the implications of this be on the rendering interfaces and implementations I would have to maintain?
That is purely dependent on how far we want to go with the implementation, afaics.
For this instance, as long as no GLFW specific code is in the Graphics.Vulkan namespace, this would just require (in theory) adding a Windowing.SDL
variant that can provide whats needed for the window context, and then allowing the default rendering system to pick SDL over GLFW in this case. Maintenance should be lower cost here, however YMMV with the other interfaces since.. they don't exist just yet 😆 (DX12 and Metal are supported though so in theory it's the same cost)
Another instance is implementing a high-level renderer (akin to OGL) - this is clearly much higher cost initially, since it'd require a whole new Graphics subset and RenderingSystem, but I can't speak on maintenance unless we know how we're rendering (letting SDL manage the rendering work vs. writing OpenGL/ES/D3D9-11 code are two completely different strategies and therefore costs)
I can take this one
I'll take it
Priority: Low
Details: As the title suggest, we may want to look into utilizing SDL2 after MVP as another possible backend for NovelRT, akin to how GLFW/OpenAL are backing it today.
Mainly, using SDL2 as a backend would allow for potentially streamlining porting to non-desktop devices and also potentially open up avenues we can explore for implementing other graphics libraries with/without doing explicit development for them.
In the case of more adaptable porting - for example:
In the case of additional graphics libraries:
In any case, I think there's a multitude of reasons (seeing SDL2's versatility) as to why we might want to implement it as a supported backend. With that said, however, it's certainly up for discussion as to if/why/how we would support it.
Also, very open to outside feedback here if anyone has thoughts! (Is this needed/wanted? Any issues foreseen? etc.)