Made Change Color: Increment/Decrement Foreground/Background methods cyclic instead of clamped. At last palette element, incrementing selected color returns to first element. At first palette element, decrementing color returns to last element.
Before this fix, it was possible to lose the transparent index at Indexed Color Mode.
It was reproducible doing:
- New file, Indexed mode, Black background.
- Erase all the palette, add 40 colors slots (these all will be black)
- Press Remap button
- Go to Sprite > Properties... set transparent color to 11.
- Erase color entries 2 to 20
- Press Remap button
You'll see the transparent index is gone (transparent index = -1)
To reproduce the crash, additional steps are needed:
- Right click to layer and select 'Layer from Background'
- Make a color RGBA(0, 0, 0, 0) and add to the palette
- Paint on canvas with this color (it'll act like a eraser)
- File > Save As... save in GIF format.
- Press OK
Crash!
This crash was reported on ticket 2620 and 2621.
Removes switch case with fall through. Removes nested switch
cases. Refactors color sorting method to 1. push zero alpha colors to
the front of the palette; 2. resort to value as a criterion for gray
colors; 3. use saturation and value as back up comparisons for each
other for equivalent values; 4. approximate gamma-to-linear when
perceptual lightness is chosen.
Partial fix for #2901.
Maybe it's not the final version, but it's a good start. We cannot
match the coding style that we were using, but it's pretty close.
We'll start applying clang-format incrementally in a near future.
Without this fix windows were missing a last re-layout/setBounds to
the new frame size, so they showed up with an incorrect size given the
available area of the native window.
ase_file_write_start_chunk needs to skip forward the size of the chunk header, as these values will be written in later. Using fseek was causing performance issues on my Windows machine due to causing an io flush on every chunk, for projects with many (thousands) of chunks. Replacing with the equivalent put commands in ase_file_write_close_chunk results in ~100x speedup.
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).
This should improve the mouse movement, where a new mouse cursor was
created on each mouse movement with black & white pixels. It's a
regression introduced in ef4f691459
(which was originally introduced to improve the mouse movement
perception in a 100Hz monitor).
This might be a possible fix for:
https://github.com/aseprite/aseprite/issues/2713
