The user wants a graphical demo in the Zane language using its C FFI and a library like raylib, and points to a GitHub repo. I can't browse the web, so I need to check whether I actually know this language. I'm not aware of a well-known Zane language at that address, so I should be upfront about that rather than invent details. I'm weighing whether to write a raylib demo in C, since that's guaranteed to work, and then map it onto Zane once the actual syntax is known. I'll be clear that I can't verify Zane's FFI conventions or build system, so anything I write in its syntax would be a guess, and I'd rather flag that than fabricate it. I'm weighing two routes: say upfront that I don't know Zane's syntax and write the demo in C with raylib, which I can get right, or guess at Zane syntax, which would likely be wrong. I'll go with the C version and list the exact raylib functions and struct layouts it needs, so porting to Zane's FFI is straightforward once the user shares a snippet of its extern and struct syntax. Now I'm weighing which kind of graphical demo would be most impressive. A per-pixel Mandelbrot or Julia zoom is a strong candidate: it's computationally heavy and the raylib surface is small, just a texture update and a draw call each frame. I'm weighing which demo would impress most: a stable fluids simulation looks striking and is clearly compute-bound, and its FFI surface stays small, just a pixel buffer pushed to a texture each frame. An N-body particle sim with trails is another option, with around 4000 particles giving roughly 16M interactions per frame, which should still run at 60fps in C. I'm settling on the design now: keep the FFI surface to a few calls, do the heavy computation in the host language, and push pixels through a buffer and a texture upload. Passing structs like Image, Texture2D, and Color by value is where the FFI details could get tricky. I'm thinking about the struct-by-value problem: many small languages' FFIs can't pass raylib's structs like Vector2 or Color directly, so I'd write a tiny C shim that takes pointers or primitives and compile it alongside raylib. That keeps the Zane side to simple bindings. Then I'll settle on a real-time 2D fluid demo with mouse interaction, drawn into a pixel buffer and pushed to a raylib texture. I'm weighing a stable fluids simulation as the demo: a 256×256 grid stepped each frame with diffusion, projection and advection, which should be heavy enough to feel genuinely computational while the raylib surface stays tiny. Now I'm sketching the thin C shim that wraps raylib, so the Zane side only has to call functions with primitives and pointers. I'm settling on the shim approach: a thin C wrapper that calls raylib and exposes only pointers and primitives, so the Zane side never has to pass structs by value. The direct raylib bindings are worth showing too, but I'll flag where struct passing could break. I'm weighing whether to keep the main program in C, since that's the one thing I can guarantee runs, and treat it as a reference to port to Zane once its syntax is known. I could sketch it in a made-up Zane-like syntax, but if the real language works differently that would just mislead, so I'm leaning against it. Now I'm writing the fluid simulation as a C reference, since that's the one version I can actually get to compile, and I'll port its structure to Zane once its syntax is known. Still writing the fluid setup code... I'm settling on 3 dye channels for color mixing, stored as an array so the diffuse and advect steps can loop over them, and I'm considering adding vorticity confinement to keep the swirls lively. Still writing the fluid solver code... Still writing the boundary handling code... Still writing the solver iterations... Still writing the advection step... Still writing the projection step... Still writing the projection step... Still writing the vorticity confinement code... Still writing the vorticity confinement code... I'm checking the vorticity confinement force: the curl gives a vector field pointing toward stronger swirl, and crossing that normal with the curl produces an x-component of ε·Ny·ω and a y-component of −ε·Nx·ω. That matches the code I already wrote, so the sign is right. Checking the sign convention on the vorticity force: the cross product of the normal N with the curl gives the same form as the Fedkiw et al. formula, so the amplifying direction is right. The remaining question is the scale, since the curl is computed without dividing by the grid spacing and the eps parameter will need tuning by eye. Still sorting out the vorticity magnitudes: the curl is computed without dividing by grid spacing, so the eps value will need tuning by eye rather than a precise derivation. Estimating the force scale from typical velocities: with per-cell curl around 0.1 and dt near 1/60, the vorticity term is tiny per frame, so eps probably needs to be around 10 to have a visible effect over about 30 frames. Settling on the eps value now: I'll set the vorticity strength to 8.0 and flag it as a tuning knob. Since the grid-spacing factors cancel out, the force reduces to eps times the curl times the normal components, so the formula holds and only the scale is uncertain. I'm estimating the injection strength next: a mouse drag at about 500 px/s works out to roughly 0.65 domain-widths per second, so I'll scale the injected velocity to a small multiple of that, around 2 to 5 times, applied within a radius of the cursor so the velocity near it lands near 1 to 3. Still settling the vorticity strength: with curl around 0.3 and per-frame changes meant to stay in a small range, a value around 2 to 3 looks reasonable, though the nonlinearity means it could blow up if pushed too high. Still writing the fluid step... Still writing the velocity step, which swaps the buffers, runs the second diffusion and projection passes, then advects both components. Checking the swap order against Stam's reference: diffusion writes into u, projection uses the scratch arrays, then the buffers swap again so advection reads the projected velocity and writes back into u. Advecting u and v with that same field, followed by a final projection, matches the reference sequence. Still writing the buffer setup, zeroing the force accumulators each frame before adding input. Still writing the dye step code... Still working through the dye arrays: I'll keep the velocity pointers and the three dye channels as globals so the solver steps can swap them freely. Now I'm thinking through the speed cost of the dye diffusion: with zero diffusion it's wasted work, so skipping it would save time, though a little diffusion looks nicer. Counting the cell updates per frame, that's roughly ten million, which should be about 10ms in optimized C at 60fps, but a hobby language with weaker codegen might be slower, so I'll note that the grid size can be dropped to 128 if needed. Still writing the dye diffusion code... Still writing the dye rendering code... Still writing the dye fade and tone mapping code... Now I'm settling on an input scheme: mouse drags will inject velocity and colored dye, and when the button isn't held, a slowly orbiting emitter keeps the fluid moving so the demo runs on its own. Still writing the splat function... Still working out the mouse injection scale: I want the injected velocity to match the drag speed times a force factor, which means dividing the source term by dt so the step lands on the right value. Still writing the velocity step, but I'm dropping the separate source term: the mouse injection will go straight into the velocity and dye fields, which removes the awkward dt scaling. Still working out the velocity step: I'm skipping viscosity diffusion when it's zero, since that pass would only copy the field, and I'm sketching how to structure the buffer swaps around that conditional. Still writing the velocity step: I'm checking the pointer swaps so that advection reads the projected field and the final projection leaves the result in u and v. Still writing the dye step, which advects each channel and then scales it down slightly so the colors fade over time. Still working out the mouse grid mapping: converting window pixels to grid coordinates by scaling against the window size, with row zero at the top. Working out how to convert mouse movement into velocity: the drag delta in pixels, scaled by the window width and divided by dt, gives a grid velocity that I'll multiply by the force factor before adding it straight into u. Checking the injection scale now: a few pixels of mouse movement per frame works out to roughly 2 domain-widths per second once the force factor is applied, which means the advection moves the dye several cells each frame. That's fast, but it should read as a lively swirl rather than chaos. The concern is that the splat keeps adding velocity every frame while the cursor stays over the same spot, so the fluid could build up faster than projection and advection carry it away. Still weighing how strongly to inject the mouse motion: I'm considering a blend toward a target velocity instead of a plain add, which would be steadier, though adding the force times the drag displacement without dividing by dt is simpler and frame-rate dependent. Still working out the mouse injection strength: I'm trying a force factor of about 0.5 applied to the drag velocity, which would give a gentle push of roughly 0.4 domain-widths per second for a 10 px/frame drag. Still working out the mouse injection: I'm framing the force as frame-rate independent by scaling the mouse velocity with dt, so the total push a cell gets depends on how long the cursor lingers over it rather than on the frame count. Still working out the mouse injection: I'm settling on a per-frame push proportional to the cursor's displacement in grid units, with a tunable force factor around 10 to get a visible swirl. Still working out the mouse force: I'll scale the drag displacement by a factor of about 12, so a 10-pixel move adds roughly 0.13 velocity per frame at the cursor, and I'll treat that as a tunable knob. Next is the auto emitter, which orbits near the center on a slow circle. Now I'm settling the auto emitter: it orbits near the center, and I'm leaning toward a fixed per-frame push in the tangent direction so the jet keeps moving the fluid along. Working out the steady-state jet speed: if each frame injects a fixed push into the splat region, the fluid there settles where that push balances how fast advection carries it out, which means the target speed depends on the injection amount and the splat radius. Checking the numbers, the injection would need to be around 0.7 per frame to reach a speed near 1. Now I'm settling the emitter: instead of adding velocity each frame, I'll blend the field toward a fixed jet velocity inside a small radius, using a Gaussian weight. That keeps it stable and independent of frame rate, and I'm writing a splat_set helper for it. Still working out the emitter: I'm switching to a set-blend toward the jet velocity inside the splat radius, and I'm checking whether the dye should be added per frame scaled by dt so it saturates near the center and gets carried off by the flow. Now I'm writing the color cycling: the hue advances at 40 degrees per second, and I'll convert HSV to RGB with a small hand-written helper instead of raylib's ColorFromHSV, since that returns a struct by value and would be awkward over FFI. Next I'm filling the pixel buffer cell by cell, clamping each dye channel and setting alpha to full, then pushing it to the texture with UpdateTexture. Now I'm listing the raylib functions I need for the FFI surface, starting with window setup like InitWindow, SetTargetFPS, and WindowShouldClose. Now I'm listing the raylib calls that avoid struct passing, like GetMouseX and GetMouseY in place of GetMousePosition, since the struct-by-value returns are awkward over FFI. The image and texture loaders are the trickier part, because Image and Texture2D are structs passed in and out by value. Still listing the raylib calls, now the drawing and text side: BeginDrawing and EndDrawing, ClearBackground, DrawText and DrawFPS, which take only primitives and a string. Now I'm working out the FFI strategy for the texture-related calls, since Image and Texture2D get passed by value and that could be awkward for Zane. If its FFI can't handle C structs by value, I'll put a small C shim in front of those calls so everything crosses the boundary as pointers and primitives. The shim would hold the texture internally and expose init, canvas create, update, and draw functions. Writing the raylib shim header now, for the calls that take or return structs. Writing the C shim for the calls that take or return structs, wrapping the texture setup, upload, and draw so only pointers and primitives cross the FFI boundary. Writing the C shim now: the calls that take Color or return Image and Texture2D by value get wrapped so only pointers and primitives cross the boundary. I'm noting that a 4-byte Color struct is usually passed in a register just like a 32-bit integer on common ABIs, so binding it as a u32 may also work. Looking at how a struct gets passed is where the shim decision really hinges. A Color is only four bytes, so it can go through a plain 32-bit integer on common ABIs, but Vector2 behaves differently on each platform: it packs into one SSE register on x86-64 and into two float registers on AArch64. Texture2D is too large for registers at all, which is why the wrapper is the reliable route. Now I'm weighing whether the velocity field can get out of hand near the boundary, and noting that the dye boundary can just copy neighboring values. I'm checking whether a jet speed around 1 with a small radius could make the vorticity confinement blow up. Estimating the curl at about 0.17, the added force per frame is only around 0.006, so after a couple of seconds it should be noticeable but not explosive. I'm settling the mouse injection now: a fast fling could add a large velocity per frame, but semi-Lagrangian advection stays stable even at high speeds, so the result might look chaotic without breaking. I'm going to skip the mouse-delta clamp to keep the code short, and move on to the rendering step. For the tone mapping, I'm weighing an exponential falloff against a simple Reinhard-style c/(1+c) curve, since the exponential costs a lot more per pixel across the whole grid. Now I'm checking the edge case in the advection step, where the right-hand index could land one past the grid when the sample point sits at the far boundary. Still writing the HSV helper... Still writing the HSV helper... Still writing the HSV helper... Still writing the HSV helper... Still writing the mouse emitter, now wiring up the orbiting autonomous emitter. Still writing the main loop, filling in the rendering and the texture draw call. Still writing the main loop, now checking the jet direction so the orbiting emitter pushes forward along its path. Checking the boundary handling next: horizontal velocity should flip sign at the left and right walls, and vertical velocity at the top and bottom, which is the part I'm verifying in the set-boundary helper. Still working on the boundary handling, checking that the sign flips are right for the horizontal and vertical components at each wall. Next I'm thinking about the per-frame cost of the solver, since the pressure passes and diffusion loops dominate. I'm estimating the cost per frame: about 4 million cell updates at 24 solver iterations, which works out to a few GFLOP/s at 60fps. That's a demanding load for a scalar, single-threaded program, so it doubles as a benchmark of Zane's codegen. If Zane turns out to be slow, I'd drop the grid to 128. I'll also need a porting checklist for the language features Zane has to support. Next I'm planning how to close out the answer: I'll ask the user to paste a Zane snippet covering an extern C declaration, a struct or array with indexing, and a loop with a function, so I can translate the whole demo. I'm also noting the build step, where the shim gets compiled separately and linked against raylib with platform-specific flags for Linux, macOS, and Windows. Still writing the C source, now working through the build line for Linux, macOS, and Windows. Still writing the C source, now on the build flags for macOS and Windows. Still writing the constants and the grid indexing helper. Still writing the dye advection, swapping the buffers so the update reads from the old values. Still writing the render step, converting each dye channel through a soft tone-map into RGBA pixels. Still writing the splat helper, clamping the loop bounds to the interior cells. Still writing the splat helper, filling in the same bounded loop with a Gaussian weight that sets the cell to the target value. Still writing the vorticity confinement, computing the curl at each interior cell. Still writing the vorticity confinement, computing the normalized gradient of curl magnitude for each interior cell. Now I'm checking whether the vorticity force points the right way, since the sign convention flips with the y-down screen coordinates. Checking the vorticity sign convention against the finite-difference curl, I'm confirming that the cross-product term is consistent with how I defined curl, so the force strengthens the vortex whichever way the screen's y-axis runs. Still writing the velocity step, now checking the diffusion coefficient and the projection pass. Still checking the velocity step, now confirming that skipping the first projection when viscosity is zero is fine, since advecting and projecting once per frame is a standard approach. Still tuning the velocity step: I'll drop the separate first projection, run vorticity confinement, diffusion only when viscosity is nonzero, then advect and project once per frame at about 30 iterations. Still writing the dye step, swapping the channel buffers and decaying each channel by the fade factor. Still writing the dye step, swapping the channel buffers and advecting each color before decaying it. Still working through the dt clamp and first-frame behavior, checking that a zero timestep leaves the fade and advection unchanged. Now I'm listing the port requirements for Zane: the extern C declarations for the raylib calls, a flat float buffer for the fields, and the math functions either from Zane's stdlib or from libm. I'm checking how raylib's C functions map onto Zane's FFI, starting with the simple ones like window setup and frame rate. For the bool-returning WindowShouldClose, I'm not sure whether the upper bits of the return register are guaranteed, so I'd treat it as a small integer and only test for nonzero. Checking the raylib prototypes for the rest of the calls, I'm noting that the bool-returning functions need the same caution as WindowShouldClose, and that the struct-by-value helpers like GenImageColor and LoadTextureFromImage will be the awkward part for the FFI. Still writing the shim, now wrapping the struct-by-value raylib calls for the canvas texture and its filter setup. Still writing the shim, now wrapping the canvas create, update, draw, and destroy calls and the clear and text helpers. Now I'm writing the build step: compiling the shim object with optimizations and linking it against the Zane output and raylib, and noting that a bool-returning call may warn under stricter flags but not by default. Next I'm mapping the C reference's raylib calls onto the shim wrappers, so the canvas create, update, and draw go through rl_canvas_* and the clear and text calls through rl_clear and rl_text. I'm settling on the structure now: the reference C program will call the shim's primitive-signature functions rather than touching raylib structs directly, so the Zane version becomes a line-by-line translation. I'll declare the shim prototypes explicitly in the C file, since that's the same declaration the Zane side will need. Now I'm laying out the header for the shim, declaring the six wrapper functions for the canvas and the clear and text helpers, so that the C reference and the Zane side share the same primitive signatures. Then fluid.c will include both raylib.h and that header. Next I'm weighing whether the Zane side needs a hypothetical extern syntax sketch, but I'll stick with plain C prototypes since those are unambiguous, and tell the user to translate them into Zane's own syntax. I also need to note that raylib's bool-returning functions should be read as small integers and masked, and that strings must be NUL-terminated and the pixel buffer passed as a raw contiguous byte array. Next I'm covering the two ways the shim could be built: a static object for a compiled Zane, or a shared library loaded via dlopen-style FFI. I also want to note that the hot loop is the linear solve, which runs a few million cell updates per frame and should stay comfortably fast in optimized C, so the performance question depends mainly on whether Zane compiles or interprets. Checking the boundary helper next, making sure the edge values mirror correctly for the velocity components and that the corners get averaged from their neighbors. Still writing the boundary helper, now mirroring the edge values and averaging the corner cells from their neighbors. Still writing the linear solver, now filling in the Gauss-Seidel sweep over the interior cells. Still writing the rest of the solver and the main loop setup, now checking the window initialization. Still writing the main loop, now clamping the timestep so a long frame doesn't blow up the solver. Still writing the main loop, now handling the reset key and cycling the dye colour through the hue spectrum over time. Next I'm working out where the mouse sits in grid coordinates, for when the left button is held down. Still writing the main loop, now handling the mouse-driven splats that push velocity and dye through the grid while the left button is held. Still writing the main loop, now filling in the per-frame splat calls for the orbiting emitter and then running the velocity and dye steps. Still writing the main loop, now filling in the wrap-up: the code that finishes the frame, draws the FPS counter and the on-screen hint text, and then tears down the canvas and window. I'm checking the jet's dye load against the tone map: about 0.42 per frame at the centre, with dissipation around 3 seconds, so the colour should land near 0.67 brightness rather than blowing out to white. The hue cycle at 40° per second gives a full spectrum roughly every nine seconds. Now I'm checking the HUD text: the render loop writes pixels row by row into a sequential buffer, which matches raylib's row-major RGBA8 layout that the uploaded image uses, so the update buffer size works out. Now I'm turning to the Zane port, and I want to point out what this demo actually stresses in a language: tight numeric loops, swapping pointers between buffers, passing pointers to raw memory across the FFI, getting the calling convention right, and handling floats at the ABI boundary. I'm also considering a fallback where raylib's structs are passed by value, with Color as four bytes, Vector2 as two floats, and Texture2D and Image as their matching layouts, though I'd still recommend the shim. And if Zane compiles down to C, the FFI step becomes almost trivial, since it could just include raylib.h directly. Now I'm writing the C reference's header comment for the fluid solver, which is cut off partway through. Still writing the C header comment for the fluid solver, covering the build lines for Linux and macOS. Still writing the C header, now defining the tunable constants for grid size, window scale, solver iterations, viscosity, and vorticity strength. Still writing the constants, now setting the dissipation and mouse force, and the autonomous jet speed and dye injection rate. Still writing the fluid setup, now declaring the velocity, scratch, and vorticity buffers plus the dye channels and the pixel upload buffer. Still writing the fluid reset routine, now zeroing the velocity fields and each dye channel so the simulation starts clean. Still writing the boundary helper, now handling the wall reflection and the corner averages for the rest of the edges. Still writing the Gauss-Seidel solver, now setting up the relaxation loop over the interior cells. Still writing the Gauss-Seidel sweep, now finishing the interior update and the boundary pass after each iteration. Still writing the advection step, now tracing each cell back along its velocity and clamping the sample position to the grid. Still writing the advection step's bilinear sampling, now finishing the velocity projection that makes the field divergence-free. Still writing the pressure projection, now zeroing the divergence and pressure fields on the interior before the Poisson solve. Still writing the vorticity confinement function, now computing the curl field from the velocity components. Still writing the vorticity confinement, now finishing the curl gradient and the force that pushes the velocity field. Still writing the vorticity step, now applying the confinement force to the velocity field and then running the diffusion passes on the velocity components. Still writing the dye step, now advecting each colour channel along the velocity field and fading it out over time. Next I'm setting up the Gaussian splat helper, which adds or blends colour into a small area of the grid. Still writing the splat helper, now computing the Gaussian falloff for each cell around the splat centre. Still writing the color conversion, now setting up the HSV-to-RGB mapping for the hue ramp. Still writing the fluid renderer, now converting the dye into RGBA8 pixels with a soft tone-map. Still writing the fluid renderer's pixel loop, now checking the bounds handling in the splat helper and confirming the hue calculation stays within range. Still writing the main setup, now creating the window and setting the target frame rate. Still writing the main loop setup, now taking the frame time and clamping it so a stall doesn't cause a huge simulation step. Still writing the main loop, now reading the frame time and handling the R key reset. I'm setting up the dye colour from a hue that cycles over time, then working out the mouse position and the stir force. Still writing the mouse stir and idle emitter branches, now setting the splat position and velocity for each mode. Still writing the render loop, now feeding the dye and velocity into the splats and then drawing the canvas. Now I'm writing the rest of the demo's main code and the shim header, and I'm getting ready to lay out the Zane porting notes. Still writing the FFI table, now covering the string and bool parameters and the 32-bit and 64-bit float returns. Still writing the FFI table, now listing the libm math functions and the heap allocators Zane might need to provide. Next I'm covering how the struct-passing question affects the port, since the field layouts have to match C exactly. I'm also weighing performance expectations for the solver, since it works as a good codegen benchmark, and which optimization level to compare at. The main thing to watch is float versus double at the FFI boundary: the prototyped functions need true 32-bit floats, and if Zane's FFI only handles f64, the shim will have to convert between the two. Now I'm settling on how to open: a plain admission that I can't open the repo and don't reliably know Zane's syntax, so I won't invent code that might not parse. Then I'll offer the port as a mechanical step and ask for a small Zane sample to convert line by line. Checking the remaining raylib calls I plan to reference: the texture upload, the draw call, and the image helpers all look right to me. Checking the raylib names I'm going to reference: the texture helpers, the drawing calls, and the key and mouse constants all look correct to me. Now I'm checking the macOS link flags, and I'll suggest `pkg-config` as the portable way to get raylib's libraries, with explicit Linux flags as a fallback. I'm also noting that a shared raylib build usually only needs `-lraylib`. Last, I'm working out how the shim should build a `Color` from ints. Casting each channel to unsigned char keeps the compound literal clean without triggering a conversion warning. I'm also thinking about the bool return from WindowShouldClose: wrapping it in a shim that returns an int would make the FFI boundary simpler, so I'll route the bool-returning calls through the shim as ints. I'm weighing whether the bool-returning raylib functions should go through the shim as ints, since that would make the FFI boundary simpler. I'd rather keep them direct so the demo shows raylib's own calls. For a `bool` return, I'm noting that the common convention on x86-64 is that only bit 0 is guaranteed, so Zane should read it as an 8-bit value and test it against zero. Checking how the bool return is read, I'm treating it as an 8-bit value, and I'm also thinking about whether to mention a quick way to confirm the FFI works step by step: a window with ClearBackground through the shim first, then the canvas, then the simulation. I'll also use a plain hyphen in the title instead of an em dash, since raylib's default font may not render it. Settling the final checks: the math and string headers cover every function the code calls, and the allocators are in stdlib. I'm also asking whether a 256-by-256 stable fluid at 60 fps is worth calling computationally heavy. It is: roughly three million cell updates and around 50 MFLOP per frame, with a memory-bound Gauss-Seidel sweep, and it still looks striking on screen. I'm mapping out the closing notes now: a brief pointer to scale N up to 512 as a real stress test, since that quadruples the work and pushes the 60 fps target. I'm also noting that the solver's inner loop is what to inspect in Zane's generated assembly, and then I'm settling on the final answer. ## First, the honest caveat I can't open that repository, and I don't have reliable knowledge of Zane's syntax or how it declares `extern` C functions, so I won't invent Zane code that might not parse. Instead I've built the demo so the Zane port is **mechanical**: everything that crosses the FFI boundary is a plain C function taking only `int`/`float`/pointer arguments (raylib's own primitive calls plus a ~20-line shim that hides raylib's struct-by-value API). The reference is in C so you can verify raylib works on your machine first, then translate line-for-line. If you paste me a small Zane sample (an extern declaration, a function with a loop, array indexing), I'll do the translation. ## The demo: real-time stable-fluids ink simulation A 256×256 incompressible Navier–Stokes solver (Jos Stam's *stable fluids*) with vorticity confinement, running every frame on the CPU: - semi-Lagrangian advection of velocity + 3 dye channels - 30 Gauss-Seidel sweeps for the pressure Poisson solve (incompressibility) - vorticity confinement to keep the swirls crisp - ≈3 million cell updates per frame → ~50 MFLOP/frame, 60 fps An emitter orbits the screen leaving spectrum-cycling smoke trails; left-drag to stir; `R` resets. Bump `N` to 512 for a real stress test (4× the work). ### `fluid.c` ```c /* fluid.c - real-time 2D "stable fluids" (Stam 2003) + vorticity confinement. * Only primitive-signature C functions are called across the FFI boundary. * * Build the reference: * cc -O2 fluid.c rlshim.c -o fluid $(pkg-config --cflags --libs raylib) -lm * (Linux w/o pkg-config: -lraylib -lm -lpthread -ldl -lGL -lX11) */ #include #include #include #include "raylib.h" #include "rlshim.h" /* ---------- tunables ---------- */ #define N 256 /* interior cells per side (128 if your codegen is slow, 512 to stress) */ #define SCALE 3 /* window = N*SCALE pixels */ #define ITERS 30 /* Gauss-Seidel sweeps for the pressure solve */ #define VISC 0.0f /* viscosity, 0 = inviscid */ #define VORTICITY 2.0f /* vorticity confinement strength, 0 = off */ #define FADE 0.35f /* dye fade rate per second */ #define FORCE 12.0f /* mouse stir strength */ #define JET_SPEED 1.0f /* emitter speed, domain-widths per second */ #define DYE_RATE 25.0f /* dye injected per second at a splat centre */ #define SPLAT_R 6.0f /* splat radius in cells */ #define SIZE ((N + 2) * (N + 2)) /* grid incl. 1-cell boundary ring */ static float *u, *v, *u0, *v0, *curl; /* velocity, scratch, vorticity */ static float *dye[3], *dye0[3]; /* RGB dye, scratch */ static unsigned char *pixels; /* N*N RGBA8 upload buffer */ static inline int IX(int i, int j) { return i + (N + 2) * j; } static void swap_ptr(float **a, float **b) { float *t = *a; *a = *b; *b = t; } static float *alloc_field(void) { return (float *)calloc(SIZE, sizeof(float)); } /* ---------- solver ---------- */ /* b: 0 = scalar, 1 = x-velocity, 2 = y-velocity; walls reflect the normal component */ static void set_bnd(int b, float *x) { for (int i = 1; i <= N; i++) { x[IX(0, i)] = (b == 1) ? -x[IX(1, i)] : x[IX(1, i)]; x[IX(N + 1, i)] = (b == 1) ? -x[IX(N, i)] : x[IX(N, i)]; x[IX(i, 0)] = (b == 2) ? -x[IX(i, 1)] : x[IX(i, 1)]; x[IX(i, N + 1)] = (b == 2) ? -x[IX(i, N)] : x[IX(i, N)]; } x[IX(0, 0)] = 0.5f * (x[IX(1, 0)] + x[IX(0, 1)]); x[IX(0, N + 1)] = 0.5f * (x[IX(1, N + 1)] + x[IX(0, N)]); x[IX(N + 1, 0)] = 0.5f * (x[IX(N, 0)] + x[IX(N + 1, 1)]); x[IX(N + 1, N + 1)] = 0.5f * (x[IX(N, N + 1)] + x[IX(N + 1, N)]); } /* Gauss-Seidel relaxation of x = (x0 + a*sum(neighbours)) / c -- THE hot loop */ static void lin_solve(int b, float *x, const float *x0, float a, float c, int iters) { float inv_c = 1.0f / c; for (int k = 0; k < iters; k++) { for (int j = 1; j <= N; j++) for (int i = 1; i <= N; i++) x[IX(i, j)] = (x0[IX(i, j)] + a * (x[IX(i - 1, j)] + x[IX(i + 1, j)] + x[IX(i, j - 1)] + x[IX(i, j + 1)])) * inv_c; set_bnd(b, x); } } static void diffuse(int b, float *x, const float *x0, float diff, float dt) { float a = dt * diff * (float)N * (float)N; lin_solve(b, x, x0, a, 1.0f + 4.0f * a, ITERS); } /* semi-Lagrangian advection: trace each cell centre backwards, bilinearly sample d0 */ static void advect(int b, float *d, const float *d0, const float *vx, const float *vy, float dt) { float dt0 = dt * (float)N; for (int j = 1; j <= N; j++) { for (int i = 1; i <= N; i++) { float x = (float)i - dt0 * vx[IX(i, j)]; float y = (float)j - dt0 * vy[IX(i, j)]; if (x < 0.5f) x = 0.5f; if (x > (float)N + 0.5f) x = (float)N + 0.5f; if (y < 0.5f) y = 0.5f; if (y > (float)N + 0.5f) y = (float)N + 0.5f; int i0 = (int)x, i1 = i0 + 1; int j0 = (int)y, j1 = j0 + 1; float s1 = x - (float)i0, s0 = 1.0f - s1; float t1 = y - (float)j0, t0 = 1.0f - t1; d[IX(i, j)] = s0 * (t0 * d0[IX(i0, j0)] + t1 * d0[IX(i0, j1)]) + s1 * (t0 * d0[IX(i1, j0)] + t1 * d0[IX(i1, j1)]); } } set_bnd(b, d); } /* enforce incompressibility: solve Poisson for pressure, subtract its gradient */ static void project(float *vx, float *vy, float *p, float *div) { float h = 1.0f / (float)N; for (int j = 1; j <= N; j++) for (int i = 1; i <= N; i++) { div[IX(i, j)] = -0.5f * h * (vx[IX(i + 1, j)] - vx[IX(i - 1, j)] + vy[IX(i, j + 1)] - vy[IX(i, j - 1)]); p[IX(i, j)] = 0.0f; } set_bnd(0, div); set_bnd(0, p); lin_solve(0, p, div, 1.0f, 4.0f, ITERS); for (int j = 1; j <= N; j++) for (int i = 1; i <= N; i++) { vx[IX(i, j)] -= 0.5f * (p[IX(i + 1, j)] - p[IX(i - 1, j)]) / h; vy[IX(i, j)] -= 0.5f * (p[IX(i, j + 1)] - p[IX(i, j - 1)]) / h; } set_bnd(1, vx); set_bnd(2, vy); } /* vorticity confinement: push fluid toward vortex cores to undo numerical smoothing */ static void vorticity_confinement(float dt) { for (int j = 1; j <= N; j++) for (int i = 1; i <= N; i++) curl[IX(i, j)] = 0.5f * ((v[IX(i + 1, j)] - v[IX(i - 1, j)]) - (u[IX(i, j + 1)] - u[IX(i, j - 1)])); for (int j = 2; j < N; j++) for (int i = 2; i < N; i++) { float gx = fabsf(curl[IX(i + 1, j)]) - fabsf(curl[IX(i - 1, j)]); float gy = fabsf(curl[IX(i, j + 1)]) - fabsf(curl[IX(i, j - 1)]); float len = sqrtf(gx * gx + gy * gy) + 1e-5f; float w = curl[IX(i, j)] * VORTICITY * dt / len; u[IX(i, j)] += gy * w; v[IX(i, j)] -= gx * w; } } static void vel_step(float dt) { if (VORTICITY > 0.0f) vorticity_confinement(dt); if (VISC > 0.0f) { swap_ptr(&u0, &u); diffuse(1, u, u0, VISC, dt); swap_ptr(&v0, &v); diffuse(2, v, v0, VISC, dt); } swap_ptr(&u0, &u); swap_ptr(&v0, &v); advect(1, u, u0, u0, v0, dt); advect(2, v, v0, u0, v0, dt); project(u, v, u0, v0); } static void dye_step(float dt) { float keep = expf(-FADE * dt); for (int c = 0; c < 3; c++) { swap_ptr(&dye0[c], &dye[c]); advect(0, dye[c], dye0[c], u, v, dt); for (int k = 0; k < SIZE; k++) dye[c][k] *= keep; } } /* Gaussian splat. set=0: add val; set=1: blend toward val (inflow condition) */ static void splat(float *f, float cx, float cy, float r, float val, int set) { int i0 = (int)(cx - r), i1 = (int)(cx + r) + 1; int j0 = (int)(cy - r), j1 = (int)(cy + r) + 1; if (i0 < 1) i0 = 1; if (i1 > N) i1 = N; if (j0 < 1) j0 = 1; if (j1 > N) j1 = N; float inv = 1.0f / (0.5f * r * r); for (int j = j0; j <= j1; j++) for (int i = i0; i <= i1; i++) { float dx = (float)i - cx, dy = (float)j - cy; float w = expf(-(dx * dx + dy * dy) * inv); int k = IX(i, j); f[k] = set ? f[k] + (val - f[k]) * w : f[k] + val * w; } } static void hsv_to_rgb(float h, float s, float v, float *r, float *g, float *b) { float c = v * s, hp = fmodf(h, 360.0f) / 60.0f; float x = c * (1.0f - fabsf(fmodf(hp, 2.0f) - 1.0f)); float r1 = 0, g1 = 0, b1 = 0; if (hp < 1) { r1 = c; g1 = x; } else if (hp < 2) { r1 = x; g1 = c; } else if (hp < 3) { g1 = c; b1 = x; } else if (hp < 4) { g1 = x; b1 = c; } else if (hp < 5) { r1 = x; b1 = c; } else { r1 = c; b1 = x; } float m = v - c; *r = r1 + m; *g = g1 + m; *b = b1 + m; } /* dye -> RGBA8 with a soft tone-map so colours never blow out */ static void render(void) { int p = 0; for (int j = 1; j <= N; j++) for (int i = 1; i <= N; i++) { int k = IX(i, j); for (int c = 0; c < 3; c++) { float t = 2.0f * dye[c][k]; pixels[p++] = (unsigned char)(255.0f * t / (1.0f + t)); } pixels[p++] = 255; } } static void reset(void) { memset(u, 0, SIZE * sizeof(float)); memset(v, 0, SIZE * sizeof(float)); for (int c = 0; c < 3; c++) memset(dye[c], 0, SIZE * sizeof(float)); } int main(void) { const int W = N * SCALE, H = N * SCALE; InitWindow(W, H, "stable fluids - raylib via C FFI"); SetTargetFPS(60); rl_canvas_create(N, N); u = alloc_field(); v = alloc_field(); u0 = alloc_field(); v0 = alloc_field(); curl = alloc_field(); for (int c = 0; c < 3; c++) { dye[c] = alloc_field(); dye0[c] = alloc_field(); } pixels = (unsigned char *)malloc((size_t)N * N * 4); float pmx = (float)GetMouseX(), pmy = (float)GetMouseY(); while (!WindowShouldClose()) { float dt = GetFrameTime(); if (dt > 0.033f) dt = 0.033f; /* a hitch must not become a huge step */ float t = (float)GetTime(); if (IsKeyPressed(KEY_R)) reset(); float cr, cg, cb; /* dye colour cycles through the spectrum */ hsv_to_rgb(fmodf(t * 40.0f, 360.0f), 0.85f, 1.0f, &cr, &cg, &cb); float mx = (float)GetMouseX(), my = (float)GetMouseY(); float sx, sy, fx, fy; int mode; if (IsMouseButtonDown(MOUSE_BUTTON_LEFT)) { /* stir: mouse motion becomes velocity */ sx = 1.0f + mx * (float)N / (float)W; sy = 1.0f + my * (float)N / (float)H; fx = FORCE * (mx - pmx) / (float)W; fy = FORCE * (my - pmy) / (float)H; mode = 0; } else { /* idle: emitter orbits, firing along its path */ float a = t * 0.6f; sx = 1.0f + (float)N * (0.5f + 0.28f * cosf(a)); sy = 1.0f + (float)N * (0.5f + 0.28f * sinf(a)); fx = -JET_SPEED * sinf(a); fy = JET_SPEED * cosf(a); mode = 1; } splat(u, sx, sy, SPLAT_R, fx, mode); splat(v, sx, sy, SPLAT_R, fy, mode); splat(dye[0], sx, sy, SPLAT_R, DYE_RATE * dt * cr, 0); splat(dye[1], sx, sy, SPLAT_R, DYE_RATE * dt * cg, 0); splat(dye[2], sx, sy, SPLAT_R, DYE_RATE * dt * cb, 0); pmx = mx; pmy = my; vel_step(dt); dye_step(dt); render(); rl_canvas_update(pixels); BeginDrawing(); rl_clear(0, 0, 0); rl_canvas_draw((float)SCALE); DrawFPS(10, 10); rl_text("left-drag: stir R: reset", 10, H - 28, 20, 200, 200, 200); EndDrawing(); } rl_canvas_destroy(); CloseWindow(); return 0; } ``` ### `rlshim.h` / `rlshim.c` — hides raylib's struct-by-value calls raylib passes `Texture2D` (20 bytes), `Image`, `Vector2` and `Color` **by value**. That's the one thing most small-language FFIs can't do portably (SysV packs `Vector2` into one XMM register, AArch64 uses two FP registers, Win64 passes >8-byte structs by hidden pointer…). This shim turns all of it into ints, floats and pointers: ```c /* rlshim.h */ void rl_canvas_create(int w, int h); void rl_canvas_update(const void *rgba8); void rl_canvas_draw(float scale); void rl_canvas_destroy(void); void rl_clear(int r, int g, int b); void rl_text(const char *s, int x, int y, int size, int r, int g, int b); ``` ```c /* rlshim.c */ #include "raylib.h" static Texture2D canvas; void rl_canvas_create(int w, int h) { Image img = GenImageColor(w, h, BLACK); /* R8G8B8A8, w*h*4 bytes */ canvas = LoadTextureFromImage(img); UnloadImage(img); SetTextureFilter(canvas, TEXTURE_FILTER_BILINEAR); } void rl_canvas_update(const void *rgba8) { UpdateTexture(canvas, rgba8); } void rl_canvas_draw(float scale) { DrawTextureEx(canvas, (Vector2){0, 0}, 0.0f, scale, WHITE); } void rl_canvas_destroy(void) { UnloadTexture(canvas); } void rl_clear(int r, int g, int b) { ClearBackground((Color){(unsigned char)r, (unsigned char)g, (unsigned char)b, 255}); } void rl_text(const char *s, int x, int y, int size, int r, int g, int b) { DrawText(s, x, y, size, (Color){(unsigned char)r, (unsigned char)g, (unsigned char)b, 255}); } ``` Build it as an object for a compiled Zane (`cc -O2 -c rlshim.c`) or as a shared library if Zane's FFI is `dlopen`-style (`cc -O2 -shared -fPIC rlshim.c -o librlshim.so $(pkg-config --libs raylib)`). ## Porting to Zane **The complete FFI surface** — translate these prototypes into Zane's `extern` syntax, whatever it is: | C prototype | Notes | |---|---| | `void InitWindow(int, int, const char*)` | string = pointer to NUL-terminated bytes | | `void SetTargetFPS(int)` | | | `bool WindowShouldClose(void)` | declare the return as an 8-bit int, test `!= 0` | | `void CloseWindow(void)` | | | `float GetFrameTime(void)` | 32-bit float return | | `double GetTime(void)` | 64-bit double return | | `int GetMouseX(void)`, `int GetMouseY(void)` | | | `bool IsMouseButtonDown(int)` | `MOUSE_BUTTON_LEFT = 0` | | `bool IsKeyPressed(int)` | `KEY_R = 82` | | `void BeginDrawing(void)`, `void EndDrawing(void)` | | | `void DrawFPS(int, int)` | | | the six `rl_*` shim functions | pointer args are raw addresses | | `float expf/sqrtf/fabsf/cosf/sinf(float)`, `float fmodf(float,float)` | from libm, only if Zane lacks them | | `void *calloc(size_t, size_t)` | only if Zane has no heap arrays | **Language features the sim needs:** functions, loops, `if`, f32 arithmetic with int↔float casts, nine contiguous f32 buffers of `(N+2)²` elements plus one u8 buffer whose base address can be handed to C (if Zane arrays carry a header, pass the data pointer), and the ability to swap two buffer references (`swap_ptr`). If Zane's FFI only speaks `double`, change `rl_canvas_draw` to take `double` and add `double rl_frame_time(void) { return GetFrameTime(); }` to the shim — C `float` arguments are *not* promoted on prototyped calls, so passing a double where a float is expected is the classic silent FFI bug. **Why this is a good showcase:** `lin_solve` is the kind of loop that exposes a compiler — pure float arithmetic with neighbour indexing over a 2.4 MB working set, no calls. At `N=256` C at `-O2` does the frame in ~3 ms; whatever Zane produces, the FPS counter tells you exactly where its codegen stands (bounds checks and non-inlined `IX` show up directly). Suggested incremental path: get a window with `rl_clear` + `DrawFPS` first, then the canvas with a test gradient, then drop the solver in.

Zane visual demo