PNAMES/TEXTURE1/2 sucks.

[kb1]

18 hours ago, Dragonfly said:

I think you completely missed the point kb1.

Kinda takes the edge off when you don't explain said point.

 

16 hours ago, Gez said:

Also, doom.exe actually completely ignores P_START and P_END.

Really? Heh. I must be thinking of the sprite marker, which is definitely used. Still, the P_ markers are useful for editors when identifying lumps.

 

14 hours ago, Mordeth said:

 

Nowadays, the point is not to save disk space but to be able to combine existing patches into a new texture. So you don't have to open up your graphics editor of choice and create a brand new texture every time you need a new variation, and you especially don't have to redo a metric shitton of graphics whenever you replace or improve a patch.

Both are valid uses, of course. Are multi-patch textures really used that often these days, except for, maybe, switches? You make a good point, though: improving one patch instantly improves every texture that uses it.

 

12 hours ago, Jimmy said:

What is the point of this post? I know how the system works on a basic level, you numpty. I'm talking about combining different texture sets together, something I've done numerous times and always run into problems with due to how the system is structured.

Let me break it down:

 

The confusion stems from the fact that 4 types of changes can occur with texture wads. Texture wads can:

• Add new patch lumps - You can tell because the lumps have names not found in the IWAD.
• Replace IWAD patch lumps - The texture set's patches match an IWAD patch lump.
• Add new textures - The texture names are not found in the IWADs.
• Replace IWAD textures - The texture names match IWAD texture names.

With both types of Adds, the process is simple, and it's what I was describing in my first post: Just copy the IWAD's PNAMES and/or TEXTUREx lumps and append the new resources to them. Done.

 

For the Replace variety, you have to make a decision: Do I want to alter the appearance of the IWAD textures, or do I want to convert these resources into Adds? Unless it's something like a TC, or, say, a hi-res texture replacement pack, you probably want to convert the "Replaces" to "Adds". Because you want to make a large texture WAD that includes textures from multiple texture sets, for the rest of this post, I will assume that you want any and all "Replaces" to be changed into "Adds".

 

Note that all texture set combine issues stem from duplicate names, in some form or another. Here's a procedure you can use to combine texture sets:

Preliminary Steps

 

• 1. Use good tools. I have to stress that having good tools is the way to go here. At a minimum, you want a tool that can load both the IWAD, and a single texture set, and can show the patches and offsets that comprise a texture, the raw patch images, and the composited texture itself.
• 2. Make sure each individual texture set is defined properly (PNAMES/TEXTUREx, vs. the included patches). Some may include all the IWAD PNAME/TEXTUREx definitions, some may not. In other words, a texture set could simply replace patch lumps, without having any PNAMES/TEXTUREx defined. That's ok for now. What you don't want is a PNAMES/TEXTUREx set that defines patches that don't exist in either the IWAD or the texture WAD. Fix any inconsistencies. Prune any patch lumps with non-IWAD names that are not defined in either the IWAD's or the PWAD's TEXTUREx lumps. Then, prune any entries from PNAMES that define patch lumps that don't exist in either the IWAD or the PWAD. The idea is that the game should be able to load the IWAD, followed by the texture set, and be able to use those textures on walls without issues. So, in this step, verify that each individual texture set works.
• 3. Make 4 lists in a spreadsheet program that can sort: IWAD patches, IWAD textures, PWAD patches, and PWAD textures. Fill the IWAD patches with all the patch lump names in the IWAD. Fill the IWAD textures list with the names of all the textures in the TEXTUREx lump(s). Sort each list by name.
• 4. Experiment with your texture tool to figure out the best way to rename a patch. A good tool will let you rename a patch in one place, and it will update all textures to match this new name. When the time comes where you will need to rename a patch, the rename has to occur in the patch graphic lump, in the PNAMES definition, and everywhere the patch is referenced in all the textures that use that patch. Figure out how and in what order this works best, with your editor.

For each texture set

• Using your lump editor, load a single texture set PWAD, without the IWAD.
• Delete all textures that match IWAD textures, both in name, and in looks.
• Go through all remaining textures, and compare the names to the texture names in the IWAD and PWAD Textures spreadsheets, and if any match, rename the PWAD textures to a unique name. Write this new name into the PWAD Textures spreadsheet. This ensures that all textures will have unique names. If there's no match, add the existing texture name into the PWAD Textures spreadsheet.
• Go through the PWAD's patch lumps, and for each patch lump, see if its name is in either Patches spreadsheet.
• NOT FOUND: If a match is not found, add the patch name to the PWAD Patches spreadsheet.
• FOUND: If a match *is* found, you must devise a new unique name for this patch - a name that cannot be found in either Patches spreadsheets.
•     Rename the patch lump.
•     Add the NEW name to the PWAD Patches spreadsheet.
•     How you perform this step depends on what your tool can do. Hopefully, it lets you rename a PNAMES entry, and it will update all textures. At any rate, you must rename the PNAMES entry, and that change needs to be reflected in all the PWAD textures that used the old name.
• Save the texture set PWAD.

Final Step

• Load the IWAD, and grab the PNAMES and TEXTUREx lumps, and paste them into a new PWAD.
• Open up each edited texture set PWAD, and move the patch lumps to the new PWAD.
• Append the texture set's PNAMES and TEXTUREx entries to the new PWAD.
• Done

