crashinvaders/gdx-texture-packer-gui

Bug? Same sized sprites (alpha pre-multiplied, rgbs are different, alphas are all zeros) will be overwritten.

powof2 opened this issue · 6 comments

powof2 commented

Hi there,

If two same sized sprites (the sprites already alpha pre-multiplied before adding to the tool, they have same alpha values(all zero) but different RGBs), they will be overwritten, that is, the two sprites will share same uv rect,
Please check, thank you.

p.s. Uncheck 'Ignore Blank Imgs' wont work.

metaphore commented

Hi there, thanks for the report.

If I'm not mistaken you have two same size source images with different RGB channels, but fully transparent?

If so, it sounds like if you pack those with alpha premultiplied on, they will become all zeros for all the channels and thus equal. That case sounds like a valid behavior. Not sure what the reason of having such images packed with premultiplied alpha, their data gets lost entirely in that case.

powof2 commented

Hi metaphore,

Thanks for your reply.

Yes, they are same size images with differnt RGBs and they are not really fully transparent :

  • if you do ordinary Alpha Blending, the two images are fully transparent.
  • if you do Additive blending (Particle effects for example), they are not transparent: their RGBs will be added to background pictures.

so these kind of images (with all zeros alphas) should be packed and not to be ignored.

metaphore commented

Ah, I see. Thanks for the explanation.
I will check on that in the coming weeks as I'm pretty busy atm. Should not be a big deal to fix.

powof2 commented

Thanks.

metaphore commented

Let's keep it open till it comes to a resolution.

metaphore commented

Sorry for such a long delay, but better later than never :)

I've looked into the problem and noticed an interesting bug. So in general case image equality comparison works fine, except for when indexed color mode image is used (I particularly tested with indexed PNG).

Unfortunately this behavior is a side effect of Java's image manipulation code and there's no simple fix.
Technically this happens when we convert from BufferedImage.TYPE_BYTE_INDEXED to BufferedImage.TYPE_4BYTE_ABGR (or basically any non-indexed format).

I'm afraid we stuck with this. But since it's not a critical bug, and doesn't worth switching the entire code base to another image manipulation library, the best I can do is to add notice to the checkbox description.

As for the workaround, you should switch all the PNG images from indexed to RGB color mode.

I'm going to close this issue, but if anyone has any idea on technical solution, please feel free to reopen.

image