PCX and PNG support for external textures (also maybe JPG)

[SirYodaJedi]

Progress:

• [x] PNG+JPG (via STB_Image)
• [ ] PCX

Original post: Currently these tools support external textures using TGA, as well as WAL and MIP. While TGA is fine for development, baseline source ports support additional file formats for replacement textures that are more space efficient, and TrenchBroom also supports mapping with said formats. Therefore, I think it makes sense to support more image formats.

Quake I should be pretty simple. QuakeSpasm supports TGA and PCX replacement textures. PCX support uses the LoadPCX from vanilla Quake, which only supports 8-bit paletted with no alpha channel. While TGA seems to be more commonly used, I do think PCX is often better for opaque images in Quake, since LoadTGA only supports 24-bit images, but custom textures often only have 16-256 colors, so truecolor isn't really necessary. Afaik, these tools use the same license as Quake I, so it should be possible to use LoadPCX.

Quake II is a bit more complex. Yamagi Quake II supports TGA, PNG, and JPG replacement textures using STB_Image. PNG seems to be the most common, and several PNG image formats are supported (even 1-bit). This would probably require a either a lot of additional code, or a library dependency.

Glancing at the code, PCX support shouldn't be too difficult to add. PNG support would require major refactoring, though. If PNG support were to be done via a library dependency (such as YQ2 using STB_Image), then it would be trivial to add JPG support in the process.

[ericwa]

Sounds good, adding stb_image would be fine.

[Paril]

Shouldn't be any refactoring necessary, all of the image code is in one file and just has to grab either the metadata, the pixel data, or both. stb_image should be fairly painless to hook in there.

[ericwa]

JPG + PNG loading are in via stb_image.

All that remains for this is finishing the PCX loader (we already have one for loading palettes.)