Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mach v0.1: Cross-platform Zig graphics

devlog.hexops.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Mach v0.1: Cross-platform Zig graphics

#31

Post by slimsag »

ModernMech wrote: post #30
nightowl_games wrote: post #20

Earlier quoted context omitted.

> Mach looking a little more like an Unreal/Unity/Godot Right now, Mach is probably something more like Bevy, Magnum.Graphics or BGFX. ie: a _framework_. But your post alludes that that is not the goal. That Mach seeks to build asset importing, animation tools, navigation system, etc? ie: A FULL GAME ENGINE!?

I'm kind of new to game dev and I'm a little confused about the terminology you're using. You called Bevy a framework to differentiate it from an engine, but on the Bevy website they call themselves an engine. What would you say is differentiation between a framework and an engine?

I think the key difference in most people's eyes is: am I interacting with this mostly through code (framework), or is there a substantial amount of graphical tooling that aids me (engine)?

I'd say Bevy today is more akin to a framework, but they intend to add tooling etc. to become closer to an engine later on from what I understand.

framework engine is more of a spectrum.

Re: Mach v0.1: Cross-platform Zig graphics

#32

Post by modernerd »

slimsag wrote: post #28
modernerd wrote: post #16

Earlier quoted context omitted.

What do you think of Zig so far? How do you recommend people get into it, especially those who don't have systems programming experience? Should you learn C first?

I'm super productive in Zig, I really like the language. Documentation is lacking, so you're going to be reading the stdlib code. There are bugs. The current focus is on building the new stage2 compiler (going from C++ -> Zig implementation) so there are things that need attention that don't get it, yet. I would not suggest anyone learn C first if they don't have systems programming experience. I'd go for Zig, Rust (…

Thanks, this is helpful!

Zig appeals to me for its philosophy, simplicity, community and cross-platform build tools. The main reason I haven't already adopted it is the lack of docs/educational material that has made getting started pretty rough for a frontend dev. A lot of the existing docs seem to start with the assumption that you're a lifelong C hacker who is already comfortable with manual memory management, libc, allocators, linking and all the rest, and that you're coming to Zig to gain quality of life improvements over C.

