Congrats!

Full time indie is a fun and scary adventure at the same time, good luck!

One question, why DX 12? i'm kinda sad when i see indie choose proprietary non-portable tech..

Not to say that vulkan is better (i hate it), but i'm curious

If the OP is an ex-AAA graphics programmer, DX12 is probably more familiar than Vk. AAA likely means consoles which at the very least means you end up doing DX12x for Xbox, and at that point you may as well also do DX12 for PC.

Could be personal preference. I worked with OP at Intel during the early days of Vulkan and he was the go-to person for anything Vulkan related, so he's certainly familiar with the API.

Well, that is not a pragmatic approach to make games, specially for indies, to just target one graphics API, that limits the audience you can reach

We solved this issue already with WebGPU, it uses what ever is native to the platform you target..

https://devlog.hexops.com/2021/mach-engine-the-future-of-gra...

Everyone wins

(I'm the author of that post)

Michal is a seasoned AAA dev who has worked at AMD, Frostbite, EA DICE, Intel - I'm sure he knows exactly what tradeoffs he's making.

Different folks have different goals, and that's OK. My goal with WebGPU is to aim for a future where we have truly cross-platform graphics. I suspect your goal is similar.

But I don't think it's wrong to aim for the present, to use an API you're familiar with, or to want to get as low-level as you can get. That's pretty admirable, honestly, and I'm happy people are doing that in the Zig ecosystem.

Heck, maybe one day Michal's work with DirectX here leads to a DirectX backend for a Zig WebGPU implementation. :)

Experimentation is good.

Well said!

Note, that it is easier to ship a game for one platform. I don't have resources to test several platforms.

WebGPU is just 3D rendering. I will also need vector graphics, machine learning stuff, video playback, etc. Windows gives me that for "free" (DirectML, Direct3D 12 Video, Direct2D, DirectWrite).

My main goal is to ship a game and build interesting demos/mini-games as part of zig-gamedev project. I don't want to spend my time supporting and maintaining code for several platforms.

Also, using wrappers like WebGPU adds another layer of abstractions. I want to write my shaders in HLSL using dxc.exe, I want to directly see messages from DX debug layer and have full control over my code. WebGPU would just slow me down.

My game will run only on Windows 10+ and I'm fine with that.

I am using WebGPU from D, it's an interesting solution and works well, but it has some drawbacks. First of all, because you have to match so many APIs, it only offers a common subset of functionality. Secondly, because it's primarily a Web API, it has a lot of validation, which wouldn't be needed for a desktop application. Thirdly, while it's still a low-level API, it doesn't offer the kind of control that AAA engine devs would like. It takes care of synchronization , memory management, transition barriers. AAA devs would prefer manual control over that.

Well the most popular consoles doesn't use DX at all

Switch uses GL/Vulkan

And the PS4/5 uses something akin to Vulkan

On PC Vulkan is probably more used than DX12, i can't remember the time i seen DX12 in a setting.. i think i only seen it once..

What's the game? I guess based on DirectX it will be for Windows only?

Why Zig?

Not OP, but here is what I can think of:

- Low level

- great C interop

- Good toolchain ergonomics, except for no pkg manager yet

- Great cross-compilation

- Fast compilation (incremental coming soon)

- Ideal for things where ownership rules can get complicated (ECS e.g.)

The C interop is especially useful for gamedev since so many libraries have a C interface and thus can be relatively easily used in Zig.

Intersting, some follow up questions:

- Fast compilation: isn't it llvm? So how faster compared to C++/Rust/others that use it?

- Ownership rules/ECS: what about zig makes this especially good? The only language that comes to mind in this respect is Rust and its borrow checker, is it similar in Zig?

1. Both zig and rust compile to intermediate representations which are then compiled to llvm IR. Most of the compilation woes of rust are in the early stage IR.

2. Zig doesn't have ownership rules, which can get in the way of important data structures for gaming.

Part of Rust's problem last I knew was it throws a lot more than it necessarily has to at the LLVM backend. So a front end that takes the time to lessen the burden could run faster despite using the same tooling.

Part of it (perhaps the majority) is excessive intermediate code. But at least some of it is that Rust's abstractions are more complex/involved. The "zero cost" doesn't refer to compilation time.

Is that part paid in the Rust or LLVM portion of the compiler chain?

rust portion. For example, LLVM has no internal concept of ownership.

That's true of borrowing, but I'm not sure if it's true for other abstractions. I imagine generics (due to monomorphization) adds to the burden on the LLVM side.

Zig is like C but better. It fixes all the pain points of C without adding any extra complications (Rust - borrow checker, Go - GC, C++ - everything).

Memory safety is a pain point of C, and Zig doesn't fix that. There is no free lunch: you either accept garbage collection or deal with something that resembles the borrow checker.

I believe Zig takes a more nuanced and balanced approach to memory safety as a spectrum, rather than the extremes you present of either GC or borrow checker.

For example, Zig offers spatial memory safety, and provides test allocators to catch temporal memory safety issues. That's already an order of magnitude improvement over C.

Memory safety is also just one aspect of safety, whereas sometimes programmers conflate the two. It's important, but things like checked arithmetic should also be right up there, and should be enabled by default in safe build modes. I think Zig's approach here is also spot on, having worked a little in security, where an integer overflow can be almost as dangerous as a buffer overflow. Yet I don't see many other languages taking checked arithmetic as seriously as Zig does.

Ada, Modula-2 and Object Pascal, minus compile time execution that they lack, and you have Zig almost 40 years ago.

Sad that we have to go in circles to keep programming fashion going, instead of adopting best practices from the get go.

A language isn't just a compiler and a spec. I don't know the full history of all these projects, but IIRC Ada's compiler wasn't free for a long time.

How you structure the financials and the community around the language has also a gigantic impact on the final result, and this is an area where Zig bringing to the table something completely new.

https://ziglang.org/zsf/

Although most people associate Object Pascal to Borland due to the Turbo Pascal branding done by them, the language was originally created to write Lisa OS (Clascal), and then when the project got replaced by Mac OS, with the help of Niklaus Wirth input, Clascal became Object Pascal and was the main language until the C++ rewrite that took place in the early 90's.

Outside Apple computers, the dialects created by Borland gained such following, specially in Europe, that Turbo Pascal became the official Pascal dialect, even though Extended Pascal fixed most of the original design flaws.

Naturally they going enterpreisy lost the crowd to VB and VC++ folks (later .NET).

Modula-2 did have some nice offerings, specially on Amiga, but on the PC and Mac, Turbo/Object Pascal made it irrelevant as it offered all the improvements Modula-2 brought to the table (no one cared about co-routines on home computers back then).

Ada was the only one from those that yeah, actually quite expensive, and I think only SGI and SUN had UNIX compilers for them, with HP having BASIC and Pascal compilers for their OSes.

Then there was the Amsterdam Compiler Kit, the "LLVM" for the 1980's, which had support for C, Pascal, Modula-2, Occam, and BASIC.

Looking forward to see how Zig evolves, specially regarding issues like #2301.

You say "minus compile time execution"... but when you take comptime away from Zig, you lose both generics and compile-time reflection. The remaining language is C without a preprocessor. So, yeah. Strip out the most useful and innovative feature from the language, and it looks primitive.

The languages I mentioned all got generics during their lifetime, so yeah they were all more powerful than C.

C won due to UNIX, had UNIX not been a kind of free beer that companies could build their workstations with and universities avoid paying for commercial OSes like VMS, history would have taken a different path.

What about compile-time type reflection?

Also, lisp has pretty much always been more powerful than C. But what zig brings to the table is an extremely simple language which is also very powerful. Much of the power results from the entire language being available at compile time. You seem so ready to throw that away in favor of could-have-been nostalgia, I wonder if you've taken the time to understand what you're criticizing.

I was quite clear that compile-time type reflection was the only thing missing.

Zig isn't the only AOT compiled language with compile-time type reflection in 2021, and exactly because of could-have-been nostalgia, we don't need newer systems programming languages that don't have an answer for use-after-free in safe code.

https://github.com/ziglang/zig/issues/2301

https://github.com/ziglang/zig/issues/1966

Naturally I have taken the time, and did not come out impressed, given my background and programming language beliefs.

However as I say in another thread, other people seem to be happy with such shortcomings.

Adding bounds checks and ASan is not an order of magnitude improvement over C. Chrome, for example, is doing all of this already in C++ in a more advanced way than anything I've seen in Zig. Clang offers UBSan [1], which is extremely advanced. Yet it is not enough.

It is not a "nuanced and balanced" approach: Zig is simply not memory safe.

[1]: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#...

If you're shipping a game that runs on a player's computer, you're most likely going to make production builds with -O ReleaseFast (safety checks off). Rust is overkill for this use case. The only benefit memory safety brings to this use case is making debugging easier. But if we're measuring how debuggable a language is, there are many more factors, such as iteration speed due to compilation times.

Memory safety also adds reliability, by catching bugs statically that you didn't catch during (automated or manual) testing. It's the same argument as for static typing.

It's of course true that some developers may judge the tradeoffs differently for their individual projects—that's why they're tradeoffs! But there are benefits to memory safety that go beyond security.

the only memory safety gamedev needs are bound checking and use after free protections

everything else is just bloat and noise that hurts iteration time

and even if one would still value them, you'd need to check only once for whatever memory check you want to run, when you build your allocators for example, and not at every builds, and you could even write the logic yourself and have a debug allocator to ensure memory safeties

you want sub second and not "double digit seconds" build times

it takes one to try to make a game to trully understand why iteration time is far more important that anything else (other than performance of course)

you don't want to wait multiple seconds everytime you change the speed of your character, or tweak the rendering/AI code

that's why then some devs end up using scripting language and they loose all the advantages of their native language, because they want to speed up iteration time

that's why i personally stick to D for my game, my engine + game fully rebuild in under 1 second

you don't get to create memory bugs when you work on your gameplay code ;)

> the only memory safety gamedev needs are bound checking and use after free protections

Probably if your game is single-threaded …

Rust's raison d'être was type-check thread-safety, and even if we don't talk about this aspect much anymore it's still the domain where it has no competitors (Pony could have been, but didn't get traction).

And it's invaluable.

> the only memory safety gamedev needs are bound checking and use after free protections

Disagree, but in any case, we're talking about the fact that Zig doesn't provide use-after-free protection.

Zig is allocator aware, use after free protection is covered with the ``GeneralPurposeAllocator``

Is GeneralPurposeAllocator the one that quarantines memory forever? That isn't practical, as I've mentioned before. To name one problem, allocating 1 byte in a 4kB page leaks the entire page.

Zig fixes many more memory safety issues than C or C++ though, simply by being less "sloppy" and enforcing more correctness (e.g. no implicit type conversions, no over/underflows, proper range-checked arrays and slices etc...) - IME most memory corruption issues in C and C++ are actually secondary effects of such simple correctness issues. Zig just isn't quite as "extremist" as Rust (also, Rust is a great language for writing a sandbox, but if a memory-safe language must be used inside the sandbox to prevent damage outside the sandbox, then it simply isn't a sandbox.

All of these are available and widely used in C++ (for example [1]). They are not enough.

[1]: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#...

"Widely used" might be a bit of an exaggeration, MSVC only added address sanitizer support very recently but doesn't support any of the other sanitizers, and none of the sanitizers are enabled by default in Clang.

The biggest companies on the planet with massive C++ codebases are all very aware of the clang sanitizers and use them regularly. UBSan has far more deployment than Zig.

From my point of view in terms of memory safety with Zig, we could just use Modula-2 or FreePascal/Delphi instead, but they aren't as fashionable.

As much as I love Delphi, the language syntax hasn't aged well. Single pass compilation was great to have in the 1980's but nowadays even the humblest Raspberry Pi will chew through thousand of lines of C++ and link an optimized executable within seconds.

We deserve and can afford a lot more comfort than Pascal (and siblings) provides. Incidentally, modern language ergonomics also adds much in the way of coding safety, making usage of explicit allocation control a more manageable problem than it was 30 years ago.

Indeed, and that is why for me modern language ergonomics is a synonym for Swift, C#, Nim, D, and Rust.

For Zig to be part of that list, a story for use-after-free must exist as well.

Others won't agree with me, and that is fine, different strokes for different folks.

You could build the same argument for all other types of correctness: either your program is formally validated to be correct, or it's broken.

While there is some truth to that, if that's the only analysis you're willing to do, then you're going to fail spectacularly hard at recognizing the advantages of TypeScript over JS, for example. Zig and C share a similar relationship across many axes, including memory safety.

Because zig needs better game development tooling!

Why not Zig? Its a pretty fun language...

Personally I dislike the @ love, feels a bit like being in Objective-C land, imports feel like JavaScript AMD modules, and still use-after-free issues.

Otherwise it is pretty much Modula-2, with C flavoured syntax and compile time execution.

Overall, the use-after-free is what irks me.

Well there are still quite a lot of compiler bugs. I personally have open issues going back as far as 2018. Knowing the compiler has bugs and that new ones are constantly being discovered makes debugging a pain because you have a lot less confidence that the problem is your code. I have many times blamed the compiler for my mistakes, something I've almost never done with C.

> I have many times blamed the compiler for my mistakes, something I've almost never done with C.

Early on, I remember dealing with lots of bugs in C compilers in the mid and late 80s. It takes time.

The tech looks really great. What kind of game (genre) are you planning to make?

This is really looking great! You say you left your job... do you have income yet, or is that an item on the todo list? Any clues about the game you're working on?

Michal has a GitHub Sponsors profile, people that are interested in what he's doing should consider supporting him there.

https://github.com/sponsors/michal-z

Any plans for multi-platform in the future?

No, sorry, it will stay Windows 10+ only. I want to focus on building interesting stuff (demos, games, audio-visual experiments) I don't have bandwidth to support and maintain code for several platforms.