This is the first commit with a simple tilemap editor. Still buggy but
functional in several ways. Several changes were made:
* NewLayer command can receive a tilemap=true to create a new tilemap
layer
* New ToggleTilesMode command added to switch between the palette and
the tileset in the ColorBar (the ColorBar was expanded to show
colors or tilesets with a generic AbstractPaletteViewAdapter)
* All commands to create new layers were moved to Layer >
New... submenu
* There are a new tileset chunk to save tilesets in .aseprite files,
and a new kind of cels to save tilemaps
* Added doc::LayerTilemap, doc::Tileset, etc. and several other types
to handle tilesets/tilemaps in the doc layer.
* Added doc::Grid class with grid specifications that indicates how a
tilemap <-> tileset must be drawn
* Added and expanded cel operations to work with tilemaps and
conversions between regular LayerImage cels <-> LayerTilemap cels
(e.g. copy cels in the timeline between layer types)
Here we avoid two ExpandCelCanvas at the same time with
MovingPixelsState + DrawingState. Double-clicking inside the selection
when we are moving it (MovingPixelsState) could start a new
DrawingState which creates a new ToolLoopImpl that needs a new
ExpandCelCanvas. So we have to drop the pixels before.
If we use two sprites with different canvas sizes, and both sprites
have a similar cel, they can share the inTextureBounds, but not the
original size (which is the original sprite canvas size of each cel).
This can be reproduced using the CLI and creating a texture
atlas (-sheet) with two or more sprites.
This can happen when we use -trim (Trim Cels) + -merge-duplicates
options together. The trimmed bounds are unique to each sample, and
only the position in the texture (inTextureBounds) can be shared.
Fixes: https://igarastudio.zendesk.com/agent/tickets/407
When the backup thread is running, the upgradeToWrite() needed some
extra time to lock the document to check if we can write or not in the
sprite. Now we just check the ability to write the sprite with the new
RWLock::canWriteLockFromRead() function.
