fix(maps): v0.5.6 — derive bitmask from cell's own corner paint-tiles

compute_cell_bitmask_v3 now reads the 8-bit neighbour bitmask from
the render-cell's own 4 corner paint-tiles (cardinal bit set iff
at least one of the 2 paint-tiles on that edge is painted; diagonal
bit set iff the corner paint-tile is painted), not from the
any-corner material status of the 8 neighbour render-cells.

Pre-0.5.6 used cell-neighbour-material, which let two cells share
connectivity across an empty paint-tile gap whenever any unrelated
corner of either was painted — producing connected blob shapes
where two visually separated 2x2 islands were expected.

Atlas, paint storage, override sublayer, public API and the slot
lookup table all unchanged. Doc comment and README painting-model
section rewritten to describe the dual-grid offset explicitly.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Axel Meyer
2026-06-01 17:19:26 +02:00
parent e3b6e38c5a
commit b5621c5d08
3 changed files with 79 additions and 31 deletions

View File

@@ -140,21 +140,36 @@ local LAYER_ORDER_TOP_DOWN = {
"topsurface", "surface", "subsurface", "foundation",
}
-- 47-Blob Autotile (Schema-v3 vertex-painted layers, 0.5.0c)
-- Dual-Grid Autotile (Schema-v3 vertex-painted layers, 0.5.0c)
--
-- The cell-state for an autotile cell is derived from the layer's
-- vertex grid using the "any-corner" rule: cell (x, y) is material
-- iff any of its 4 corner vertices (x, y), (x+1, y), (x, y+1), or
-- (x+1, y+1) is painted. A single painted vertex thus produces a
-- 2x2 mini-blob of material cells centred on the vertex.
-- Two grids, offset by half a tile. The PAINT grid (called `vertices`
-- in code, "map-tiles" in design docs) stores material flags at
-- integer positions. The RENDER grid (called `cells`) is offset by
-- (+0.5, +0.5) tile from the paint grid and is where sprites sit.
-- Each render-cell (x, y) spans 4 surrounding paint-tiles, which act
-- as its 4 corner vertices: TL=(x,y), TR=(x+1,y), BL=(x,y+1),
-- BR=(x+1,y+1).
--
-- Given the derived per-cell material-state, each cell computes its
-- 8-bit neighbour bitmask (clockwise from north, LSB-first): N, NE,
-- E, SE, S, SW, W, NW. The blob-gating rule then zeroes a diagonal
-- bit unless both adjacent cardinal bits are set. The resulting
-- gated bitmask resolves through SLOT_LOOKUP into one of the 14
-- canonical S-V2E2-RM-Blob slots plus the rotation + flip that
-- transforms the canonical sprite into the rendered one.
-- Material rule ("any-corner"): render-cell (x, y) is material iff
-- any of its 4 corner paint-tiles is painted. A single painted tile
-- thus produces a 2x2 of material render-cells centred on it.
--
-- Bitmask rule (0.5.6, dual-grid native): each render-cell's 8-bit
-- neighbour bitmask (clockwise from N: N, NE, E, SE, S, SW, W, NW)
-- is derived from its own 4 corner paint-tiles. A cardinal bit is
-- set iff at least one of the 2 paint-tiles on that edge is painted;
-- a diagonal bit is set iff the corner paint-tile in that direction
-- is painted. Then blob-gating zeroes any diagonal bit whose 2
-- adjacent cardinal bits are not both set. The gated bitmask
-- resolves through SLOT_LOOKUP into one of the 14 canonical
-- S-V2E2-RM-Blob slots plus the rotation + flip that transforms the
-- canonical sprite into the rendered one.
--
-- Pre-0.5.6 derived the bitmask from the material status of the 8
-- neighbour render-cells, which violated dual-grid semantics: two
-- render-cells with an empty shared edge could see each other as
-- material whenever any unrelated corner of either was painted,
-- producing connected blobs across visually empty paint-tile gaps.
-- =====================================================================
-- Canonical 14 slots, keyed by their lowest-numbered representative
@@ -259,16 +274,33 @@ end
-- Returns the blob-gated 8-bit neighbour bitmask for cell (x, y) given
-- the layer's vertex grid + map size. Bit layout (clockwise from N):
-- 0=N, 1=NE, 2=E, 3=SE, 4=S, 5=SW, 6=W, 7=NW.
--
-- 0.5.6: bits derive from the render-cell's own 4 corner map-tiles
-- (= the 4 surrounding vertices in dual-grid terms), not from the
-- material status of the 8 neighbour cells. A cardinal bit is set iff
-- at least one of the 2 vertices on that edge is painted; a diagonal
-- bit is set iff the corner vertex in that direction is painted.
-- Pre-0.5.6 used cell-neighbour-material, which made two cells with a
-- shared unpainted edge see each other as material whenever any other
-- corner of either was painted — producing connected blobs across
-- visually-empty map-tile gaps. See plan
-- 2026-05-29-painting-model-rethink for the discovery.
local function compute_cell_bitmask_v3(vertices, w, h, x, y)
local vw = w + 1
local vh = h + 1
local TL = vertex_at(vertices, vw, vh, x, y ) ~= 0
local TR = vertex_at(vertices, vw, vh, x + 1, y ) ~= 0
local BL = vertex_at(vertices, vw, vh, x, y + 1) ~= 0
local BR = vertex_at(vertices, vw, vh, x + 1, y + 1) ~= 0
local b = 0
if cell_has_material(vertices, w, h, x, y - 1) then b = b | 0x01 end -- N
if cell_has_material(vertices, w, h, x + 1, y - 1) then b = b | 0x02 end -- NE
if cell_has_material(vertices, w, h, x + 1, y ) then b = b | 0x04 end -- E
if cell_has_material(vertices, w, h, x + 1, y + 1) then b = b | 0x08 end -- SE
if cell_has_material(vertices, w, h, x, y + 1) then b = b | 0x10 end -- S
if cell_has_material(vertices, w, h, x - 1, y + 1) then b = b | 0x20 end -- SW
if cell_has_material(vertices, w, h, x - 1, y ) then b = b | 0x40 end -- W
if cell_has_material(vertices, w, h, x - 1, y - 1) then b = b | 0x80 end -- NW
if TL or TR then b = b | 0x01 end -- N edge: TL or TR painted
if TR then b = b | 0x02 end -- NE corner: TR painted
if TR or BR then b = b | 0x04 end -- E edge: TR or BR painted
if BR then b = b | 0x08 end -- SE corner: BR painted
if BL or BR then b = b | 0x10 end -- S edge: BL or BR painted
if BL then b = b | 0x20 end -- SW corner: BL painted
if TL or BL then b = b | 0x40 end -- W edge: TL or BL painted
if TL then b = b | 0x80 end -- NW corner: TL painted
return apply_blob_gating(b)
end