What's important to note is the way Doom loads its resources. For duplicate lump names, Doom always loads the *LAST* one encountered. This is true for individual patch lumps, and also for entire PNAMES and TEXTUREx lumps. Some ports will auto-concatenate PNAMES and TEXTUREx datasets, but if you want your texture set to work across all ports, you have to do the work to provide replacement PNAMES/TEXTUREx lumps yourself. So, if you make all texture and patch names unique, and all patch lump names unique, there are no conflicts.

 

It's a pain, but it doesn't have to be confusing. I'm sure you know all of this, but because of some of the rudeness in this thread, I wanted to provide an exact set of steps to clarify my thoughts. I hope I didn't miss anything - it's not the easiest thing to type out. I did assume a good knowledge of the tools and procedures involved. Hope that helps. Again, using good tools is half the battle. The other half is avoiding "Replacers", and avoiding duplicate names.

 

What is a numpty? :)

 

How to improve:

I think ZDoom's additive PNAME/TEXTUREx parsing handles things pretty well. The big remaining problem is duplicate patch and texture names. Since you basically have 8 characters, this is a real issue. Map formats can/may improve on this, so you could specify "BrickTextures:BRICK12" in a sidedef, but that's kinda awkward. "T_000123" might work for texture sets, allowing for 1 million textures, though it requires coordination amongst texture sets, and it removes the usefulness of having a texture name.

 

I'd vote for long names, but that requires a custom PNAMES, custom TEXTUREx, custom sidedef struct, and custom sector struct. UDMF to the rescue!

 

Edited June 23, 2018 by kb1 : How to improve

[Mordeth]

6 hours ago, kb1 said:

Are multi-patch textures really used that often these days, except for, maybe, switches?

 

Nope. Can't say I've seen it used in ages. Although I'm using it quite extensively for the reasons mentioned, still using ancient tools like deutex to create the lumps.

[printz]

Doom patch layering is superseded by Photoshop-like layering in image editor projects. Such layers end up merged together when brought into Doom.

[Gez]

Given the feature requests that there have been for patch layering (blending and translucency types) in ZDoom's TEXTURES, I'd say yes.

[Jimmy]

There are also texture packs like Patched Up which utilise the power of multi-patch technology™ to create a slew of new variants of the stock Doom 2 assets using just the stock patches. It's a really impressive set, too.

 

I would not be for abolishing this setup entirely. But a system less prone to overwrite/conflict issues and the mandatory requirement of stock asset redefinition absolutely needs to be talked about.

 

Think about how many times the same order of bytes appears on the internet, redefining Doom 2's TEXTURE1 set every single time without alteration, just so custom texture assets can be used at all in a custom PWAD. There's probably more bytes gone into this than have gone into single map WADs, I wager.

 

I ran into a problem just yesterday during the endurance speedmapping stream in which I couldn't test two WADs together (a texture resource WAD + a map with a few extra additional textures) - because they both had a TEXTURE1 lump, and PrBoom+ would not even start if the two were loaded side by side. That right there seems like something that desperately, vitally needs to be addressed. Every other kind of resource is loaded additively and without issue - why not textures?

[ukiro]

7 hours ago, Jimmy said:

There are also texture packs like Patched Up which utilise the power of multi-patch technology™ to create a slew of new variants of the stock Doom 2 assets using just the stock patches. It's a really impressive set, too.

 

This also reminds me that negative Y offsets are not supported in vanilla (Patched Up uses this frequently). Are there any source ports, other than chocolate I guess, that retains this bug?

 

[Jerry.C]

7 hours ago, Jimmy said:

I ran into a problem just yesterday during the endurance speedmapping stream in which I couldn't test two WADs together (a texture resource WAD + a map with a few extra additional textures) - because they both had a TEXTURE1 lump, and PrBoom+ would not even start if the two were loaded side by side. That right there seems like something that desperately, vitally needs to be addressed. Every other kind of resource is loaded additively and without issue - why not textures? 

 

I'd say that this wasn't addressed by most ports because it's a very complex thing to get right. Just have some fun and check out the change history of this code in ZDoom since its inception long ago in version 2.0.48. It required an endless amount of fixes, workarounds and reorganizations to get right. Don't forget that you got two or three lumps here that need to be matched properly so that the engine doesn't throw up. How much easier is it to just leave everything the way it is and not think about it from a port author's perspective? ;)

 

 

[kb1]

Problem is, if you go changing how textures work, you break compatibility with other ports, existing mods, etc. Sure, you can create a totally separate system, and then you can make your textures work with that port, and no others.

 

And, again, the proper tool can manage this quite easily. I guess there is no such tool, but there should be. I tend to write my own tools for such problems. Unfortunately, my tools are usually hacked into another program which is not generic enough to give out at the moment. But, a Texture Merger program is a very do-able thing. There are WAD APIs that would assist in such a project, like @Jon's work.

[anotak]

a little update on having >8 char texture names in dbx, me and bmsq on github may have arrived at an appropriate workaround to the issue.

see here for technical information:

https://github.com/anotak/doombuilderx/issues/6