A shader could only say what colour a pixel has. Where the picture
is drawn was fixed to the four corners of its rectangle, so nothing
could wave, bend or wobble.
- The new node Vertex output takes x and y, in pixels of the
picture, and moves every corner of the wearer's grid by them. The
UVs stay with the corners, so the picture bends along.
- Subdivisions on that node says how fine the grid is: cells per
axis, 1 to 64, 8 by default. 1 is the plain quad. A shader without
the node keeps the quad every sprite shares.
- A graph holds one Vertex output at most. UV, Time, Property,
Number and the math nodes may feed it, and one node may feed both
outputs.
- Texture color, Texture alpha, Sample texture, Texture size and
Color cannot feed it. The node says "Not available per corner"
and the shader does not compile.
- Sprites, texts and the preview in the shader tab wear the grid.
A nine-slice sprite and particles draw as if the node were not
there.
- Picking, the selection frame, the size and colliders stay with
the rectangle. A wearer with a Vertex output is never culled, as
with Padding, and with Padding the grid covers the room around
the picture too.
- tools/perf-shaders.mjs takes GM_PERF_SUBDIVISIONS to measure a
grid against the plain quad.
Measured on stein2 (Intel HD 630), frames per second, one run per
row: at 800 sprites 58 with a shader on the quad, 46 with 8 cells,
41 with 32. Up to 400 sprites a grid hardly shows. Every sprite
holds its own grid.
Tests:
- Gate on melektaus-atx: 220 files, 3416 tests, CHECK EXIT 0.
- 15 new unit tests for the compiler and the grid.
- Four new e2e checks in modules 28 and 30: a fixed offset moves
the picture, 8 cells bend only the lower half where 1 cell shears
it all, Texture alpha is refused at the node, a text moves.
- e2e 28,30 on melektaus-atx: 110 checks, all pass.
- The e2e total of 1699 is counted (1695 + 4), the full suite did
not run.
- No counter-probe, no screenshot. Not looked at: the preview, Time
in the browser, flipped sprites, Padding together with the grid.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A sprite's picture is now a Mesh (unit quad, sibling of its Graphics node, which keeps
only the hit area); a worn shader replaces Pixi's fragment in that draw, so there is no
intermediate texture and no extra render pass. Measured on the HD 630: 400 shaded
sprites hold 60 fps (was 34), 800 hold 56 (was 20).
Two Pixi facts the code leans on: a mesh's texture is bound only for Pixi's own shader,
so GraphShader.wear hands it over; and MeshPipe caches whether a mesh batches and
re-checks it only in a frame without structure changes, so switching a shader on or
off calls mesh.unload().
The console panel mirrors console.group/groupCollapsed/groupEnd and fills the %s %d
%o %c directives, so Pixi's deprecation warning shows its head, not only its stack.
E2E 12 guards against the addChild-on-Graphics warning, 28 counts shaders instead of
filters.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The wiki carried an estimate ("fine for dozens, not for thousands"). Measured
on the Intel HD 630 that CI uses, 48x48 sprites in a 640x360 camera, neutral
values, three runs agreeing to 1 fps:
sprites 25 50 100 200 400 800
fps 58 56 54 48 34 20
The same scene without shaders holds 60 fps at every one of those counts, 800
included. Quadrupling the sprite area (96x96) measures the same, so the cost is
the render target switch, not the pixels: roughly 20 us per pass up to 200,
40 us at 800.
tools/perf-shaders.mjs drives it (not run in CI, frame times are machine
dependent). New hook __gm.filterCount() counts visible nodes carrying a filter
and proves one pass per sprite; e2e 28 checks it.
Two traps the tool guards against, both cost a wrong answer first: the median
frame time is useless here (the distribution is bimodal under vsync, so the
rate comes from frames/duration), and --disable-gpu-vsync has no effect in
headless, so what is measured is the point where the frame rate breaks down.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
adminandClaude Opus 5.5