meleki/feuerwerk

0 Fork 0

Table of Contents

Tilemaps

The asset
Growing and shrinking the grid
Painting
Layers

Sorting by Y

In the running game
From a behavior
Collision

Collision scale
Outlined tiles
The cost of outlined cells
Trigger tiles
One-way tiles

In the project file
What it does not do yet

Tilemaps

A tilemap is a grid painted with tiles, and it is what puts them into a scene: a tile is what lies in a cell, the tilemap is the ground it is laid on. It is an asset like any other, and unlike a tile it is placed — drag it from the asset panel into the scene, and it is drawn in the editor, in the running game and in the preview alike.

The asset

+ → Tilemap makes one. Its own rows in the inspector are:

Row	What it means
Columns, Rows	How far the grid reaches. Cells outside are not drawn — and not thrown away either, so making the grid smaller and larger again brings the drawing back. On a placed map these grow and shrink at the right and bottom edge while the painted cells stay where they are in the scene (see below).
Tile size	The side of one cell in world units. A tile's pictures are scaled onto it, so one map can mix tiles drawn at different resolutions.

Everything else is the usual: the switch, the position, scale, rotation and mirroring. The map is centred on its position, as every other object is.

Which quarters a cell shows are never stored. For an autotile they follow from the neighbours and are worked out while drawing, so painting one cell fixes the edges of the ones around it by itself; a plain tile looks the same everywhere. Only which tile lies in a cell is kept.

Two different tiles do not join: each one closes against everything else, which is how the RPG-Maker sheets are drawn. Outside the grid counts as empty as well, so a map ends with a proper edge.

Growing and shrinking the grid

