Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
> He has Vulkan support in here with a clearly marked file named Pipeline.cpp. The guy knows what a pipeline is...
There is a Vulkan API wrapper. However, there is no "Vk Renderer" -- no code seems to use the Vulkan parts of the code system, and the two projects seem unrelated.
> * Is this not a UBO interface?
There are ways of making a uniform buffer, however the examples don't cover them and the API doesn't adapt automatically. See how all of the setters assert if UBOs are enabled.
https://github.com/mosra/magnum/blob/cfc02599e54e02337dd56bb...
> * I don't see why you think there's limited support for multiple framebuffers...?
The code I do see is about binding/unbinding framebuffers in a stateful manner, e.g. AbstractFramebuffer::bind(), rather than supporting passes.
> None of your criticism seem well intentioned. It might behoove you to give people the benefit of the doubt and realize that you may be able to learn something from them, even if they're so clearly inferior to you.
To put it simply, I've taught enough graphics to know first-hand the kinds of misconceptions that OpenGL-styled APIs can cause, and I'm just a bit tired to see it continue. Admittedly I was a bit harsh, I don't mean any harm towards the author. There are just graphics APIs with interfaces I consider to be much better designed.
Some other interesting libraries I've seen along these lines:
- Sokol (sokol_gfx in particular): https://github.com/floooh/sokol
- wgpu (see wgpu-native for the C API): https://github.com/gfx-rs/wgpu
It kind of seems like graphics abstractions for modern hardware are getting pretty "figured out". There are wrappers that work for most DirectX/Metal/OpenGL applications so they can run just about anywhere, and new 2D/3D applications have a lot of accessible/open-source options to build on top of. Projects like Mesa's Zink will centralize the burden of maintaining legacy APIs away from hardware manufacturers. The future looks bright.
Some other interesting libraries I've seen along these lines:
- Sokol (sokol_gfx in particular): https://github.com/floooh/sokol
- wgpu (see wgpu-native for the C API): https://github.com/gfx-rs/wgpu
It kind of seems like graphics abstractions for modern hardware are getting pretty "figured out". There are wrappers that work for most DirectX/Metal/OpenGL applications so they can run just about anywhere, and new 2D/3D applications have a lot of accessible/open-source options to build on top of. Projects like Mesa's Zink will centralize the burden of maintaining legacy APIs away from hardware manufacturers. The future looks bright.
Check out gunslinger, a pure C99 game framework, with a very clean design.
The development has been making huge strides and they have a fairly active discord channel:
https://github.com/MrFrenik/gunslinger
Gunslinger does have many interactive demo apps that can be run in the browser via the webassembly target. This includes a clone of Snake and another sample game. https://mrfrenik.github.io/gunslinger
The same code can be compiled natively as well. https://github.com/MrFrenik/gs_examples
Related posts
- GPU Compute in the Browser at the Speed of Native: WebGPU Marching Cubes
- 3D and 2D: Testing out my cross-platform graphics engine
- Warp Terminal is now available for Linux
- Building the DirectX shader compiler better than Microsoft?
- Pikchr: A PIC-like markup language for diagrams in technical documentation