shaders: the glass written once, its Metal and GLSL generated

[foxnne]

The glass written once, in HLSL; its Metal and WebGL GLSL generated from it and checked by the shader job #405 added, instead of three programs kept in step by hand. Keeping them in step is where the shader bugs came from: #373's float3(x) was valid Metal and GLSL and broke the HLSL, and the compiled forms went stale twice.

What changes

• scripts/compile-shaders.sh: every X.hlsl with compiled forms committed beside it, to each of them. SPIR-V, DXIL and Metal by shadercross (the Metal SDL_GPU takes, as the backend's own default shaders already shipped). GLSL ES 3.00 for WebGL2 by spirv-cross from the SPIR-V, with NaN checks relaxed (HLSL's min/max otherwise come out wrapped in isnan tests at every pixel), float precision high, and the names the web binds (vColor, vTextureCoord, uSampler, uTex1, uData). The workflow runs it and compares every form.
• The glass loads the generated Metal and GLSL (LiquidField); the hand-written liquid_glass.metal and liquid_glass.glsl are gone. The HLSL is the one source and carries the explanations the GLSL had.
• The web compiles a complete generated source as it is (web/web.js, a #version line), on WebGL2 only: on WebGL1 the program fails and the glass falls back to its meshes (generated loops are not WebGL1's constant-bounded ones).
• program_example's committed Metal, hand-written to show the interface, is now generated like the rest (same interface).

Verified

• CI's compile check: the backend's default shaders reproduce byte for byte in all three of SPIR-V, DXIL and Metal with this toolchain.
• macOS: the same in-app About dialog captured through the agent with the hand-written Metal (ci: compiled shaders are built in CI and checked against their HLSL #405's build) and the generated one (this build): plain glass differs by a mean of 0.18 of 255, at most 2 (the dither); elsewhere only edges, where the dialog's contents sat a fraction of a pixel apart between the two captures.
• Web (Chromium, WebGL2): the generated GLSL compiles and links against the web's own vertex shader, and uData, uSampler, uTex1 and uMatrix all resolve; this build's menus draw their glass through it, no program failed, and it looks as main's did.
• zig build, zig build test (91/91 steps), zig build test-integration (53/53 steps), zig build check-web.
• Not seen: Windows (D3D12) and Linux (Vulkan), as for ci: compiled shaders are built in CI and checked against their HLSL #405; Firefox and Safari on the web.

🤖 Generated with Claude Code

[foxnne]

This conflicts with main (bd3c719 against today's main), but in one file only: .github/workflows/shaders.yml. #405, which this was stacked on, was squash-merged, so main holds #405's workflow while this branch still carries #405's commits and then rewrites them. In every conflicting hunk this branch's side is the one to keep:

• Header comment: keep this branch's wording ("compiled forms of it (compiled/{spv,dxil,msl,glsl}/X.*) is compiled by scripts/compile-shaders.sh").
• Both paths: lists (pull_request and push): keep the added - "scripts/compile-shaders.sh".
• "Compile and compare": keep the scripts/compile-shaders.sh out run and the find out comparison loop, which replace main's per-file shadercross loop over spv/dxil.

Nothing else conflicts. The compiled SPIR-V and DXIL here are byte-identical to main's, and the HLSL merges to this branch's version, so the committed binaries still match their source after the merge. The other main-side change since you branched (#373's float3(...) → (float3) fix) is already in this branch.

One stale sentence for this PR to fix: LiquidField.publishLook's comment (from #242) still says "the GLSL, the Metal, and the SPIR-V and DXIL compiled from the HLSL — as long as the last two are compiled again whenever the HLSL changes". With this PR all four are compiled from the HLSL by scripts/compile-shaders.sh and checked by the workflow, so it could say that instead.

---

Generated by Claude Code