The GPU loves arrays of structures AoS, since all vertex data fits in its triangle assembly cache. Once given to the GPU, the software side doesnt really care for all vertex parameters so this optimisation is pointless. Only relavent when you have instance rendering (leaves, grass) but then you only need an array of vec3’s, not the other parameters so back to normal arrays.

Meanwhile, game engines need operator overloading for adding/multiplying vectors (spatial transforms, lighting, physics) and core zig design philosophy prevents operator overloading.

Blind leading the blind. Disclaimer - I do professional rendering engines.

▲ geysersam 2 hours ago | parent | next [-]

Genuine question: why do you think game engines need operator overloading? I mean, what's wrong with generic functions like add, multiply, dot etc.

▲ aaaashley an hour ago | parent | next [-]

Not GP, but I've written game engines and rendering engines. Vector operations are just common enough that having to write `.mul` every time is a huge pain, especially when you put many of them together for a large formula. Compare:

(physics_data.velocity + omega * change) * frame_delta_time

physics_data.velocity.add(omega.mul(change)).mul(frame_delta_time)

We learn to read and think about math a certain way, which is incompatible with Zig. Also, Zig's design philosophy of "reading code over writing code" is incompatible with the kind of small modification-test-cycles required when doing games, and creative programming in general. So Zig is sort of DOA anyway for that kind of thing.

But I've been using Zig for non-game projects and it's been fantastic, so definitely not "Blind leading the blind" for the overall language design, imo.

▲ smj-edison 41 minutes ago | parent [-]

I've been thinking about a way around this, and I'd be interested to see if comptime with a DSL wouldn't be too unwieldy. Something like

  math("(v + Ω * c) * Δt", .{ .v = physics_data.velocity, .@"Ω" = omega, .c = change, .@"Δt" = frame_delta_time})

I know this is already possible with comptime, though I haven't implemented it yet since I haven't needed vector math in what I'm working on currently. Can't decide whether using math names is better or worse than using the full variable names though.

	▲	stouset 10 minutes ago \| parent [-]
		All this just to prevent people from using + - * / and ^. Why?

▲ hmry an hour ago | parent | prev [-]

Why have operators at all?

  x = x.add(step.mul(2)).mod(width)

Or in C

  x = imod(iadd(x, imul(step, 2)), width)

  x = (x + 2*step) % width

For me the answer is very simple: Operators make it easier to read the code which makes it easier to spot bugs. It also makes it easier to turn formulas from textbooks into code.

If 50% of the code you're working with is using vectors and matrices, not having operators for those parts is quite annoying.

Note that you can have vector operators without overloading, e.g. Odin has built in vector and matrix types.

But personally I think it's better to give the user more power instead of only letting the compiler author pick which types to allow operators on. Like how Java overloads + but only on the String class. Why do they get to do it, but not me?

▲ awesan 3 hours ago | parent | prev | next [-]

Zig is adding native vectors including operator support, there are some recent issues/prs about this topic.

The general technique of SoA is pretty useful both in games and other applications, but of course I cannot speak to the specific use-case you are describing.

▲

nvme0n1p1 2 hours ago | parent [-]

Zig vectors force data into SIMD registers even if that would make the code slower. They're a specialty type. You should only reach for vectors if you would have used SIMD intrinsics in C for example.

	▲	e4m2 2 hours ago \| parent [-]
		Zig vectors do not necessarily force data into SIMD registers; a scalar implementation would work equally well. This is not just a theoretical argument, because Zig code that uses `@Vector` also has to compile for architectures that do not have SIMD instructions. That being said, the parent commenter is actually referring to other recent proposals as opposed to existing `@Vector` functionality: https://codeberg.org/ziglang/zig/issues/32032 https://codeberg.org/ziglang/zig/issues/35376

▲ beepbooptheory 3 hours ago | parent | prev [-]

So is the argument that any SoA is pointless? Or just for GPU stuff? Because this isn't really talking about all that one way or another.

Also does one really need operator overloading? That feels a little strong. I've gotten by with functions just fine.. Does that make the GPU not like me Mr. wise engineer?