Tilemap editor feature

[dacap]

UI design and main goals of the tilemap feature:

• Everything related to tilemaps must be hidden until we create a new tilemap layer using a new Layer > New Tilemap Layer menu option (in this way we avoid bloating the UI with tilemap stuff)
• As tilemaps will be a kind of layer, we'll be able to have several tilemaps in one sprite
• One tilemap layer will have its own tileset, a tileset will have its own tile specs (grid size, etc.), but the tileset could be linked from an external file (with possibilities to embed the external tileset content inside the tilemap optionally)
• Each cel in a tilemap layer will be a new kind of image where each pixels reference a tile:
  • Each pixel in the tilemap image will be a 32-bit value with some bits to reference the tile in the tileset and other bits to specify flip and rotation
• When we create a new tilemap layer, it should behave almost exactly like a regular layer, and tiles should be handled transparently/automatically by default (so even if an user creates a new tilemap layer by mistake, she/he shouldn't see a different behavior from a default layer)
• When the active layer is a tilemap layer, a new set of buttons should be displayed in the color bar, those buttons should allow:
  • Changing between the palette view <-> tiles view (keyboard shortcut: Shift+Tab)
  • Changing between the automatic mode of handling tiles
  • Do some special operations to tiles, which should match future operations with the palette too. E.g.
    • clean unused tiles = clean unused colors,
    • group tile = group colors,
    • remap of tiles = remap of colors
• When a sprite contains tilemap layers, the sprite properties dialog should show a section of "tilesets" #3875
  • We should be able to reorder tilesets
  • We should be able to add new tilesets
• Possibility to link external tilesets
  • Persistence (.aseprite information)
  • Auto-sync tileset from external file when the original is modified
  • UI to select external tilesets
  • Special import/external/linked tileset options, e.g. from grids, from frames, from layers, from "Import Sprite Sheet", etc.
• Drawing tile pixels with three modes: Manual (modify the tiles, don't create new tiles), Auto (create/remove existent tiles automatically), Stack (add new tiles when they are modified, keep the existent tiles unmodified)
• Drawing tools with tiles
  • Paint with tiles (still buggy)
  • Eyedropper for tiles
  • Selecting tools with tiles
  • Fill, Stroke, and Clear commands for tiles
  • Copy and paste tiles

Special Features

Possible advanced features:

• Flip/Rotation per tile in tilemap layer Implement xflip/yflip/rotation flags in tilemap layers #3603
• Overlapped tiles (isometric tiles etc., hexagonal tiles, etc.)
• Palette shifting (e.g. some bits to shift the colors of a tile in the color palette)
• Metatiles (hierarchy of tiles, where the tiles of one tileset is another tilemap with smaller tiles)

Persistence

• Create a new chunk in .aseprite format to save tilesets
• Each tileset should contain specs (tile width/height, type of tiles, etc.) and source of tiles (e.g. for linked tilesets between files).
• Save/load layer tilemaps and their cels
• Save only differences between cels in tilemap layers
• Save (and load?) TMX files
• Convert grid settings into tileset specs and save then in the .aseprite file if it's possible (Save grid parameters to .ase files #688), this might enable isometric grids too (Isometric object creation tools #720)

Integration

• Check the integration with Tiled mode

---

Ideas, issues to review, and old ideas about the implementation

Review

• Projects management feature Projects management #126, question, should tilemaps be related to a project? It looks like nothing should be related to a specific project and maybe the projects feature should handle folders only.
• All tilemap related issues tilemap
• This Steam thread: http://steamcommunity.com/app/431730/discussions/1/405692224243720164/

UI Design

Here I'll be updating this issue to talk about the design of this feature. Some questions to solve:

• How we create a new tilemap? (File > New > Advanced > a new tab for tilemaps appears? or we start creating the sprite sheet?)
• Should be the tilemap a switcheable mode like "Tiled Mode"? I don't think so, we could be creating several tilemaps from the same tileset/sprite sheet. So it looks like a tilemap is just a way to say "we are going to create a map feeding tiles from these sprite sheets"

The general idea is this:

• the color bar should be transformed into a tileset where we can pick tiles
• the sprite editor is the tilemap editor where we can put/draw/pick(eyedropper) tiles

Internal tasks

Tasks to do (this list is not complete):

• create a new kind of image that can reference different tiles/doc::Image on each area and with different rotation/flipping. (doc::TiledImage?)
• create a generic iterator for any kind of image (current doc::Image, and this new tiled image)
• different parts of code will use the doc::Image iterators (e.g. file format encoders/decoders) and other areas should use this generic iterator (e.g. sprite Editor widget).
• get tileset from a tilemap (from this thread)

An alternative implementation would be to edit images as a regular image, and after each "tool loop", we update/sync the tilemap/tileset depending on these modifications. Pros: easier to implement (there is no new kind of image), Cons: it will use a lot more memory (and it couldn't be an option for big maps).

[not-surt]

All other image editors with tilemap editing that I know of are limited to non-overlaping rectangular tiles.
This is obviously useless for isometric, other axonometric tiles.
Ideally any solution would allow tiles to overlap on the tilemap canvas and be editable in place.
This should require an full tilemap implementation rather than just a hack on top of a regular image.

[EyeGem]

2not-surt: Full tilesets and tilemaps creation support is far out of animated layered image editing scope. Don't think Aseprite should be jack-of-all-trades here, because wishes will just grow and grow. There are lot of other things possibly required from such support: clipmasks/z-masks, 2D/3D tilemaps, animated voxel/point-cloud sources for isometric tiles/sprites, objects/locations placement with parameters and objects presets archetypes hierarchy, animated scenes timelines for sprites/objects/hints, different lighting/shadows support, advanced grids (hex-grids, walls-and-columns-around-cell grids, etc.). Just too many of them. But simple and clean Super Tiling support will be just OK. Better create another editor or mode for ATnT (Advanced Tiles & Tilemaps) =)

[EyeGem]

2not-surt: And you can create isometric tiles (not tilemaps) in Aseprite using hint guides layer. Frames will be different sprites (or sometimes "frames"). Layers will help create complex tiles with layered layouts. And then use this tileset in tilemap/level editors, not image editor. Simple tiles is special case specifically because they do not overlap.

[KasumiArai]

Block tile copy is an absolute must. (That is selecting multiple and pasting multiple tile indices. Pyxel Edit still lacks this, and it's my main problem with its workflow.)

It would be cool if this paired well with issue #974, or at least had a feature found in D-pixel. It allows you to work with tiles in a palettized way. Say you have a range size of say... 4 and draw a tile using indices 4, 5, 6 and 7. You place a duplicate of this tile to the right. You then draw on the left one using color 8. It remaps index 4 to 8, 5 to 9, 6 to 10 and 7 to 11, but only for the left tile. Meanwhile the stroke you made is still made on the identical right tile using color 4. So there's one tile in the tileset, but it can be displayed with two different palettes. Useful for retro stuff. A range equal to the current palette size would end up being "normal" painting behavior.

You can see a gif here, it's probably better than the text explanation:

What D-Pixel lacks that Pyxel Edit has is seeing the stroke you're making across all tiles the stroke has touched. D-Pixel lets you see the stroke, but if you make say... one continuous stroke across two of the same tile, both tiles will look different until you release click and it applies both sets of pixels that overlapped each tile in the map to the actual tile. You can see this above when a line is drawn on the white background. Ideally all of those white tiles would update during the stroke itself so it's never possible for two of the same tile to look different.

This is also a must. The palette stuff would be cool, but is not a must to me.

[EyeGem]

About blocks for Super Tiling I proposed at http://steamcommunity.com/app/431730/discussions/1/405692224243720164/

Copying blocks of tiles could be done by selecting tiles in Tileset window with Ctrl+click (they should be organized there for this, like 2x3 tiles for tree and etc.) or with Tiiling Pen on image layer with Ctrl+Alt+clicks, and then Ctrl+C to copy all selected tiles as image. Yes just an image. Then Ctrl+V to insert it. If current tool is Tiling Pen then Ctrl+V should insert it aligned to grid automatically and then movable with auto-aligning.

Also Ctrl+drag (Tileset window) and Ctrl+Alt+drag (image layer) could select/deselect tiles in rectangular block,yes.

[EyeGem]

2dacap: about "create a new kind of image that can reference different tiles/doc::Image on each area and with different rotation/flipping. (doc::TiledImage?)"

Just to clarify: for Super Tiling you don't need special kind of image. Only special kind of operations. It's perfectly possible to allow select existing files in Tileset window (and layer inside file for .ase files). And make combo list of such files with (+) and (X) buttons somewhere to add new and remove unwanted. And auto-select file and layer from this combo list then switching between layers of main image (restoring lastly selected file/layer for this layer).

[EyeGem]

For any tile WxH it's possible to calculate hash value using, for example, this function:

ub4 one_at_a_time(char *key, ub4 len)
{
ub4 hash, i;
for (hash=0, i=0; i < len; ++i)
{
hash += key[i];
hash += (hash << 10);
hash ^= (hash >> 6);
}
hash += (hash << 3);
hash ^= (hash >> 11);
hash += (hash << 15);
return (hash & mask);
}

From: http://www.burtleburtle.net/bob/hash/doobs.html

It's also possible to calculate hash values for flipped/rotated versions of same tile, because hash function is order-dependent.

These hash values could be used to create hashtable lookup of N lists, N = 2*max_tiles. Simply put tile index (and flip/rotate flags) into list with index = hash_value % N. Then when you need to find matching tile simply calculate hash value for your tile and lookup into same list and compare tile pixels only against those tiles in list (with flipped/rotated flags affecting comparison), not against all tiles of tileset.

max_tiles could be estimated as = ( tileset_width / tile_width + 1 ) * ( tileset_height / tile_height + 1 )

[EyeGem]

One worst case scenario estimation:

1. image 8192x8192 designed with tiles grid 16x16, thus 512x512 tiles, 256K tiles total
2. tileset 128x1024 with same tile size 16x16, i.e. 8x64 tiles = 512 tiles
3. all image tiles same (for example, black), thus same hash value
4. all tileset tiles same (for example, black), thus same hash value
5. hash function for 16x16 = 256 bytes ~ max. 3000 processor ticks (for Indexed mode)
6. let us have CPU 1Ghz
7. 512 * 3000 * 8 ~ 12M ticks to calculate hash values for tileset (4 rotates with flips) ~ around 10ms
8. 256K * 3000 = 768M ticks to calculate hash values for whole image ~ less than 1 sec
9. 512 tiles in list for same hash value, compare every tile 512 times, 256K * 512 * ~1000(memcmp) = ~128G ticks ~ 100 sec ... hmm, slow =)
10. to optimize don't add to hashtable same tiles, extra 511 comparisons, 511 * ~1000 ~ 512K ~ 0.5ms
11. thus only 1 tile in list, thus 256K * ~1000 = 256M ~ 200ms

And this 1.5 sec operation is rare operation only for special second click in Tileset window to select all tile instances in main image (including flipped/rotated) and edit them all. All other operations do not operate over full image. And this was really bad case scenario where hashtable failed because of all tiles were the same.

[AkashaRepo]

Right now I have a workflow where I make tiles in Aesprite and arrange them in Tiled. Being able to do all this in Aesprite would be <3

[astraldata]

+9000 to KasumiArai -- that sort of tilemap feature would be amazing in Asesprite! D: