Strange Background Coloring

[Shahelion]

Most of the older textures have a strange thing happen when imported into another program, where they suddenly have a background of mixed black and white, sometimes with extra color pixels as well. Perhaps the transparency isn't 100%, or maybe it's something else. I have uploaded an example. The second image is the one in your pack.

[malcolmriley]

Hello,

Thank you for the report. I'll look into this, but in the meantime: would you be willing to share what program you are using where this occurs? You mentioned that "most of" the older textures have this issue, could you identify an example of one that does not, even a newer texture?

[malcolmriley]

Interesting! I think I've identified the issue, then. One last test, if it's not too much trouble - just to ensure it isn't a "false positive" and to confirm my fix:

If these are working, I will roll out an automated fix to the rest of the sprites in the repo. I've already confirmed they work in Minecraft, which I assume is the main use case for this repository...

[Shahelion]

Those three all loaded with a solid black background, but no other visual artifacts. Also, I went back and added screenshots to my previous comments.

[malcolmriley]

Thank you for your time and continued patience. Adding the screenshots is appreciated, so thank you for that as well.

I have prepared another trio for testing:

[Shahelion]

Perfect!

[malcolmriley]

Then that's the fix. Your time, patience, and continued assistance in this matter is greatly appreciated. With 77c715d I have applied an automated fix to all the sprites in this repository. This should allow any of the sprites in the repository to be used in any software affected by the same issue, and has the happy side effect of reducing the file size of many sprites.

The following explanation of the issue may or may not be of any interest to you, but on the internet we are joined by the ghostly presence of future knowledge-seekers, so here it is.

There were two issues at play here:

The first issue was that, as you surmised, the translucent areas had errant color data. A hypothetical pixel srgba(255,0,0,0) would still have a maximum red-channel value even if the alpha channel was such that the pixel should be fully translucent, even if the PNG palette also included other zero-alpha entries, such as srgba(0,0,0,0). This was the cause of the peculiar extra pixels, as they are leftovers from the editing process. It is not surprising that GameMaker doesn't discard this data on load, as in the context of game development there are legitimate use cases for preserving color channel data in fully transparent pixels, such as for shaders. It was sloppy of me to assume that either ImageMagick or optipng would discard these values from the palette, but fortunately it was simple enough to compel them to do so.

The second issue was more difficult to identify, and I believe it has to do with the fact that the PNG format standard has evolved since GameMaker 8 stopped receiving support. In the PNG file format, the alpha channel is actually stored separately from the other color channels. For some reason, GameMaker 8 seems to discard the alpha table when encountering indexed-color PNGs of certain color/alpha channel bit depths, possibly because those combinations were not part of the spec when the GameMaker 8 was written. According to the specification, the alpha channel is considered optional so I suppose it could be argued that this is a more compliant failure state than any other. Finding the correct combination between channel bit depth while trying to minimize file size took a few tries, but the result is worth it if it means that the repository can be of use to older software.

I have updated my formatting/optimization script to work around these issues, which actually leads to a file size reduction in most cases, largely due to palette reduction. Thank you again for your time, and good luck with your project!