Tiled.read / Tiled.read_tsx (runtime/native/tiled.ludic): map the native
XML formats (TMX/TSX/TX) onto the SAME intermediate the JSON path produces
— a Value tree in Tiled's JSON schema — so one format-independent core
(P1) consumes either reader.
- tmx_to_value walks a <map> into {orientation, width/height, tilewidth/
height, tilesets[], layers[]}; every tile layer's <data> is decoded to a
dense GID int list (CSV split, or base64 -> zlib/gzip inflate ->
little-endian u32s), so a CSV .tmx and a base64 .tmj of the same map read
structurally identically.
- External tilesets keep the {firstgid, source} reference (as TMJ does);
embedded tilesets and standalone .tsx (tsx_to_value) inline full geometry
+ per-tile metadata (animation frames, collision objectgroup, class,
properties) for later phases.
- Object layers, shapes (rect/ellipse/point/polygon/polyline/text),
image/group layers and custom properties are parsed into the tree now so
P2/P4/P5 just read it.
- tmj_normalize decodes base64 `data` strings in a parsed .tmj so the JSON
path matches the XML path.
Proven by library/tiled_p05.ludic (30 assertions) incl. the in-repo Kenney
sampleMap.tmx + external sampleSheet.tsx and TMX-vs-TMJ structural
identity. Docs + inventory added; x test: 91 passed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
14 lines
806 B
Markdown
14 lines
806 B
Markdown
---
|
|
id: tiled-read
|
|
name: Tiled.read
|
|
category: tiled
|
|
kind: namespace-method
|
|
tokens: Tiled.read
|
|
sig: Tiled.read(path: string) -> value
|
|
tip: Read a map file into the intermediate value tree.
|
|
order: 1
|
|
ns: Tiled
|
|
member: read
|
|
---
|
|
|
|
Reads a Tiled map file at <code>path</code> — auto-detecting TMX (XML) vs TMJ (JSON) by its first byte — and returns the intermediate map <a href="value"><code>Value</code></a> tree in Tiled's JSON schema: <code>orientation</code>, <code>width</code>/<code>height</code>, <code>tilewidth</code>/<code>tileheight</code>, a <code>tilesets</code> list and a <code>layers</code> list. Every tile layer's <code>data</code> is decoded to a dense GID int list (CSV split, or base64 → zlib/gzip inflate → little-endian u32s), so the two formats yield structurally identical trees.
|