Prior to this fix, animations were incorrectly converted to GIF when
the animation contained semi-transparent colors or backgrounds
(specifically, colors with alpha <= 128). Essentially, semi-transparent
pixels didn't repaint the pixel of the processed frame, meaning they
retained the color from the previous frame.
Now callers can force loading a file without creating any background
layer in the doc. This is because for drag and drop operations we don't
want to generate background layers
This was originated for #1279 (CLI-only Aseprite) which can be
achieved with LAF_BACKEND=none anyway.
In this way we simplify the development process, and checking for the
availability of the GUI can be done in run-time through App::isGui()
or Context::isUIAvailable().
If the RGB color at index 'i' of the local gif palette and the sprite palette match, there is no need to call findMatchColor(). This prevents indexes from being reassigned undesirably.
Also, in the special case that a global palette exists and as long as no local palette appears during frame iteration, it is not necessary to call findMatchColor() since the global palette is equal to the sprite's palette (in colors and order).
Implemented using a new FileAbstractImage interface to get scanlines
for each frame automatically resized (without modifying the original
sprite/without using SpriteSize command/adding new undo information).
Related to #3008
Before this fix, when some aseprite file with transparents pixels was
converted to GIF, each frame didn't overwrite correctly the previous
frame (image disposal was incorretly chosen: DO_NOT_DISPOSE instead of
RESTORE_BGCOLOR).
Before this fix, during gif encoding we get a crash when the previous and current frames matchs exactly and no pixel clearing are detected from a frame to the next.
We arrive to this situation during the gif encode main iteration which calculates deltaImage and its frameBounds.
Before this fix, some colors were missing in the palette when gif animation were open.
The conditions to reproduce the error are:
- Final open sprite is not opaque,
- Gif source without a global colorMap and
- Gif source with different local transparent indices for each frame
Before this fix, multi layer blended indexed images (into the gif options dialog), could be checked in the preserve palette orders check box, but actually it is not possible.
In addition, we bypass large code blocks when we have to preserve palette order.
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)
* Added the gfx::ColorSpace field in doc::ImageSpec
* Removed some methods like Sprites::add(width, height, etc.)
* Prefer methods with ImageSpec as argument (which now includes the color space)
New cmake flag -DENABLE_UI=OFF can be used to turn off the GUI
and compile a CLI-only version of Aseprite.
Requested here too:
https://community.aseprite.org/t/1351
Gaspar Capello
David Capello
Martín Capello
David Capello
Gaspar Capello
David Capello