A placed map grows and shrinks at any edge (#136). Under its properties the inspector shows GRID EDGES with a row each for Left, Top, Right and Bottom: + adds one column or row at that edge, - removes one. Every click is one undo step.

The painted cells stay where they are in the scene. Cell 0,0 is always the top-left corner, so at the left and top edge the cells of every layer move one column or row in; and because the map is centred on its position, the position moves by half a cell to make up for it. This is worked out in the map's own frame, so a turned, scaled or mirrored map — or one inside a turned parent — holds still just the same.
Editing Columns and Rows of a placed map does the same at the right and bottom edge, already while the value is dragged.
Removing throws nothing away. Cells of a removed column land outside the grid (at negative coordinates for the left and top edge) and come back when the edge grows again.
The size is the placement's own, like any value edited on a placed object; a grid keeps at least 1 and at most 1000 columns and rows.
Placed more than once? The cells belong to the asset, so moving them at the left or top edge moves them in every placement, and only the one being edited has its position corrected. The inspector warns about it under GRID EDGES when the map is placed elsewhere too.
On the asset itself (asset panel) Columns and Rows stay plain values: there is no placement whose content could be held in place.
Reset to asset and Apply to asset on Columns or Rows are the plain override actions and do not move the position.

Painting

Select a placed tilemap in the scene view, and the Tilemap panel opens to the right of the view, between it and the inspector (#142). It holds everything below: PAINTING, TILES and LAYERS. The inspector keeps what belongs to the object — name, asset, position, transform and the Columns, Rows and Tile size rows.

The panel is there only while exactly one placed tilemap is selected, and only on the Scene tab. With nothing, another object or a second object selected, or on any other tab, it is gone and the scene view has its full width. Selecting the tilemap asset in the asset panel does not open it: one always paints a placed map.
It starts as wide as the inspector; the splitter on its left edge makes it wider or narrower. Like the other splitters, the width is not saved.
Opening, closing or widening the panel leaves the map where it is on screen: the scene view keeps its world in place rather than its centre, so the view simply shows more or less on the right.
Deselecting the map puts the brush down: the tool falls back to Select, so no invisible brush is left waiting for the next map. The chosen tile and layer are kept.
Select leaves the scene view as it is: the map is picked up and dragged like any other object. This is what a tilemap starts in — a map one cannot move would be worse than a click.
Brush paints the chosen tile. A drag paints every cell it passes, not only the ones the pointer was reported at.
Erase clears cells the same way.
Rect fills the box a drag spans; while dragging, that box is outlined.
Fill (#133) fills, from the cell clicked, every cell of the active layer that holds the same tile — or is empty, if that one is — and is reached through the four edge neighbours. Diagonals do not count, so a fill does not leak through the gap between two corners. The grid is the border. Filling a cell with the tile it already holds does nothing. A cell naming a tile the project does not have counts as empty (see Tiles).
Pick takes the tile of the cell clicked on the active layer and hands it straight to the painting tool used before Pick (Brush, Rect or Fill; from Select or Erase it is the Brush). An empty cell says so in the console and changes nothing.
Holding Alt is Pick for as long as it is held, from any tool; letting go brings the tool back. Choosing another tool while Alt is down keeps that one.

While any painting tool is chosen, the map shows its cell grid, so one does not paint blind. It paints anywhere on that grid, also where another object is drawn above the map. With Select, a click on an empty cell is empty space, and a sprite drawn above the map's layers there is what the click selects. Shift-drag still pans the view, whatever the tool.

One stroke is one undo step, and so is one fill — a line of twenty cells comes back with one Ctrl+Z, and a stroke painted over another tile puts that one back, not merely emptiness. A stroke, rectangle or fill that changes no cell leaves no undo step at all (#212).

Under TILES stands every tile of the project as a grid of pictures with its name below (#139), so you see what you paint with. A floor or wall tile shows its lone tile — the four convex corners, the one RPG Maker shows as well — and an animated tile its first picture. A tile without a usable picture shows a ? and can still be picked. Picking one reaches for the brush by itself. Without one chosen, or with one deleted since, painting says so instead of quietly doing nothing.

Layers

A tilemap holds one or more layers, listed under LAYERS, the topmost row being the one drawn last (over the others). The list works like every layer list of the editor (the shapes of Vector Art, the layers and frames of Pixel Art):

a click on a row chooses the layer to paint on;
dragging a row moves the layer to another place in the drawing order, one undo step;
the eye switches the layer off and on: a layer switched off keeps its cells and is left out of the drawing, in the editor and in the game alike;
a double-click on a layer's name edits it right in the row (#138). Enter or a click elsewhere keeps it, Esc goes back, and a blank name is not taken;
the number left of the eye is the layer's Z, see below. Click it to type, or drag it sideways to scrub;
the copy mark (two squares) puts a copy of the layer right above it, cells, Z and all, and paints on the copy. It shows, like the ✕, on the row under the pointer and on the chosen one.

The layer's settings (#138):

Z (#174), the number in the row, is that layer's place among the other objects of the scene, added to the map's own Z, just as a child's Z is added to its parent's. Every layer starts at 0, where it is drawn right after the map in list order, exactly as before. Give a layer "Treetops" a Z of 10 on a map at 0, and a figure at 5 walks between the ground and the treetops. Because it is relative, moving the map in Z takes all its layers along, and two placements of the same map each keep their layers the same steps apart from their own Z. A negative Z sorts a layer below the map. Layers of equal Z keep their list order; against other objects of equal Z the hierarchy decides, as always. One undo step per change; the running game draws the same order, and a map whose Z a run changes takes its layers with it.
Sort by Y (#228), the box under the list, sorts the chosen layer row by row with every object on its Z, see Sorting by Y. Off by default, one undo step per change.
Show decides how the scene view draws the other layers of the selected map: All layers as they are, Others faded at 30 %, or Active layer only. It is a way of looking while you paint, not a property of the map: it touches neither the project nor the game, a map that is not selected is always drawn whole, and the layer switches above stay as they are.

The + in the header of the list appends a layer on top. The ✕ at the right end of a row removes that layer, cells and all. A tilemap always keeps at least one layer — there has to be something to paint on, so the last one has no ✕.

Sorting by Y

For top-down maps a layer can be sorted by Y (#228): trees, fences and houses a figure walks both behind and in front of. With the box ticked the layer is no longer one piece in the drawing order but one slot per row, and everything on that layer's Z is sorted by where it stands:

a row of the layer by the bottom edge of its cells,
an object by the bottom edge of its box, which for a figure is its feet. A sprite whose frame has a Sort line (see Textures) stands on that line instead, for a figure drawn with a shadow or empty pixels below its feet.

Whatever stands higher up on screen is drawn first. A figure below a trunk's row is drawn in front of the tree, a figure above it behind. Objects on that Z sort among each other the same way. Ties keep the usual order: the hierarchy, and between layers their list order.

Only the Z of a sorted layer is affected. Objects and layers on every other Z are drawn as before, so switching the box on changes nothing elsewhere in the scene.
On that Z a layer that is not sorted, and the map itself, stay behind everything sorted: neither has one place to stand. Keep the ground on a Z of its own below, or on the same Z unsorted.
A tree whose crown is a row above its trunk would sort by its own row, so a figure right under the crown would stand in front of it. Give the crown tile a Sort offset of 1 (see Tiles): its cells then sort with the row below, the trunk's. A crown two rows tall gets 2 on its upper tile.
Each row is drawn with one mesh per tile, so a sorted layer costs about one draw call per row and tile instead of one per tile.
The scene view, the game view and the running game sort the same way, and a click picks what is drawn in front.

In the running game

A tilemap is scene content, not editor decoration: it is drawn in the game exactly as in the editor, and an animated tile keeps running there at its own rate. Every map showing the same tile is on the same step, so animated water does not run out of phase between two of them.

Drawing is done with one mesh per tile and layer rather than one sprite per cell, so a map of a thousand cells costs as many draw calls as it has tiles on that layer.

From a behavior

A behavior reads and changes the cells of a placed map while the game runs (#135). Four nodes do it, each taking the placed map as its tilemap input:

Tile at gives the tile in a cell (tile, empty for none) and empty. It reads the moment it is asked, so a Set tile earlier in the same flow is already seen. A cell outside the grid, on a layer the map does not have or naming a tile the project does not have reads as empty.
Set tile puts a tile into a cell, or empties it when no tile is given. done says whether it could: not on something that is no tilemap, not on a missing layer, not outside the grid, and not with an asset that is no tile.
World to cell turns a world point into a cell, inside saying whether that cell is on the grid. This is how a figure finds the cell it stands on. The map may be moved, turned, scaled and mirrored.
Cell to world gives the middle of a cell in world units, the way back.

A Tile node hands out one tile as a constant: something for Set tile to put down, or to compare what Tile at read with (Equals).

Cells count in whole columns and rows, 0, 0 being the top-left corner, as in the panel. The layer is picked by name from the layers of all tilemaps in the project, since the node does not know which map it will be given. The index would move whenever the layers are reordered. First layer means the first layer of whatever map arrives; two layers of one name are the upper one.

What a behavior sets belongs to that one placement and to the run:

The run keeps its changes per placed map, laid over the asset's cells. A second placement of the same map is left alone.
The changed cell is drawn at once, the autotile edges of its neighbours follow, and its collision is rebuilt: a Move later in the same frame already meets the new cell, and a falling body lands on it.
Nothing is written back. After Stop the map is the one that was painted. The editor run is no exception: the scene view shows the changed cells while the run lasts and the painted ones again once it ends, and the project never sees them.

Collision

Whether a cell blocks is a property of the tile, not of the map or the layer: switch Solid on in the tile's inspector, and every cell painted with it blocks — water or a wall is what the tile is (#132). A hidden layer still blocks: hiding is how you look at a map, and an invisible blocking layer is a common thing to want.

The blocking cells are merged into rectangles, row by row, so a wall of twenty cells is one shape rather than twenty. In the scene view they are outlined the way a collider is, green and above the drawing; the game view does not show them. The outline runs only along the outer edge of all that blocks (#173): where two rectangles or the pieces of outlined cells meet, no stroke is drawn, so a wall of several rectangles or a lake of many pieces shows as one shape. Collision itself keeps the pieces. The area is tinted only while the map is selected, and then only where the active layer blocks: the outline shows the whole map, the tint what the layer you paint on adds to it.

A solid tile's Friction and Bounciness (#193) are what a cell of it offers, read by Move and by the physics engine like a collider's (see Physics). Cells of tiles with a different surface are never merged into one rectangle, the same way one-way tiles are kept apart from walls. A tile with a smaller collision scale therefore does not stay flush with a neighbour of another surface: towards it, it is drawn in like towards an open side.

A placed tilemap carries Layer and Collides with like a collider does, for the whole map (see Colliders): ground only some things walk on is a map on its own layer. Per layer of the map or per tile it is not — a cell belongs to the map.

Collision scale

A tile's Collision scale (1 by default, 0.1 to 2) makes its cells block less or more than their square (#140) — below 1 for a bush or a thin pillar the hero may come closer to, above 1 to keep it further off. The box is drawn in or out only on the sides without a blocking neighbour; towards a blocking cell the side stays flush, whatever value that cell has. So a wall of bushes at 0.5 is one narrower wall, not a string of beads with gaps to slip through.

The inner corner of an L closes cleanly: the drawn-in upright runs down into the drawn-in foot, which can take one rectangle more than at 1.
Cells that meet only at a corner are not joined — that corner stays drawn in.
Where two layers hold a solid tile on the same cell, the larger scale counts.

The outline in the scene view shows the drawn-in or grown shapes.

Outlined tiles

A tile whose first picture is a frame with collision outlines (drawn in the Texture tab, see Textures) blocks with those outlines instead of its whole square (#141): a slope, a rock, a tree trunk, the shore of a lake. Such cells are not merged with the rectangles — they bring their own polygons — but the scene view draws them together with the rectangles, along the outer edge only.

A plain tile (kind None) lays all its outlines over the cell: scaled from the frame onto the cell, and drawn in or out about the cell's centre by the tile's collision scale.

A floor or wall autotile is drawn from four quarters of its block per cell, picked by the neighbours — so its outlines are drawn over the whole block and cut along the same quarters, and every cell takes the pieces of exactly the quarters its picture is made of. An outline that follows the drawing continues across cells the way the drawing does: outline the bordered 2x2 tile of a floor a little inside its shore, and every lake painted with it blocks a little inside its shore, at straight edges and outer corners alike.

A tile of the block with nothing drawn in it blocks whole in all its quarters. Most often that is a floor's notch tile (top right): left undrawn, the inner corners of a lake stay closed. Once anything is drawn in a tile of the block, only what is drawn blocks there, and a quarter can be left open on purpose.
Drawing past a tile's edge is harmless: what reaches into another quarter is cut off there.
A cell drawn only from quarters that block whole — the inside of a lake — is a plain square and is merged with its neighbours like any other.
The collision scale does not apply to an autotile with outlines: the outline is the shape. An autotile without one blocks as its square, with its collision scale, as before.

For both:

Only the first picture of an animated tile counts: a blocking shape that twitched with the animation is rarely wanted.
A solid tile blocking as a square on another layer of the same cell covers the whole cell, so there the outlines are left out.
An outline that crosses itself collides as none; a tile none of whose outlines is a polygon blocks as its square.

In the running game the placed map is a body of its own in the collision system:

Move with Collide with solids stops at it and slides along it, like at a solid collider. The rectangles turn, grow and move with the placed map.
On collision enter / stay / exit fire with the tilemap as other, and Is touching with the map as one side works as well.
Two tilemaps never collide with each other — they are ground, not things that walk into each other.
Cells painted while the game runs count from the next frame on.

A tile that should report instead of block is a trigger tile, see Trigger tiles.

The cost of outlined cells

Merged rectangles are few, outlined cells are many: every painted cell of an outlined tile is a polygon of its own, and every one of those is cut into convex pieces that are tested against each other piece by piece. A map of 20x20 outlined cells is 400 solids under one entity, where the same map of plain solid tiles is a handful of rectangles.

That is why a move, a ray and the editor run's detection each ask the map only for the cells of the rectangle they can reach (#184): the rectangle is taken back into the map's own units — a turned map through its own axes — and turned into cell coordinates, so cells outside it are never worked out in world units at all. Measured on a map of 20x20 outlined cells of 16 corners each, one Move cost 148 ms before and 0.26 ms after; with 8 corners, 34 ms and 0.27 ms. Nothing about the result changes — what is left out could not have been met.

What the cells work out to is remembered while they stay the same (core/model/tilemapMemo.ts). The scene view, the game view, the collision system and the physics all ask for a map's tiles and solids every frame, and an animated tile makes the views draw every frame. Before, each of them cut every outline into its quarters and pieced every cell together again, so a map that only stood there cost a frame. Now:

The tiles of a layer, the blocking cells, their rectangles and polygons are kept per content. A stroke paints the cells in place, so the object being the same says nothing. Whoever writes into cells says so with cellsChanged(cells): the brush while a stroke is under way, and PaintTilesCommand on execute and undo. Only then is the content compared cell by cell, and only a real difference makes a new version. A painted cell, a tile switched off Solid, a new outline or a new tile kind is seen at once. Code that replaces the cells object needs no word.
A tile's cut outline is kept per outline list. The model replaces the list instead of editing it, so the list stands for its corners.
The same cells hand out the very same rectangles and polygons. The physics tells by that, and by the map's place and settings, that it need not work the map's pieces out again every tick.

Measured on a map of 39x18, 8x8 and 43x20 cells on three layers, with an animated water tile and an outlined hill tile (5 outlines), script time per frame on the main thread went from 17.7 to 5.8 ms with nothing selected, from 26.2 to 8.6 ms with the map selected and from 29.9 to 8.7 ms in Play. That is 52, 38 and 33 fps before and 60 fps in all three after.

A second round (#284) took out what a map that only stands there still cost in Play:

The cells were compared on every question, some sixty times a frame for one map. That was the largest single cost of the run. Now a painter's word decides, see above.
A view with an animated tile on it was drawn twice a frame: once by the run and once more by animate. animate(drawnBefore) now leaves a view alone that was drawn since the tick began.
Every mesh of the map got a new geometry with each drawing. TilemapField keeps what a mesh was built from and builds again only when the cells, the tile size, the origin or the picture differ. groupByTile and layerRows hand out the very same lists for the same cells, which is how a mesh tells. An animated tile rebuilds its own mesh when it steps on, the others stay.
The physics went through every collider of a map each tick to switch it on or off. A map whose shapes and switch did not change is skipped.

Measured in Play on the 30x18 map of the reference project with 222 entities, per frame on the main thread of a slow machine: Physics 2.64 to 0.97 ms, Drawing 6.89 to 2.56 ms. The same scene without the map and its crates takes 0.30 and 1.63 ms.

A third round (#347) took out what painting cost on top of that:

Each frame of a stroke previews the model, and the asset and hierarchy panels built every row anew on it. Every label became a new text, and every text a new upload to the GPU. ListView now keeps a row whose item draws the same (sameListItem) and builds only the ones that changed. An open graph tab did the same with the captions of its groups and comments, because each redraw gave them a new style. A caption now keeps its style while colour and width stay.
The brush drew the whole scene on every pointer event, on top of the preview and of animate. Now the preview draws what a stroke changed, once a frame. The rectangle tool asks for one drawing a frame for its box. animate asks just before the frame is drawn instead of in the tick, so a frame with a preview in it is drawn once.
Where the scene view's symbols stand (layoutSymbols) is kept while no anchor moves.
A layer's cells are read once per content into an index by place (layerCells), and the tiles and the blocking cells find their neighbours there instead of building a key string for each.

Measured with a brush stroke on a copy of a project with a 60x60 map on three layers and fifty objects (Chrome, slow machine): 20 to 39 fps before, 47.5 after, against 55 to 57 fps without painting. The stroke drew 2012 labels again before and none after, and the scene 1.32 times a frame before and once after. One painted cell cost the scene view 28 ms headless before and 16 ms after, on the same map doubled to 120x120 109 ms before and 49 ms after.

A fourth round (#348) made a painted cell cost what is around it, not the whole map:

cellsChanged takes the keys a writer changed (the brush, the paint command and its undo), and each new version of the cells keeps them (cellsChangedSince, the last 16 versions). A writer that names none costs one walk over the cells, and a replaced object starts afresh.
The cell index, the tiles of a layer and the blocking cells patch only the changed cells and their eight neighbours: nothing else can join or block otherwise. Both lists are in cell order now, so a patch is one walk that keeps every other entry, the same object as before.
The rectangles are merged row by row. A strip never spans two rows, so a patch joins again only the rows around it and stacks the rest as they were. That is one row further than the patched cells, since an autotile turning into a box cuts the box below it otherwise.
The tiles a map names come sorted by id, so the same content gives the same order whichever way it was painted. That is also the order of two trigger tiles on one cell.

Measured with the same map: one painted cell costs the scene's item list 3.5 ms on 60x60 and 4.0 ms on 120x120, against 3.4 ms without painting (headless, before 16.8 and 54.6 ms). A brush stroke on the map doubled to 120x120 runs at 42 fps instead of 28, p95 of a frame 52 instead of 92 ms.

A fifth round (#424) took out the meshes: a painted cell built the geometry of every tile on that layer again, since the layer's tiles came as a new list and were grouped by tile afresh.

A patched list of tiles says what it came from and which entries went and came (tilesPatch). A cell around the painted ones that is drawn the same keeps its entry, and a patch that changes nothing drawn hands back the very same list.
groupByTile and layerRows patch the groups of the list before (patchedGroups). A group no changed entry falls into is the very same array, so its mesh is not built again. On a layer sorted by Y that goes for each row and for the groups in it.
A tile new to the layer still works the whole layer out again, as before.

Measured with the same stroke: meshes built per frame 21.9 to 0.94 on 60x60 and 40.7 to 1.22 on 120x120, 49 to 51 fps and 42 to 46 fps. Painting now costs both sizes the same, about 10 fps below the same view without painting. What is left between the two sizes is drawing the larger map, which the view without painting shows as well.

A frame still costs what it touches: an object standing inside many outlined cells is tested against each of them, so an outline of a hundred corners around every cell of a lake is dearer than a few around its shore. Draw as few corners as the shape needs.

Trigger tiles

A tile with Trigger (reports, never blocks) on (#160) is water, lava, spikes or a goal: its cells stop nothing — not a Move, not a falling body, not a ray — and tell the collision events what lies on them. Trigger wins over Solid, as it does on a collider. In the scene view the cells are outlined in the trigger collider's yellow, merged into rectangles like the solid ones but never with them.

On collision enter, On collision stay and On collision exit fire for a collider that lies on such a cell, with the tilemap as other, and three outputs say where:

Output	What it holds
`tile`	the tile asset, to compare with a `Tile` literal: water or lava
`cell x`, `cell y`	the cell in the map, as `Tile at` and `Set tile` count it

For another collider, and for the solid cells of a map, tile is empty and the cell is -1, -1.

How often the events come is up to the node's input per cell:

Off (the default): once per area. An area is the stretch of cells of the same tile that touch side to side. Walking through a pond is one enter and one exit, however many cells it crosses. The cell told is the one of the area nearest to the collider's middle; on exit, the last one. Water next to lava is two areas, and so are two ponds that only meet at a corner.
On: once per cell. Every cell the collider comes to lie on enters, stays and exits on its own. A stay with an interval keeps a clock per cell.

The input is a port like any other: unconnected it is a checkbox on the node, connected it is read each time an event comes.

What else holds:

The tile's Collision scale and the outlines of its picture shape a trigger cell exactly as they shape a solid one. One-way, Friction and Bounciness mean nothing on a trigger.
The map's Layer and Collides with decide which colliders are told at all, and a collider that is itself a trigger is told as well.
A cell holding two trigger tiles on two layers reports both.
Is touching with the map as one side is true on a trigger tile too.
Set tile changes them while the game runs: a trigger tile put under a collider enters in the next frame.
The editor run and the played game tell the same. Both test the overlap where the objects are drawn (src/runtime/systems/tileTriggers.ts); the physics engine never sees a trigger tile.
A ray does not meet a trigger tile, with Hit triggers on either.

One-way tiles

A solid tile with One-way (from above) on (#155) blocks only what comes down on it from above, like a one-way collider blocking from Above (see Colliders): a figure jumps through from below and from the side, lands on top, and falls through with Ignore one-way. Above means the map's top, turned with it. The tile's One-way angle (45 degrees by default, #159) is how far a contact may lean from straight up and still land, as on a collider. One-way cells are merged into rectangles the same way, but only with each other and only with tiles of the same angle — a platform next to a wall is two shapes, so the wall never blocks from below only. In the scene view they are outlined thinner, their top drawn thick with the fan of their angle on its middle.

In the project file

While you edit, a layer holds its cells as a map from "x,y" to a tile. The project file stores them more compactly (#134): per layer the tiles it uses once, the top-left painted cell, and then one line per row as runs of index*count. index counts from 1 into the tile list, 0 is an empty cell, and a single cell drops the count:

"tiles": ["grass", "path"],
"origin": { "x": 0, "y": 0 },
"rows": ["1*40 0*3 2", "1*44"]

Cells outside the grid are stored as well, so a map that was made smaller gets them back when it grows again. Measured: a full map of 100x100 cells on two layers went from 736 KB to 11 KB. The map of the first version (#128) is not read any more (#137): such a layer loads empty.

What it does not do yet

A trigger tile tells no contact: normal, impulse and point are 0 on its events, as for a trigger collider.
The solid cells of a map do not say which tile was hit: tile and the cell are only told for trigger tiles.

Using the editor

Working on the code