Why generated graphics code is wrong in visible ways
No type error, no stack trace, no failing test. Just something on screen that looks about right, and a model that will defend it.
Every other kind of code you generate has a critic somewhere: a type checker, a linter, a test, an exception. Graphics code has none. A shader with the wrong aspect correction compiles, runs at full frame rate and produces a picture, and the only signal that anything is wrong is that the circles are eggs and you have to notice.
The failure modes repeat with remarkable consistency. Normalising by both axes and squashing everything. Calling a sine-based hash noise. Fixed-width smoothstep edges that alias at one resolution and blur at another. Ignoring device pixel ratio. Sizing the canvas once and never on resize. Animating without checking prefers-reduced-motion. Precision that only breaks after a minute on a phone. That is the list, and it covers most of what you will find.
The counter-practice is to write down what should be true before you look: the circle must stay circular at any window shape, the edge must stay one pixel wide at any resolution, the pattern must be identical on two machines, and then check each one deliberately. It is the same discipline as evals in Phase 08, applied to something you judge with your eyes.
You should now be able to
- List the recurring failure modes of generated shader code
- Design a check that would catch a wrong-maths bug
Loading…