Mach Engine: The Future of Graphics (With Zig)

https://devlog.hexops.com/2021/mach-engine-the-future-of-graphics-with-zig

by ArtWomb • 5 years ago

138 39 5 years ago

devlog.hexops.com

ArtWomb• 5 years ago

Everyone's building on the "bigg" (bgfx + imgui + glfw + glm) stack ;)

https://github.com/yuki-koyama/bigger

slimsag8• 5 years ago

author here, I do think that's a reasonable choice of tech in general, but I won't be using most of those for Mach for various reasons:

* glm -> zig has native vector types with SIMD support and I think in the long-term these could be much nicer.

* bgfx is truly awesome, but I'm keen to is WebGPU for the reasons outlined in the post.

* imgui - I do think it's the best thing out there currently, but I have something up my sleeve for a much better UI library built around vector graphics and have done a lot of research in this area.

vg_head• 5 years ago

I am really interested in your research related to vector graphics!

AndyKelley2• 5 years ago

re: zig's SIMD vectors - I would caution you to do some proof-of-concept with some perf testing because as I understand it, these are more well suited for doing bulk operations on a large array of things, rather than for modeling linear algebra.

For example, if you had 100 PointA objects and 100 PointB objects and you wanted to compute the midpoint of all of them in an output array, you would use SIMD vectors to represent, e.g. 10 X values at a time, and 10 Y values at a time, and then do the math on that, rather than to represent each Point as a separate vector.

But that's just something I heard, of course real world experience would be interesting to hear about.

flohofwoe• 5 years ago

(disclaimer: shameless plug) Here's another cross-platform alternative, auto-generated Zig bindings to the Sokol headers:

https://github.com/floooh/sokol-zig

This is quite a bit slimmer than using one of the WebGPU libraries like wgpu-rs or Dawn, because sokol-gfx doesn't need an integrated shader cross-compiler (instead translation from a common shader source to the backend-specific shader formats happens offline).

Eventually I'd also like to support the Android, iOS and WASM backends from Zig (currently this only works from C/C++, for instance here are the samples compiled to WASM: https://floooh.github.io/sokol-html5/)

And finally, I'd also like to become completely independent from system SDKs for easier cross-compilation, but with a different approach: by automatically extracting and directly including only the required declarations right into the source files instead of bundling them into separate git repositories (similar to how GL loaders for Windows work).

slimsag8• 5 years ago

very cool work :) If you like, add a screenshot or two and I'll include this in the next zigmonthly.org article

you might also be interested to know about stub dynamic libraries, e.g. `.tbd` files on MacOS. That's what is in the Mach SDK repos primarily[0], though I'm sure you could slim them down some more with a concrete list of symbols you depend on.

[0] https://github.com/hexops/sdk-macos-11.3/blob/main/root/Syst...

politician• 5 years ago

I love this codebase. I’ve been working with it on the side for a few weeks: it’s extremely well documented, supports Metal, has reasonable abstractions that don’t try to be the One True Way, and the Zig port looks really clean.

Lerc• 5 years ago

There's a lot of talk on what platforms it supports (or plans to) and how it intends to achieve that. That's nice but what will it actually provide?

Does it implement an interface like Raylib? Is it a scene graph? How about an entity component system? Will game logic and graphical representation be tightly bound or kept separate?

None of these things are necessarily good, bad, required or forbidden, but they're fairly important to know before you dive in.

slimsag8• 5 years ago

The project is only 4 months old :) I will get to those bits and explain my vision there once the groundwork is done.

In general, I have a preference of providing (1) solid groundwork, (2) libraries, and (3) extensive tooling. We're only at phase 1/3 :)

I don't want to _force_ one way of interacting with this, either. You're free to take the work I've done on making GLFW easy to use and build on top of that (several people are), same with the upcoming WebGPU work.

But yes, there will eventually be a graphical editor, component system, and "obvious" ways to structure your code if that's not something you want to choose for yourself.

yAak• 5 years ago

As a mobile dev, any effort to abstract away platform fragmentation craziness is highly commendable in my eyes. Excited to see where this takes you!

jakearmitage• 5 years ago

This effort seems to be born out of frustration with build systems for cross-platform engines, not really with the engines.

LordRishav• 5 years ago

Perhaps the name can be a little problem, due to the existence of the Mach kernel (https://en.wikipedia.org/wiki/Mach_(kernel)). Nevertheless, the toolkit does look great.

Ono-Sendai• 5 years ago

The future of graphics, can render 1 red triangle.

Zecc• 5 years ago

Was it supposed to be a black triangle?

https://rampantgames.com/blog/?p=7745

baxuz• 5 years ago

So WASM seems to be in a good place when it comes to code portability and performance, and now WebGPU does as well.

It's great to see how the web is giving back to the native platforms.

ksec• 5 years ago

DirectX 13 is coming by the end of 2022.

Is that confirmed? I cant search anything official and Windows 11 was suppose to be the moment they could do DX13 ( DX12 Ultimate was a naming madness ). But they didn't.

Mach Engine: The Future of Graphics (With Zig)

Related Stories