First commit :
Removed Local storage feature
Added 'download project' 'open project' options
First attempt at simplifying right panel.
To be continued ...
New option in application settings : onion skin.
You can choose the overlay to display now :
- no overlay
- onion skin (default)
- layer preview (previous default)
Available in Application Settings panel.
Only one overlay can be used at the same time.
The onion skin overlay is driven by a new OnionSkinRenderer maanged by the
drawing.
The drawing controller is responsible for instanciating and 'choosing' the
overlay renderer.
When switching to a new overlay, other overlays are cleared and flushed
(they cache their rendering frame, flush empties the cache).
NB : flush is only available on LayersRenderer and OnionSkinRenderer for
now.
In the GIF export panel, user can now choose between :
- export online (previous 'upload' feature)
- download GIF
Labels have been updated in the PNG export panel to follow the same
convention.
CanvasToBlob library was modified and moved to dedicated utils to handle
not only canvas, but also any base64 dateURI.
When holding shift and using the move tool,pixels normally exiting the
frame will now be redrawn on the other end of the frame.
Makes it easy to perform sliding animations.
Added new tool to lighten/darken. By default is in lightening mode. If the
user holds ctrl/cmd while using the tool, switches to darkening mode.
If the user holds shift while using the tool, then each pixel can only be
modified once per tool usage (ie user keeps hovering the same pixel, it
won't get lighter/darker after the first time). Can be useful if you want
to keep control of the amount of colors in the sprite.
TODO :
- Ability to select explicitly lighten/darken (context menu for
tools).
- Ability to set the 'step' (ie the strength of the lighten/darken)
If there are less than 256 colors in the piskel, do not perform anycolor
quantization, just reuse the colors from the piskel.
Added preserveColorsParameter to gif.js library.
If nb colors>256, fallback to the previous behavior. This could be
improved by checking the number of colors for each frame. The palette is
defined independantly for each frame, so as long as a frame is <256
colors, we could reuse the original colors.
I also believe that images with more colors would get a better quality if
we could use a single color sample for all frames. This would avoid color
'gaps' as we can experience today. In any case, for piskel, < 256 is a
reasonable assumption
