Fix #358

[scurest]

This fixes #358.

The cause was pretty obvious: transparency was being decided based on color (ie. is this pixel's index's color the color of index 0?) instead of index (ie. is this pixel's index 0?). Unfortunately, since EasyRPG never saw the indices (libpng handled it) this required a new path for handling indexed images with transparency, and then I wanted a new path for grayscale images to handle their transparency, and then I just pulled the rest of the image types out for the sake of symmetry, and that's how I got such an ugly commit :( Changes welcome.

• I know there's a lot of repeated code, but I'm not sure what the best way to refactor it is.
• Does ReadPalettedData need the if (bit_depth == 16) check?
• I used malloc for the temporary buffer in ReadPalettedData just because that's what pixels used, but should I prefer new[]?
• 8026ee4 gets rid of the temporary array, but it's a little tricky, so I'd appreciate if someone could check it (details in commit message).
• I didn't test a grayscale image. Someone should probably do that. Seems fine.

(This is me reading the libpng docs)

[fdelapena]

Thanks scurest, looks a clever way to fix this. I was thinking on getting a transparent mask then applying them after but I was feeling it dirtier as it was requiring to modify the transparent palette calculation code when the issue was really in the PNG handling. Not tested but I guess this should work fine with BMP and XYZ image readers.

About the temporary array allocation removal adds some extra operations on a nested for I think won't make much slower the conversion, so looks good to me 👍.

About bit_depth I guess there are really very few images with 16 bits per channel, they are rare and limited for professional image use (raw conversion from cameras, medical images...), I don't think we will get a game with this, as RPG_RT does not support more than indexed PNGs with 1 channel palette, which don't support 16 bit depth. Only when a game is being designed specifically for EasyRPG Player may use 3-4 channel with 8 bit depth per channel. Using 16 bit depth would be extremely rare. I have never seen a PNG with 16 bit per channel yet.

[scurest]

fdelapena, thanks. About 16-bit depth, it's probably just me being finicky. You're right about indexed images not having 16-bit depths, so I took those out along, with the <8-bit depths for GRAY_ALPHA, RGB, and RGBA, which were also impossible.

[fdelapena]

Thanks, tested and working fine, now the new methods don't require the parameter:

src/image_png.cpp:108:36: warning: unused parameter 'bit_depth' [-Wunused-parameter]
  png_uint_32 w, png_uint_32 h, int bit_depth, bool transparent,
                                    ^
src/image_png.cpp:162:36: warning: unused parameter 'bit_depth' [-Wunused-parameter]
  png_uint_32 w, png_uint_32 h, int bit_depth, bool transparent,
                                    ^
src/image_png.cpp:190:36: warning: unused parameter 'bit_depth' [-Wunused-parameter]
  png_uint_32 w, png_uint_32 h, int bit_depth,
                                    ^
src/image_png.cpp:206:36: warning: unused parameter 'bit_depth' [-Wunused-parameter]
  png_uint_32 w, png_uint_32 h, int bit_depth,
                                    ^
src/image_png.cpp:221:36: warning: unused parameter 'bit_depth' [-Wunused-parameter]
  png_uint_32 w, png_uint_32 h, int bit_depth,
                                    ^

By the way, if you want to silence these warnings in image_png.cpp in the same pull request would be nice:

src/image_png.cpp: In function 'bool ImagePNG::WritePNG(std::ostream&, int, int, uint32_t*)':
src/image_png.cpp:241:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
  for (size_t i = 0; i < width * height; ++i) {
                       ^
src/image_png.cpp:269:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
  for (size_t i = 0; i < height; ++i) {
                       ^

Other tested formats for this bug (BMP, XYZ) are working fine.

[scurest]

Oops, that was careless. Should be fixed. Also added some cleanup on the return true path in WritePNG.