GasVentField called queue_redraw() every frame and its _draw rebuilt six
vents of seven glowing polygons each - 168 antialiased polylines
re-tessellated per frame, since every NeonDraw call expands into four.
Measured first: 40 rasterisations over 30 frames, costing 6.6ms against a
32.4ms floor. For scale, the black hole's cached disc costs 0.1ms.
Both halves are pieces now. The sources never move, never recolour and never
fade, so they are rasterised once. The rising bubbles genuinely change size
and opacity, but size is scale and opacity is modulate - neither needs the
geometry rebuilding. 40 rasterisations over 30 frames became 0.
Two things worth recording.
The static extraction alone measured NOTHING - 7.1ms against 6.6ms, inside
the noise. softpipe is a CPU rasteriser: it prices FILL, and cached geometry
fills the same pixels. It cannot see a tessellation saving at all. After the
full change the frame time read NEGATIVE with the floor drifting 28 to 39ms
between runs, so no millisecond figure is claimed here. The rasterisation
count is the reproducible result; what it is worth on a phone is unmeasured.
And scaling a NeonPiece scales its STROKE with it. The bubbles were first
built as unit circles scaled up by their radius, which multiplied NeonDraw's
widths by five to fourteen - a hundred pixels of glow around a fourteen
pixel bubble. They rendered as bright blobs, the rasterisation count said
40 -> 0, and only the screenshot disagreed. Built at the largest radius and
scaled DOWN now, so the stroke only ever thins. The trap is noted at the
call site: scale is safe for moving and shrinking a piece and quietly wrong
for growing one.
NeonPiece.add_polygon gained a width, which it needed to keep the vents'
authored stroke rather than silently fattening them.
179/179.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019AJMdB7iuHuLFZM1aBu3GD
On a gas planet the vents were drawn on top of the player. SurfaceFeatures
is added after Fleet in PlanetSurface.tscn, so at the default z_index of 0
the vent field won the tie purely by being the later sibling, and the fleet
flew under its own gas source.
Same one-line fix, for the same reason, as #50's capture rings and the
rocks on a rocky surface. It goes on the field rather than on children
because this one draws in its own _draw().
The test checks the rule instead of the node that was wrong: every drawing
feature, on every surface profile that has features, must end up behind the
fleet - 22 of them today, and any added later without editing the test.
Enemies are excluded and the test says why; they are combatants and share
the fleet's plane on purpose.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Everything lived in one flat directory, so a diff gave no clue what area it
touched and finding the file you wanted meant knowing its exact name. Twelve
folders now, grouped by what a thing IS rather than what type it is - a
vessel's definition, its component scenes and its upgrade resources sit
together, because that is the set you read when you change one of them.
buildings core controllers enemies logistics planets
resources shaders surface ui vessels vfx world
332 files moved and every res:// reference rewritten - 306 files touched,
including the autoload and main-scene paths in project.godot. Nothing renamed:
this is purely where files sit, so the diff is a pile of pure moves and no
behaviour is buried in it. ui_theme.tres, icon.svg and web_shell.html stay at
the root, where Godot and the export preset expect them.
Verified three ways, because a suite alone would not have caught all of it:
the full 117 pass, the web export builds clean, and the game renders.
The export is why that matters. The FIRST export after the move failed with
"Attempt to open script 'res://GameState.gd'" - the old path - while
project.godot on disk plainly said res://core/GameState.gd. That is this
project's documented Android FUSE mtime trap: Godot served a cached copy of a
file whose content had changed. A `touch` fixed it. Nothing in the test suite
would have found that, because the suite runs from a copy on a native
filesystem - the one place the bug cannot happen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>