I noticed that the screenshot captures done with F1 from the editor contain a black color #020408, while a system screenshot will show that PICO-8 uses #000000 while running.

This caused some issues as I was editing screen captures, Aseprite noticed that the color didn't match the black color from the PICO-8 palette, and operations like color replacement failed.

This may have been the case from the start, and I have no idea how many times I used screenshots in my editing process, possibly mixing "good" and "bad" black together. As they are not distinguishable with bare eyes this may be a problem for later (e.g. I try to fill an area with color bucket but it only colors a small area).

I could only find one occurrence of this color, on the PICO-8 Wikipedia talk: https://en.wikipedia.org/wiki/Talk:Pico-8

Apparently the old page was mentioning #020408 for black. Either it was the old color, or the author checked the colors from an F1 screenshot (and I would have done the same!).

I don't know if other colors are different during screenshot.
I don't know if it's intentional for web export, human eye convenience or anything, or if it's just an old value that was not updated.

I was wondering what this almost-black color was! This #020408 bug also appears when you do export spritesheet.png from the console, but a direct printscreen shows that the displayed color in Pico8 is solid black.

I was running into some weird bugs in my art program because of this, so I'm really glad you posted this bug. And FYI, most pixel art programs let you select all pixels of a certain color in the canvas, so that's what I did to fix the fill bucket tool.

+1

Fixed in 0.2.2b

From changelog:

> Fixed: black pixels in gif / map export not completely black