Thraka/SadConsole

Black pixels in animations are displayed as transparent pixels

Gr-a-f opened this issue · 2 comments

Gr-a-f commented

Hi, I'm not sure if it's an issue or if I'm just doing something wrong.

The thing is that for some reason black pixels are displayed as transparent when playing animations. At first I thought the problem was in my animation, but then I found the same thing in the example. Judging by the fact that the animations play normally on the https://code2d.wordpress.com/2023/06/17/animations/ site, I think it might be a problem with the new version of SadConsole.

For the animation I used the default demo display font (thick_square_8x8) and black and white animation. I tried changing the font background from black to transparent, but it seems to break the animation even more.

The link to the project is https://github.com/Gr-a-f/SadDamo6. To the template I just added my animation in DemoAnimations, and changed the thick_square_8x8 font background to transparent.

I don't know if it's related, but non-black and white animations look darker in the app than the original file

image

Thraka commented

I was finally able to figure out why these little holes get punched through. It has to do with the code that creates the shaded blocks. If it runs into a really dark color while determining the brightness (to choose a shaded block character) it does nothing and moves on. The default background of the cells is transparent, so nothing happens to that cell, leaving it transparent.

Still investigating what to do about this though...

Thraka commented

OK, I think I came up with some tweaks that sorts of fixes this problem.

  1. We discovered earlier that the font being used has a hard-coded black color for the transparent spot. Once we fixed that, we then started seeing these black spots turn to transparent, still didn't solve the problem.

  2. The other problem is that the demo code was created to sort of circumvent these issues. So while those animations looked good, anyone who created a different animation/image, such as the skull in the previous post, you could instantly see the problem.

  3. The translation code that converts a color to a shaded block isn't designed to place pixels against a light background, it was meant for black. As such, there's logic in there that just skips over really dark pixels, because it wants to leave them dark and untouched.

    Things look good when drawing the converted image with a black background surface. However, the demo is using a transparent background for the animation and a white background for the container. This makes white pop out of those unhandled-defaulted transparent spots. Further, since the shaded blocks are shading a foreground color with the default background of the surface (transparent in this case) this shades everything very brightly (bleeding through to the white background). The animations don't look correct.

    To fix this, I've added a parameter to the image conversion routine that lets you specify a background color, so you can default to something other than transparent.

So to sum up, with these tweaks:

  1. Fix the font
  2. Remove the patch code that worked around the original problem in the demo
  3. Add the ability to set the animated-image-converter's default background
  4. Shade the default background to Black

The animation demo is fixed up. The screenshot shows the previous version (after font fix and circumvention code removed to expose the real problem) followed by the fixed version:

image