#Simple low-level graphics library

1 messages · Page 1 of 1 (latest)

brave ember
#

Low-level graphics API that supports multiple multiple back-ends (Vulkan, OpenGL, WebGPU, etc), with an emphasis on being dead simple to setup and use.

Only support the most-common shader setups:

  • Drawing colored geometry
  • Textured geometry / images
  • Colored text and icons (I.e 1 Channel images with color assigned per mapping)

Additionally, you could specify some basic options:

  • Z-culling (Whether to include z coordinate in vertices and setup a depth buffer)
  • Desired Anti-aliasing level
  • Image blitting (scaling) method

NOTE: This could all be turned on and off at compile time and runtime.

Example: You enable generation of anti-aliasing code, but allow the user to toggle it on and off at runtime.
Example: You disable generating code for textured geometry, because you know you'll only need text / icons + colored geometry

Why write instead of using a pre-existing library?

  • This should be a super simple, low effort library, and having something written in Zig would reduce friction of getting something compiled and running.
    I believe both Odin and Jai have simple to use graphics APIs in this spirit

  • I think comptime would absolutely shine here. As described above, you could omit generating code for certain features and generate quite efficient code.
    As such it could be used for writing high-quality, efficient applications, albeit ones that have simple requirements in regards to graphics.

If enough people are interested I could actually write this myself (At least with an initial Vulkan back-end), because I'm currently working on the renderer in Reel anyways to create a dedicated draw pass for icons / text. It wouldn't be a tonne of extra work to extract it into a standalone library.

gritty void
#

can't mach core do most of that?

brave ember
#

I think mach core is more low-level, basically a wrapper around WebGPU. It has to be because it's aimed at covering all use cases.

#

And then Mach engine is high level

#

So you could say this sits in between. Also things like input, etc are out of scope here

dark bone
#

zero-graphics has parts of this as well, based on OpenGL ES 2.0, but also has a bigger scope

#

what would the target platforms?

brave ember
#

I guess I didn't convey the scope very well. Here's a general idea of what I was thinking the api would look like. A Renderer type that's comptime generated (i.e fn Renderer(options: Options) type), three draw functions (i.e drawQuadColored, drawImage, drawIcon ), a way to add, remove and modify textures, a recordRenderPass and a presentSwapchain function. It would end up being more than that, but that's the gist of it.

No text support, no window creation, no input support, etc. It would be as cross-platform as the graphics back-end you're using.

#

That being said, maybe OpenGL is simple enough to make this redundant.

steady flame
#

i dig it and have d3d11 and webgl code for this

#

send me the API stubs (imagine a C header file) and I'll fill them out for these platforms

#

let's call it zigdraw where the logo is a nice fat crayon with a big ole zig logo on the side

#

could make a site like shadertoy where you have codemirror on one side, rendered output of zigdraw on the other

(the code in the codemirror widget compiled with zig compiler compiled to wasm, compiling wasm 😉)

hollow flax
#

hahaha

calm thorn
#

been thinking about implementing a vulkan renderer in zig for a minute, i need to learn vulkan for my job so maybe i could even get paid to do it

#

the cross-backend thing is a much bigger ask though

#

WebGPU/Vulkan/DirectX are much more similar and could probably be faiiiirly simply wrapped in the same way, but openGL is way different (and if I'm not mistaken, metal too)

#

if there was an opengl backend then compiling with that would just remove half the features of the library since opengl wouldnt support them

hollow flax
#

you can do it

calm thorn
#

yeah but vulkan has beeg optimization improvements

#

id prefer to just leave opengl as not an option

hollow flax
#

That's fine

#

I would make an opengl render as a "legacy" renderer

#

=V

steady flame
#

opengl version turn off half the features

dude what

#

most basic shader options

this isn't sokol. this is much more limited

calm thorn
#

oh sorry i guess i didnt read ur proposal very well

#

yes this is a good and cool idea and could support all backends

steady flame
calm thorn
#

bruh