PNG-loading fails silently for valid PNGs (FIX INCLUDED!)

[RockstarRaccoon]

TLDR: proposed warning code for non-loading of non-standard PNGs. (Git-commit here)

Last night there was an issue with a set of hires textures not appearing, which stumped the entire Discord, including Rachel, Marisa, and WildWeasel. This led to me having to download the latest source and run it with breakpoints to find why some relatively standard publicly available PBR materials were silently failing to show in-game. After rooting around with breakpoints, I finally found the culprit, which is a set of lines which determine if the PNG in question fits the specific criteria which GZDoom supports: it turns out the images had a bit-depth of 16, instead of 8, AKA 64 bit color.

These lines have no Warnings on them, and lead to a totally-silent failure on a completely undocumented caveat that very few people in the community would even about.

These were not rare images: they were from one of the first sites that come up when looking for non-commercial PBR materials. ( https://cc0textures.com/ ) Not only were they in a perfectly valid format which everything else in the typical development stack (GIMP, Slade, UDB) treated as normal without any warnings, but it should be expected that other people will come across similar resources and use them more frequently as time goes on: 64 bit color is overkill for games, but for the high-end rendering these were made for, it's becoming common to find them in the wild.

GZDoom is the ONLY program in the typical development stack which has this narrow of support for the PNG format. As such, the average developer will have no other way to figure out what's going wrong without these: these CANNOT be allowed to fail silently. As things like PNG-compression and 64-bit color become more common in royalty-free PBR materials, support should probably be an eventual target, but in the meantime, and even when support is achieved, there should still be a warning to prevent this from being an issue the next time things change.

The following commit adds warnings to prevent the dreaded silent-failure scenario I was experiencing, so that other people won't get stuck with no explanation when they try to unknowingly use 64-bit PNGs...
https://github.com/coelckers/gzdoom/commit/6a89da4647f8bbc705c987f4f1e2c0bd986c2ba7

The pk3 that was giving the problem, for reference, is at the following link. It will load in both SLADE and UDB without any issue, but will fail silently in the current build of GZDoom.
https://drive.google.com/file/d/1ConZy866Zy86QtuqzFZLwJKniWy44fMn/view?usp=sharing

[Graf Zahl]

Just adding warnings does not sound like a fix - what precisely *is* the format that does not work?

And your commit is not presented as a PR so how can I merge it?

[RockstarRaccoon]

Just adding warnings does not sound like a fix - what precisely *is* the format that does not work?

It's a fix because the silent-failure was bad enough on its own that I'd say it was never intended, and is pretty much a bug in its own right.

The format that doesn't work is PNG: these are valid, industry standard PNG files, which are perfectly readable by programs meant to work with PNGs meant for GZDoom. You probably don't have to put in support for different color-depths or whatever right away, but not having then AND not having a way for the user to see why things are simply not working is going to make more people go on these several-hour bug-hunts like I just did, trying to figure out why what looks like a valid PNG is not loading.

Expanding support for more of the PNG format is gonna take a lot of work though, especially for something that could easily be worked around by just converting the files down to the specific criteria supported by GZDoom. I don't have time to program it in, nor do I think it should be high on the list, even though you'll probably want to add it eventually just because 16-bit-depth images are showing up more.

And your commit is not presented as a PR so how can I merge it?

Bleh. I felt like I was doing something too easily for Github. I'll go do it the long way...


Edit: I'll figure this out in the morning. I'm really not a fan of Github: it always seems so convoluted to me, but that's probably just because I've never had to use it for anything but a few code-additions to open source projects here and there.

[RockstarRaccoon]

I think I did it right this time...
https://github.com/coelckers/gzdoom/pull/1302

Like I said, I'm just not used to GitHub's interface and methods, so when it offers me options like "suggest a change", I assume it means that's a valid way to send in a change... But I'm seeing now that what I just did is triggering a bunch of build-testing stuff, so It's clearly what I was supposed to do...