Joseph Ferano
07d068d297
Texture2D and Rectangle are the two structs the texture calls need, and they are the ones whose layout can be silently wrong: five 4-byte fields in a row, and four floats in a row, so a permutation still reads as plausible numbers everywhere. The obvious test — hand raylib a struct, read it back, compare — is worthless here, and I only found that out by trying it. Storing and returning is symmetric: swap two fields in the Flan defstruct and the round trip still agrees with itself, because C writes and reads the same wrong slots. That test passes whatever the layout is, which is the kind of test this project would rather not have at all. So the headless case uses the two things raylib computes from the fields without a GPU. GetCollisionRec turns (0,0,10,4) and (6,1,10,10) into (6,1,4,3), four different numbers each derived from a different pair of fields, and no permutation of Rectangle survives it. SetShapesTexture keeps a Texture2D without touching GL and substitutes 1 1 1 1 7 when the id is zero, so a zero id pins the first field, the 7 pins the last, and a zero width stored rather than substituted is what stops that pair from passing with id and width swapped. Each of those was checked by permuting the defstruct and watching the case fail. What is left unpinned is width, height and mipmaps against each other; nothing raylib does without a GL context reads them. That is stated in the program rather than papered over, because the alternative is a case that looks like it covers them. set-shapes-texture, get-shapes-texture, get-shapes-texture-rectangle and get-collision-rec are real bindings, not test scaffolding — they are bound here because they are also the only pure consumers of these two structs.