In a C project, I’ve been doing a lot of pixel manipulation and converting between RGBA and ARGB pixel layouts. I would have liked a built in swizzle operation like Odin has, but it looks like Odin only has this for arrays? (I’m quite new to Odin, so apologies if I’m mistaken). Would a swizzle operation that takes a u32 (or u16) and returns a u32 with the bytes reordered be practical?
I know you can just put them into an array of u8’s, but when the underlying pixel data type is u32, this seems a little odd. Or is there a cleaner way of using the existing swizzle feature for this? Maybe a union with a u32 and [4]u8?
Thanks. Not disagreeing or arguing the point but I am trying to understand the rationale for why it wouldn’t make sense.
Is it because using the foo.rgb notation here would be massively confusing? But there’s also foo.xyzw, or the notation foo.0123 could be introduced (which I personally might prefer in the general swizzle case anyway).
Is it because for arrays/matrices, there’s a hardware speedup that can be taken advantage of by putting it in the language, but there isn’t for single numbers?
Endianness issues? Too niche? Just trying to wrap my head around why it’s useful for arrays, but not integers.
Well, you say the underlying type is a u32 but it just so happens that all 4 channels are u8’s and fit into one u32.
Recently I wrote a raytracer and the code looked/worked way better if I had a type Pixel :: [4]u8.
Lets say we do have swizzling for ‘int’ types, what do you do when you switch between signed/unsigned 32 and 64 bit types? What do you do if it overflows? All of these edge cases start popping up and suddenly there isn’t an obvious answer and/or intuition IMO.