API reference

Every public class, method, and event in @codexo/exojs. Generated from source.

C

classTileMapView

@codexo/exojs-tilemap / tilemap / stable

Groups a TileMap's layers into independently placeable scene nodes so application actors can be interleaved **between** tile layers. A view produces exactly one canonical TileLayerNode per map layer (stable identity, map document order) and, optionally, named TileMapBands grouping subsets of those nodes. The application parents the bands / layer nodes wherever it wants - typically as siblings of its own actor containers: ```ts const view = map.createView({ bands: { ground: ['background', 'ground'], roof: ['roofs'] } }); worldRoot.addChild(view.band('ground'), actors, view.band('roof')); // or without bands: worldRoot.addChild(view.getLayerNodeById(groundId)!, actors, view.getLayerNodeById(roofId)!); ``` **Actors are application-owned siblings.** A `TileMapView` never adopts or destroys actors. The view is a helper, not a scene node - it does not own the world container, the TileMap, the TileLayers, or tileset textures. **Ownership:** the view owns its generated layer nodes and bands. A layer assigned to a band is owned by that band; an unbanded layer is owned by the view directly. TileMapView.destroy destroys every band and layer node (detaching them from their application parents) but leaves actors, the map, its layers, and Loader-owned textures untouched. There is no map-replacement mutation API: to swap maps, destroy the old view, construct a new one, and re-parent its bands - the actor tree is never involved. **Image layers.** A view also produces exactly one canonical ImageLayerNode per TileMap.imageLayers entry (stable identity, map document order), reachable through imageLayerNodes, getImageLayerNodeById, and getImageLayerNodeByName. Image layers are selectable in TileMapViewOptions.bands exactly like tile layers: a band member list may mix both kinds, and the band stacks its members by the map's combined document order (import('./TileMap').TileMap.renderableLayers). A banded image node is owned by its band; an unbanded one is owned by the view directly, and the application parents it wherever the image belongs in draw order - the same way actors are interleaved.

6
props
8
methods
0
events
Import
import { TileMapView } from '@codexo/exojs-tilemap'

Groups a TileMap's layers into independently placeable scene nodes so application actors can be interleaved **between** tile layers.

A view produces exactly one canonical TileLayerNode per map layer (stable identity, map document order) and, optionally, named TileMapBands grouping subsets of those nodes. The application parents the bands / layer nodes wherever it wants - typically as siblings of its own actor containers:

```ts const view = map.createView({ bands: { ground: ['background', 'ground'], roof: ['roofs'] } }); worldRoot.addChild(view.band('ground'), actors, view.band('roof')); // or without bands: worldRoot.addChild(view.getLayerNodeById(groundId)!, actors, view.getLayerNodeById(roofId)!); ```

**Actors are application-owned siblings.** A `TileMapView` never adopts or destroys actors. The view is a helper, not a scene node - it does not own the world container, the TileMap, the TileLayers, or tileset textures.

**Ownership:** the view owns its generated layer nodes and bands. A layer assigned to a band is owned by that band; an unbanded layer is owned by the view directly. TileMapView.destroy destroys every band and layer node (detaching them from their application parents) but leaves actors, the map, its layers, and Loader-owned textures untouched. There is no map-replacement mutation API: to swap maps, destroy the old view, construct a new one, and re-parent its bands - the actor tree is never involved.

**Image layers.** A view also produces exactly one canonical ImageLayerNode per TileMap.imageLayers entry (stable identity, map document order), reachable through imageLayerNodes, getImageLayerNodeById, and getImageLayerNodeByName. Image layers are selectable in TileMapViewOptions.bands exactly like tile layers: a band member list may mix both kinds, and the band stacks its members by the map's combined document order (import('./TileMap').TileMap.renderableLayers). A banded image node is owned by its band; an unbanded one is owned by the view directly, and the application parents it wherever the image belongs in draw order - the same way actors are interleaved.

Constructors1
Methods8
destroy(): void
Destroy the view: every band, generated tile-layer node, and generated ImageLayerNode is destroyed (and detached from its application parent), freeing cached chunk geometry. Banded nodes are destroyed by their band; unbanded ones by the view directly. Idempotent. Application actors, sibling content, the TileMap, its TileLayers and image layers, and Loader-owned textures all survive.
The canonical image layer node for the image layer with the given **id**, or undefined. Ids are authoritative and unique - this is the unambiguous lookup. The returned node may be reparented into the caller's own containers; the view still tracks it for refresh and destruction.
The canonical image layer node for the image layer with the given **name**, or undefined if no image layer has that name. Prefer getImageLayerNodeById when you have the id.
The canonical layer node for the **tile** layer with the given **id**, or undefined. Tile ids are authoritative and unique - this is the unambiguous lookup. The returned node may be reparented into the caller's own containers; the view still tracks it for refresh and destruction.
Every canonical tile-layer node whose layer has the given **name**, in map document order. Layer names are not guaranteed unique, so this returns an array (empty when no layer matches). Prefer getLayerNodeById when you have the id.
hasBand(name: string): boolean
Whether a band with the given name was defined.
refreshLayers(): this
Rebuild the view after **structural** map changes (tile or image layers added to or removed from the map). Ordinary tile edits and chunk creation/removal do NOT need this - those are handled by chunk revisions and TileLayerNode.refresh respectively. - Removed layers (tile or image): their generated node is detached and destroyed. - Unchanged layers: keep their existing node (stable identity). - Added layers (tile or image): a new node is created and assigned to the first band whose definition selects it (by a currently-unambiguous id or name), otherwise owned directly by the view. - Every band's children are re-ordered to the map's combined document order (import('./TileMap').TileMap.renderableLayers). Application actors are never touched, and bands keep their placement in the application scene graph.
Properties6
destroyed: boolean
Whether this view has been destroyed.
Render-only pixel-snap mode applied to every layer node this view owns (and forwarded to every chunk drawable, current and rebuilt by refreshLayers). Snaps tile chunk origins to the active render target's device-pixel grid for crisp tiles; with integer tile pitch the grid stays exact and adjacent chunks cannot drift apart. Purely visual - tile data, layer offsets, chunk revisions, and culling are unchanged. Setting the current value is a no-op; an invalid value throws and leaves the prior mode unchanged. Defaults to Geometry because a tile grid is made of quads that share their edges: left unsnapped, a boundary landing between two device pixels is sampled across both, so the seams blur and shimmer as the view moves. Set None to opt out.
Source