Jolt FFI layer binds raylib structs without C shims for 75 examples

The binding layer replaces traditional C shims with direct ABI-aware mappings for raylib’s structs. This removes a common integration bottleneck for managed runtimes, where foreign-function interfaces typically require intermediate C code to handle struct passing. The approach is demonstrated across 75 examples, covering 2D/3D rendering, physics, and generative art, all built atop a single shared namespace. Each example compiles headlessly, enabling unattended validation without a display or JVM.

Struct handling is tailored to size and architecture. Four-byte Color structs are passed as integers, matching how they travel in general-purpose registers. Larger structs like Camera2D (24 bytes) and Camera3D (44 bytes) are allocated in native memory and passed by pointer, a requirement for AArch64’s calling convention. Small float structs (Vector2/Vector3) bypass pointer indirection by using raylib’s immediate-mode scalar API, which accepts individual floats. These decisions are documented as ABI-specific rather than portable, avoiding false claims of universal compatibility.

The implementation prioritizes developer ergonomics and validation. A keyword-argument drawing API wraps positional C bindings, making calls like `(rl/circle! :x 400 :y 225 :radius 50 :color rl/MAROON)` possible. Headless compilation checks all 75 examples at once, catching broken bindings without a window or JVM. clj-kondo hooks rewrite FFI definitions into regular functions, enabling arity and type checking at call sites. The layer is not raylib-specific; it also binds libc’s `time()` and `localtime()`, reading `struct tm` directly from native memory.

Adoption requires Jolt and a system `libraylib`, with optional Babashka tasks for convenience. The binding layer is tested against a specific Jolt version but does not hardcode it, allowing updates. Each example is a small namespace with minimal dependencies, reducing the cost of adding new ones. The license matches raylib’s, avoiding compatibility issues. While the approach eliminates C shims, it does not abstract away ABI details, engineers must still account for architecture-specific behavior when extending or porting the bindings.