Gez
Why don't I have a custom title by now?!
Posts: 7036
Registered: 07-07 |
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.
|