Support textures in TX_START..TX_END markers

[andwj]

These two commits add support for textures within the TX_START and TX_END markers. Both composing wads and extracting wads are handled.

It normally converts textures to/from the DOOM patch format, but using a positive integer after the texture name in the wadinfo.txt file causes a PNG or JPEG file to be stored directly in the wad (i.e. no conversion is done). When extracting, the first few bytes of a lump are inspected to determine if the lump is a PNG or JPEG image.

[chungy]

but using a positive integer after the texture name in the wadinfo.txt file causes a PNG or JPEG file to be stored directly in the wad (i.e. no conversion is done)

Can you explain more how this works?

In general this looks good but I'm concerned about becoming confusing with converting to/from PNG and Doom's patch format and storing a PNG directory. :)

[andwj]

This aspect was something I struggled with myself, because textures in the TX namespace can either be PNG format or DOOM patch format (and for ZDoom, other formats like JPEG).

My solution to this is to slightly abuse the X/Y offset mechanism (the two optional numbers in entries in the wadinfo.txt file). When the X value is absent, left at zero, then we convert the image file to DOOM patch format when composing. When the X value is 1 (or any positive value), we look for a PNG or JPEG file and insert it directly when found.

The opposite happens during extracting: the code detects if the lump is a PNG or JPEG file, and if so then it is extractly directly (no conversion), and "1 0" is appended to the entry in the wadinfotxt file (the X/Y offset values). Othewise it assumes it is a DOOM patch format texture, and writes the image as it would for a graphics lump, generally as PNG but possibly as PPM if the HAS_LIBPNG config variable is unset.

The only other approach I thought of was to have two distinct sections in the wadinfo file, one for DOOM patches and one for real image formats. I found that concept very clumsy and unintuitive.

Rather than use (abuse) the X/Y values, a new syntax could be introduced to somehow indicate that an entry should be stored as a real image format instead of converted to/from DOOM patch format. Such a syntax is potentially useful for other sections too (e.g. for PNG sprites). I'm happy to implement such a new syntax if that is preferred.

[chungy]

We don't want to break the wadinfo format too much, and I can't think of any good alternatives (you are very thorough in your own analysis of the options!), I'll merge. Thanks :)

[jmtd]

@chungy and I chatted about this a little on IRC. I think it would be good if, before the next deutex release, we adjust the wadinfo format for this feature to not overload x/y and instead extend the parser. It would break backwards compatibility, so older deutex's wouldn't read the wadinfo generated by this feature, but I think that's a better behaviour than silently format converting, if that's what it would do otherwise. @chungy didn't want to block merging this in the meantime since it's high-quality code :)

[andwj]

I agree that new syntax is the best way.

Compatibility has already been broken by the removal of AU and VOC formats for sounds (as I discovered when trying to build an old version of FreeDoom, which I unpacked years ago, with the latest Deutex). Plus the new syntax only kicks in when somebody either adds it manually to a wadinfo.txt file, or Deutex is used to extract a wad with raw PNG images inside it -- so I don't foresee any major issue with compatibility.

For the syntax itself, I like the idea of an optional "raw" keyword.

[chungy]

Compatibility has already been broken by the removal of AU and VOC formats for sounds

Which justified the move to 5.0.0 -- see https://semver.org/ for such details. we just oughtn't break compatibility from one 5.x release to the next (however, new features in 5.2 shouldn't be expected to work in 5.1, and so on).

[andwj]

I have thought about the syntax, and here is a concrete proposal:

After the lump name, and before the offsets, there is an optional keyword which can either be "PNG" or "JPEG" (case is not significant). When present, Deutex looks for a file which that exact format, and if found it is inserted into the wad as-is (no conversion). For JPEG, we allow files to have the ".jpg" extension, since it is very common, but the keyword must be "JPEG". Unknown keywords would be an error.

More keywords could be added in the future if other formats are deemed desirable, e.g. I think ZDoom supports "TGA" (Targa) format images. But I think PNG and JPEG are enough for now.