I've dabbled with Rust/Go and found the docs/books much more accessible. But I didn't end up feeling an affinity for either language quite the same as Zig. (For Rust it was the complexity/readability and sluggish compile/dev loop; for Go it was the feeling that it wasn't really empowering me to do much that I couldn't already do quite comfortably with TypeScript/Deno, or stretching me to understand lower-level programming the way I'd hoped.)

Thank you for zigmonthly.org and for Mach! I just sponsored you on GitHub. It's encouraging to hear buzz around Zig and see it being used for fun things. I'm tempted to persevere with Zig and write docs/guides pitched at those outside the traditional systems programming realm as I gain confidence with it.

Re: Mach v0.1: Cross-platform Zig graphics

#33

Post by slimsag »

modernerd wrote: post #32
slimsag wrote: post #28

Earlier quoted context omitted.

I'm super productive in Zig, I really like the language. Documentation is lacking, so you're going to be reading the stdlib code. There are bugs. The current focus is on building the new stage2 compiler (going from C++ -> Zig implementation) so there are things that need attention that don't get it, yet. I would not suggest anyone learn C first if they don't have systems programming experience. I'd go for Zig, Rust (…

Thanks, this is helpful! Zig appeals to me for its philosophy, simplicity, community and cross-platform build tools. The main reason I haven't already adopted it is the lack of docs/educational material that has made getting started pretty rough for a frontend dev. A lot of the existing docs seem to start with the assumption that you're a lifelong C hacker who is already comfortable with manual memory management, lib…

Super excited for Zig to make low-level coding more accessible to people outside the usual group of lifelong C hackers, as you said! That's one of the reasons I am betting on it.

Check out https://zig.news too, it's where a ton of people are writing learning material / little tutorials on things.

Re: Mach v0.1: Cross-platform Zig graphics

#34

Post by gpanders »

HowardStark wrote: post #23
gpanders wrote: post #18

Earlier quoted context omitted.

Do you have experience cross compiling? If so, you’re likely familiar with the headache: getting the right tool chains, sysroots, compiler flags, libraries, etc. There are entire businesses and open source tools whose raison d'être is providing these tool chains and making the process simpler. With Zig, that all goes away. It’s as simple as saying `zig build -Dtarget=aarch64-linux-gnu` or `zig build -Dtarget=riscv32-…

Huh. From what you said and then a quick peek at the docs Zig does seem great in that regard, but in my own experience I’ve definitely found Rust to be equally competent. What about Zig would you say makes it better? Rust has `cargo build --target `

Admittedly I don’t have as much experience cross compiling with Rust, but my experience has not been so smooth. You need to install each target toolchain manually with rustup, and then some tool chains require different versions of Rust (e.g. the ESP32 RISC-V toolchain requires nightly). Another time I tried cross compiling on x86 Linux targeting Linux on ARM64, and I kept getting linking errors (or it couldn’t find an acceptable linker).

I certainly agree that Rust is much better than C/C++, but it’s not quite at Zig level, at least in my (limited) experience.

Re: Mach v0.1: Cross-platform Zig graphics

#35

Post by zamadatix »

HowardStark wrote: post #23
gpanders wrote: post #18

Earlier quoted context omitted.

Do you have experience cross compiling? If so, you’re likely familiar with the headache: getting the right tool chains, sysroots, compiler flags, libraries, etc. There are entire businesses and open source tools whose raison d'être is providing these tool chains and making the process simpler. With Zig, that all goes away. It’s as simple as saying `zig build -Dtarget=aarch64-linux-gnu` or `zig build -Dtarget=riscv32-…

Huh. From what you said and then a quick peek at the docs Zig does seem great in that regard, but in my own experience I’ve definitely found Rust to be equally competent. What about Zig would you say makes it better? Rust has `cargo build --target `

Cross compiling for the language itself is half of it, albeit a half Rust does decently well too, but Zig will also cross compile C/C++ for you just as easily. The latter part combined with Zig's focus on making it as 0 effort as possible to do either action is what results in it being talked about so much.

Re: Mach v0.1: Cross-platform Zig graphics

#36

Post by syntheweave »

ModernMech wrote: post #30
nightowl_games wrote: post #20

Earlier quoted context omitted.

> Mach looking a little more like an Unreal/Unity/Godot Right now, Mach is probably something more like Bevy, Magnum.Graphics or BGFX. ie: a _framework_. But your post alludes that that is not the goal. That Mach seeks to build asset importing, animation tools, navigation system, etc? ie: A FULL GAME ENGINE!?

I'm kind of new to game dev and I'm a little confused about the terminology you're using. You called Bevy a framework to differentiate it from an engine, but on the Bevy website they call themselves an engine. What would you say is differentiation between a framework and an engine?

While I've never seen it defined this way, I think the distinction comes down to this:

An engine deals with assets in depth, and exposes runtime abstractions to them.

A framework does what is necessary to expose I/O and load the assets, but aims to be minimally opinionated about how they integrate into the application.

For example, in an engine you might have abstractions for applying collision, physics, and rendering techniques onto an image asset, so that you can achieve a useful result just by configuring the data correctly. A framework would give you a way to load the image and display it, but leave it to you to add more detailed behaviors by writing new code.

In effect, engines are never totally done until you have a feature-complete application. Often it works out that you need a scripting layer to define a certain kind of asset(e.g. dialogue tree logic), and then what you have is an engine extension; if the asset is defined independently of the scripting system, it can be made portable to another engine.

Re: Mach v0.1: Cross-platform Zig graphics

#37

Post by modeless »

This is awesome! I was hoping someone would take WebGPU/Dawn and package it up in a form that is usable outside Chromium. Building it yourself is nontrivial.

Portable graphics has always been a big issue. Back in the day OpenGL was kinda sorta portable, but in practice that never worked out very well. Drivers were buggy, platforms came with different versions and different extensions, Windows didn't come with GL drivers by default, mobile had OpenGL ES which was different. And now Apple has deprecated OpenGL so the dream of portable graphics at the OS level is truly dead.

WebGL is the most portable graphics API that exists today, and it's actually possible to use it from native code if you want (using the ANGLE library) but I don't think anyone does, and that's understandable. WebGPU should be different. I think there are a lot of good reasons that native apps should consider using WebGPU.

Re: Mach v0.1: Cross-platform Zig graphics

#38

Post by rudedogg »

slimsag wrote: post #11

Author here, thanks for posting! Happy to answer any questions about Mach (or my experience working with Zig.)

Just wanted to say I love the style of your blog (especially the little diagrams), and am looking forward to future posts in the ECS series.

Also, I've played around with the mach-glfw-vulkan-example project (https://github.com/hexops/mach-glfw-vulkan-example) and really enjoyed using it to learn about Vulkan, so thank you for your part in that!

I think you make a good case for WebGPU, and am excited to look through the resources you shared – and the future of mach!

Re: Mach v0.1: Cross-platform Zig graphics

#39

Post by zRedShift »

HowardStark wrote: post #23
gpanders wrote: post #18

Earlier quoted context omitted.

Do you have experience cross compiling? If so, you’re likely familiar with the headache: getting the right tool chains, sysroots, compiler flags, libraries, etc. There are entire businesses and open source tools whose raison d'être is providing these tool chains and making the process simpler. With Zig, that all goes away. It’s as simple as saying `zig build -Dtarget=aarch64-linux-gnu` or `zig build -Dtarget=riscv32-…

Huh. From what you said and then a quick peek at the docs Zig does seem great in that regard, but in my own experience I’ve definitely found Rust to be equally competent. What about Zig would you say makes it better? Rust has `cargo build --target `

I use Zig and cargo-zigbuild to cross-compile my Rust projects. It simply works, without Docker, if I want it to use older GLIBC symbols for an embedded Linux target running an ancient kernel/glibc version, or if I want to cross-compile to an M1 Mac from Linux. Of course, you still need to provide all the pkg-config/libraries/headers for the target platform, but that’s simple enough.

Re: Mach v0.1: Cross-platform Zig graphics

#40

Post by defen »

bsaul wrote: post #2

i'm following zig's project from HN and i often see cross-compilation and c/c++ mentionned. Why is zig often mentionned in that context ? it seems that cross-compilation and C can be achieved using llvm/clang without a lot of problem ? What is zig accomplishing in that matter that makes it so special ?

Here's the problem statement in a nutshell. Consider the following trivial C program:

    #include 
    #include 
    int main(void) {
        unsigned char buf[10];
        ssize_t ret;
        ret = getrandom(buf, sizeof(buf), 0);
        if (ret != sizeof(buf))
            fprintf(stderr, "getrandom() failed\n");
        else
            fprintf(stderr, "getrandom() success\n");

        return ret != sizeof(buf);
    }
You have an x86_64 Linux machine running glibc 2.17. Your task is to compile the above program into a dynamically linked executable targeting glibc 2.28 on x86_64 Linux.

With Zig, it looks like this:

1) Download zig

2) `zig cc -target x86_64-linux-gnu.2.28 random.c`

What would those steps look like using llvm/clang?

Next, try doing it from Windows 8

Post reply on HN