Change Log

All notable changes to bresenham-lighting-engine are documented here. This project follows Semantic Versioning.

[Unreleased] — 2026-08-01

The engine emits transport masks only (ADR-0010, main repo issue #110). put now returns a white radial-falloff mask — RGB always 255, alpha = linear attenuation (curve shaping is renderer-side) — and put_ambient lost its r/g/b parameters, returning an opaque-white room-fill mask. Colour and intensity are applied renderer-side (tint × mask).

ColorMode (Solid/Custom/Rgb), hsv2rgb, and every colour-carrying light API: put_solid_color, put_custom_color, put_rgb and their update_or_add_light_with_* counterparts. There is no colour path left in the engine to collapse (#72 fixed by construction).

LightingEngine type (src/engine.rs). Construct one with LightingEngine::new() and call methods on it directly. Each engine owns its own tile map, block map, collision system, and light registry — multiple engines can coexist in one process. This unlocks two things that were previously impossible:
- Parallel tests: each test builds its own engine, so the default cargo test thread pool no longer races on shared globals.
- Embedding: Rust callers (servers, level editors, comparison harnesses) can hold more than one scene at a time. See ADR-0007.
LightingEngine::render_canvas_text(light_id) — ASCII-matrix view of a light's canvas, suitable for stdout, panic messages, or piping to other tools.
Scenarios module (src/scenarios/) — plain Rust functions like single_light and object_shadow that populate a LightingEngine. Shared between the exploration CLI and the regression tests so the same scene definition drives both.
scenario example — cargo run --example scenario -- --list enumerates the available scenarios; --name <NAME> prints the ASCII matrix; --output-format png --out path.png renders a PNG.
CONTEXT.md — canonical vocabulary (Tile, Cell, Wall, Object, Room, LightingEngine, Light, Canvas, Ray). Read this before contributing.
.cargo/config.toml sets RUST_MIN_STACK=8388608 so cargo test works without remembering the env var.

lighting::*, collision::*, and block_map::* free functions are now thin shims that forward to a process-wide DEFAULT_ENGINE singleton. WASM/JS callers are unaffected — every #[wasm_bindgen] function keeps its current name and signature, including put, put_solid_color, put_custom_color, set_tile, set_map_data, set_pixel, set_pixel_batch, clear_pixel_collisions, get_tiles, and get_blockmap.
New Rust code should prefer LightingEngine methods; the free functions exist for back-compat and operate on a shared global, which serialises callers under a RwLock.

IsBlockedFn and reset_is_blocked_fn (dead since the collision-system rewrite — they were never read at runtime).
TileCollisionMap (superseded by the unified HybridCollisionMap in ADR-0006; was no longer reachable from any code path).
VISUAL_TESTING.md, tests/output_mechanisms.rs, tests/README.md, the test_output/ and test_output.before/ directories, and benches/collision_performance.rs. The PNG-snapshot harness they described had silently broken when the collision modes were unified — every "obstacle" snapshot in version control was either from pre-unification code or from post-unification code with no occlusion wired up. Replaced by the scenarios CLI and tests/scenarios.rs.

JS / WASM callers: no change required. The pkg/ artifact keeps the same exports and ABI.
Rust callers using free functions: still work, but each call now takes the global write lock. For tests or any code that wants independent scenes, switch to LightingEngine::new() and call methods on the instance directly.
Test authors: do not use DEFAULT_ENGINE from tests. Each test must construct its own LightingEngine — that is what makes parallel test execution safe.

See git log for prior history.