Joseph Ferano
9700eeafb4
Every other struct in the package is handed to raylib and handed back, and that proves nothing: store-and-return is symmetric, so C writes and reads the same wrong slots for any field order. An Image is different. raylib computes with it, and two computations answer differently per axis. gen-image-color takes two scalars and returns a struct reading 4, 2, 1, 7 — four distinct values in four adjacent i32 slots, with no input struct for a permutation to cancel against. Texture2D never got that: nothing without a GPU reads its width, height or mipmaps at all. And get-image-color indexes y*width + x, so on a 4-wide, 2-tall image (3,0) exists and its transpose does not. That is the axis discriminator the collision family could not be — exchange x and y in the wrapper and the read goes out of bounds. The two flips say it twice more: on two rows, one moves a mark the other leaves alone. The PNG round trip is not the symmetric trap either. stb's encoder and decoder are external ground truth; they agree with each other, not with whatever field order Flan believes in. Verified to fail, each restored after: width against height, mipmaps against format, x against y in the shim, the two flips bound to each other, and the crop rectangle's width against its height.
