"High Resolution Textures w/o the High Resolution" problem

http://www.doomworld.com/idgames/index.php?id=15725

For the longest time I am still trying to figure out what's causing this, as it's absolutely baffled me. ASHWALL4 (at least I think that's what it is) is the ONLY broken texture in the entire WAD. Nothing seems to be wrong inside of the WAD itself however, and even replacing/deleting that texture will still cause it to not show up in-game.

For early reference, this texture wasn't broken in Skulltag 97D5, but broke in 98A and subsequent releases. I say ST because I was using ST a lot in 2009 when I got heavy into it, and I thought the convenience of "software and hardware in one + multiplayer = automatically better than G/ZDoom". So I have no idea how it works in older G/ZDoom but it seems to be broken in the new releases as well.

It also refuses to work in PrBoom+ due to "R_TextureNumForName: SKY3 not found" which doesn't even make sense as the skies aren't replaced.

If anyone knows what's the deal and is well endowed in that PNAMES/TEXTURE1 business, would they look inside themselves to see what's causing this? I have no experience in this field but there is a possibility something isn't named properly or the PNAME/TEXTURE1 lumps are broken.

Cyanosis said:

http://www.doomworld.com/idgames/index.php?id=15725
ASHWALL4 (at least I think that's what it is) is the ONLY broken texture in the entire WAD. Nothing seems to be wrong inside of the WAD itself however, and even replacing/deleting that texture will still cause it to not show up in-game.

It also refuses to work in PrBoom+ due to "R_TextureNumForName: SKY3 not found" which doesn't even make sense as the skies aren't replaced.

Well, that's obvious. PrBoom+ complaint about SKY3 is completely justified, as there's indeed no SKY3 texture in wad's TEXTURE1. (Never mind flats in PNAMES.) As for ASHWALL4, it's the first texture in TEXTURE1, which causes it to be rendered as HOM.

Cyanosis said:

It also refuses to work in PrBoom+ due to "R_TextureNumForName: SKY3 not found" which doesn't even make sense as the skies aren't replaced.

In vanilla, the TEXTUREx lumps aren't cumulative. The game will load the last one it finds, and ignore all others, so if the last lump doesn't contain all textures, some will be missing.

Randy changed that in ZDoom so that texture lumps would be cumulative, the engine loading each of them in order, allowing a mod to only define the new textures without having to copy all the standard texture definitions as well. But on this point, it hasn't been imitated by other port authors.

For the other issue, see AASTINKY.

I really like this texture pack and had been confused by this as well.

Here's a set of replacement PNAMES/TEXTURE1 lumps - for anyone who wants/needs PrBoom+ compatibility.

Somehow, someway, you were able to fix what I wasn't able to (even tried adding AASHITTY to the lump but that didn't seem to work either) and for that, I owe you my gratitude!

Gez said:
Randy changed that in ZDoom so that texture lumps would be cumulative, the engine loading each of them in order, allowing a mod to only define the new textures without having to copy all the standard texture definitions as well. But on this point, it hasn't been imitated by other port authors.

As it happens I've been looking at this recently, and since the original poster's question has been more or less answered, I don't feel bad about derailing the thread :-)

In particular I'm wondering how to work out which PNAMES goes with each TEXTUREn. I came up with this heuristic: if there's a PNAMES in the same wad as the TEXTUREn, use it, otherwise the wad probably depends on the PNAMES from the IWAD.

However I might have missed some subtlety, so I would appreciate an explanation of how ZDoom does it. The wiki seems rather silent on the issue (http://zdoom.org/wiki/TEXTUREx, http://zdoom.org/wiki/PNAMES only mention that patch numbers in TEXTUREn are listed in PNAMES but says nothing about which PNAMES if there is more than one)

Thanks in advance.

If you want to check the code, it's all in src/textures, in the files texturemanager.cpp and multipatchtexture.cpp. Start from FTextureManager::Init().

ZDoom merely loads the most recent PNAMES lump up to the current archive. Let's say you're loading the following files:
A.WAD contains only TEXTURE1
B.WAD contains both PNAMES and TEXTURE1
C.WAD contains only TEXTURE1
D.WAD contains only PNAMES for some reason
E.WAD contains only TEXTURE1 again
F.WAD contains both PNAMES and TEXTURE1

When loading A.WAD, ZDoom uses the IWAD's PNAMES.
For B.WAD, it uses the included PNAMES.
For C.WAD, it uses B.WAD's PNAMES.
For E.WAD, it uses D.WAD's PNAMES.
And for F.WAD, it uses the included PNAMES.

If an archive contains several PNAMES lump, only the last one is loaded. Likewise, only the last TEXTURE1 and TEXTURE2 in a given archive are loaded.

If a texture lump redefines a texture from a previous lump, it overrides the older one. However, if for some reason a same texture is defined several times in the same lump, only the first is loaded, the following are skipped.

Finally, when loading textures from an archive, ZDoom starts with the binary definitions (PNAMES + TEXTURE1, TEXTURE2), then the textures in between TX_ markers, then the textual definitions (TEXTURES, HIRESTEX), and finishes by handling high-res texture replacements (HI_ markers).

The first texture from a TEXTURE1 lump is always considered a null texture. I guess this is what changed long ago and is partly the cause of the issue in the OP.

Cyanosis said:

Somehow, someway, you were able to fix what I wasn't able to (even tried adding AASHITTY to the lump but that didn't seem to work either) and for that, I owe you my gratitude!

You're welcome, I've dealt with problems like this before.

I hate to bump, but I am the thread starter so I think that is okay.

Well, not sure what the deal is but it seems that the first three skys in UDoom (Ultimate Doom) break, they're just a black void. However, Thy Flesh's orange sky works just fine. D2 has no problems as well. But I first noticed something was up when I was on TNT and there was D2 skies in it, and Plutonia suffers from a similar issue. Not to mention on MAP21 of Plutonia there's some odd texture errors going on in there near the start.

I ran a test with a PWAD that featured a new sky to make sure it didn't cause problems with that too but custom skies seem to work just fine. I don't know what's up, but the modified WAD is not D1/Final friendly, at least with the skies. If nothing can be done to fix this it's not a big deal, the WAD still has plenty of potential when playing PWADs.

All the Doom games use the same texture names for the sky (except Ultimate Doom's EP4 sky, which is exclusive to UDoom). Though they all use different sky graphic patches.

The wad includes a PNAMES and TEXTURE1 lump for Doom2. Therefore it maps the sky textures to Doom2's sky graphic patches.

Doom1/Ultimate Doom lacks the Doom2 sky graphics patches, hence nothing get's displayed. Both TNT and Plutonia Iwads include the Doom2 sky graphic patches, but don't use them by default.

Ultimate Doom's EP4 sky works because GZDoom supports reading multiple PNAME and TEXTUREx lumps.