Open EriKWDev opened 2 months ago
Actually, I was wondering why the rendering portions aren't being done with wgpu - wouldn't it be easier and more portable?
It would also solve the issues with post-processing only being implemented for OpenGL without having to write separate shaders.
The goals of miniquad are not strictly ease of implementation, but rather to use what the operating systems already provides us and to avoid dependencies to a great extent to keep compile times rapid.
I can also relate to the joy of having complete control over as much as possible, as well as to the satisfaction of knowing how to implement all this stuff.
The nice thing about my proposal here is that having a tiny platform abstraction for input handling and window control, rendering abstractions like the one miniquad provides could be implemented on top of it be it with OpenGL/Metal/Vulkan/Wgpu etc
There was a recent commit with WebGL2 support, by the way. And in my current project, I'm using naga to translate spirv to glsl 300 es (or presumably could also translate to metal) for shader portability. Naga is adding about 650k of weight in my stripped down wasm, but it's nice to have shader portability.
I love the minimalistic approach you have to library design with all the quad- and nano- crates.
winit
is a huge library currently and miniquad provides everything I need for input handling and window opening, it is however tightly coupled to OpenGL context creation, Metal, as well as the abstraction provided on top of that.It would be awesome to be able to have the windowing and input layers of miniquad without the graphics abstraction so that one could still chose something differnet like Vulkan or WGPU.
Would it be of interest to perhaps separate these parts of miniquad into its own crate while still providing low-level api enough so that miniquad can be implemented on top of it?