Properties node: shader params are named by their shader (#66)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
rootandClaude Opus 5 committed 2026-09-13 14:05:10 +02:00
1 parent c5bc04d969
commit 46d30db966
3 files changed
+11 -4

No files matched your search

+5 -1
@@ -21,7 +21,11 @@ shown on the node and editable in the inspector.
`+ Property` offers: *Sprite*, *Text*, *Collider*, *Camera* and *Container* offer their fields,
*Behavior* the variables of the behavior picked below it (renaming such a variable carries the
port along, in any graph), and *Any* offers the kinds (Number, Text, …) and leaves the name to be
typed. A picked property keeps its field and default — an unconnected `color` is a colour field
typed. Under *Sprite* the list goes on with the parameters of every shader in the project, since
which sprite the node will meet is only known while the game runs; each of those entries names the
shader it belongs to — `glow (Neon glow)`, and `brightness (Adjust colors, Neon glow)` for a name
two shaders both use (one entry, one port: the name is what a sprite stores it under).
A picked property keeps its field and default — an unconnected `color` is a colour field
starting white, shown on the node as `#ffffff`, and a camera's `width` is its whole-pixel view
width. Switching the type keeps the ports; one the new type lacks is marked. The node shows its
type as a setting row (*Type: Sprite*, plus *Behavior: Game* under that type). Textures and
+2 -2
@@ -12,7 +12,7 @@ npm run check # typecheck + lint + format:check + tests, the gate CI runs
# code is lost (tail's is reported), so a red run reads as green
npm run build # writes dist/ and regenerates index.html
./build.sh # the same under `set -o pipefail`, for callers that pipe the output
node tools/seed-e2e.mjs && node tools/e2e.mjs # 725 editor checks, screenshots in /tmp/gm-e2e-*.png
node tools/seed-e2e.mjs && node tools/e2e.mjs # 727 editor checks, screenshots in /tmp/gm-e2e-*.png
GM_STEPS=20 node tools/e2e.mjs # or 1-12, or 6,20 — a subset while working on one step
./e2e.sh start [GM_STEPS] # the same run detached, see below
./e2e.sh status # live progress, or the last run's result
@@ -150,4 +150,4 @@ widths to find click points. The **render device is not in this repo** — `/dev
and a 1 GB `/dev/shm` come from `container.options` in the runner's own `config.yaml`, which
applies to every job on that runner. Without them chromium falls back to llvmpipe, which gets
WebGL 1.0 only. Measured in the job container: `ANGLE (Intel, Vulkan 1.3.230, HD Graphics 630)`,
WebGL 2.0, and the same 725 checks as here.
WebGL 2.0, and the same 727 checks as here.
+4 -1
@@ -70,7 +70,10 @@ The sprite's `Shader` row is a picker over the project's shader assets (`None` i
extra render pass). The rows below it are the shader's `Property` nodes, in node order; they are
ordinary sprite properties: overridable per placed object, reset (↺) and apply (↑) like any other,
readable and writable by a `Properties` node at runtime — a behavior can fade a sprite by writing
its `brightness` every frame. A value with no row (the shader was switched, the property renamed)
its `brightness` every frame. That node's `+ Property` list (under *Type: Sprite*) offers the
parameters of every shader in the project, each naming the shader it comes from, because the sprite
it will be handed is only known while the game runs; writing a parameter the worn shader does not
have is stored and ignored. A value with no row (the shader was switched, the property renamed)
stays stored but marks nothing; it comes back with the shader.
A placed object may override the shader itself; it then shows *that* shader's rows. Switching the