TEXTURE2 lump: does anyone ever use it?

[Linguica]

The Doom engine supports loading textures from two texture indexes: TEXTURE1 and TEXTURE2.  This was originally done so that the Doom shareware could have everything in TEXTURE1 and then all the registered-version textures would be added in TEXTURE2. In Doom 2 only TEXTURE1 is present, but the engine will still attempt to load a TEXTURE2.

 

From looking at a smattering of Doom 2 megawads with new textures, it seems like all of them only use a TEXTURE1 that redefines all the IWAD textures / replaces them with new ones. However, it seems like the "right" way to do it would be to treat textures the same way id Software did for Doom 1 - leave TEXTURE1 in place with all the "normal" textures, and then use TEXTURE2 to define any new or replacement textures.

 

Is there some fundamental reason I'm missing why this would be a bad idea, or is it more likely that it's just due to momentum / tools not supporting it?

[BigDickBzzrak]

I do that sometimes, saw the idea in a post by Gez or sci42 and used it where appropriate since then. I haven't seen anyone else do that.

Especially useful when using a big texture pack that you still need to compliment with a few textures of your own.

The tools fully support it btw.

[Jaws In Space]

I wasn't even aware that this was an option that existed.

[Mr.Rocket]

I'd image it's just that most authors use Doom2 as a go-to example and said pwad gets created based on that.

[pcorf]

Doom.wad

 

TEXTURE1 contains the textures only from Episode 1 (Doom1.wad or shareware version).

TEXTURE2 contains the additional textures used in Registered Doom (E2, E3 and later SKY4 for E4)

 

Doom2.wad

 

TEXTURE1 contains all textures.

 

I am sure with additional textures you can add them both to TEXTURE1 and TEXTURE2.

[Jimmy²]

TEXTURE2 I've found has presented me with problems, when it comes to providing resource WADs, anyway -I believe it was with zoon-tex that I tried this out, and while GZDoom loaded the new textures fine, in PrBoom+ the TEXTURE1 lump was seemingly completely overwritten by the TEXTURE2 lump. I'm not sure how I could've done it wrong.

 

 

But yeah, if indeed it can be used without issue, then it would be very very useful.

 

TEXTURE3-9 as well, please. Please, source port devs?

[Linguica]

I did a quick experiment and it looks like trying to use TEXTURE2 as a simple, uh, "delta" for new textures has one massive fatal flaw: the Doom engine won't actually use the redefinition of an existing TEXTURE1 texture in TEXTURE2. Unlike most things with the Doom engine where something in a PWAD overrides the IWAD, when it comes to texture definitions, the engine just takes the *first* match for a texture name it can find, so if you, say, redefine STARTAN2 in a TEXTURE2 lump in a PWAD, the engine will never actually get to it because the search will hit the original texture first and use it.

 

If however you don't replace any IWAD textures and simply add your own (along with a new PNAMES of course), I imagine it ought to work fine?

[Da Werecat]

IIRC, there was a time when I used it to separate the textures that are required in order for the engine to not crash, format your hard drive, and explode your monitor (read: skies and switches) from everything else. I think I did it so it would be easier to purge the entire set without screwing with those necessary definitions.

 

Nowadays I don't really care about textures being stored in alphabetical order, therefore I don't really feel compelled to re-import them regularly, therefore I don't care in general.

[kb1]

20 minutes ago, Linguica said:

I did a quick experiment and it looks like trying to use TEXTURE2 as a simple, uh, "delta" for new textures has one massive fatal flaw: the Doom engine won't actually use the redefinition of an existing TEXTURE1 texture in TEXTURE2. Unlike most things with the Doom engine where something in a PWAD overrides the IWAD, when it comes to texture definitions, the engine just takes the *first* match for a texture name it can find, so if you, say, redefine STARTAN2 in a TEXTURE2 lump in a PWAD, the engine will never actually get to it because the search will hit the original texture first and use it.

 

If however you don't replace any IWAD textures and simply add your own (along with a new PNAMES of course), I imagine it ought to work fine?

(some ramblings)

I think vanilla, at least, will load the duplicate texture names along with the original texture names, but the linear texture search will stop on the first match.

 

You know, I'm not sure, but I think there's a chance that Lee Killough's chained-hash rewrite of TextureNumForName (or whatever) might reverse the order, cause that type of implementation finds most-recently-added first. If so, the hash should be filled backwards (and maybe it is - I haven't yet looked).

 

However, Doom will handle the loading of the TEXTURE1/TEXTURE2 lumps as it does with all other lumps, so if you supply new TEXTURE1/TEXTURE2/PNAMES, they will be used instead of the IWAD versions. So, delta? No. But, replacement? Yes.

 

Having said that, yes, you should be able to use a TEXTURE2 in your PWAD, if:

• the IWAD is Doom II
• you use unique texture names
• you include a new PNAMES that defines patches for the IWAD's textures AND your TEXTURE2 textures, or:
• your TEXTURE2 lump only uses original patches

An interesting idea!

[scifista42]

6 hours ago, bzzrak said:

saw the idea in a post by Gez or sci42

Back when I first saw the idea in someone's post, I immediately tested it in various ports and found out that it didn't work in some ports, thus I never spoke in favor of the idea and I might have spoken against it whenever I saw someone recommending it. But I was actually trying to replace stock textures in those tests, and now I'm glad to learn that this was the problem, not the ports.

[Urthar]

I'm using TEXTURE2 in BOOMQTEX, because it initially seemed cleaner to do so. At the time of that decision I wasn't really aware of any issues with it. But it worked out since I had no intention of supporting the Doom texture set, since that would allow me to customise the palette much more drastically.

 

And yeah, IWAD maps look pretty wierd with it:

 

 

[Jon]

Interesting to read some of the drawbacks. WadC generates a TEXTURE2 lump if you define any textures in your map. That predates Doom support, so there's problems there, and I might one day change it.

[Cacowad]

Well, i actually used it when adding new textures for Blasphemer, i just guessed it was the right thing to do to mantain everything clean... Didn't knew it could act weird in some circunstances.

[RjY]

This might seem like a good idea in theory but please note it is unwise to replace only a proper nonempty subset of {TEXTURE1, TEXTURE2, PNAMES} if you care about portability of your maps to alternative iwads. Please only replace all, or none of them.

 

"Yeah PWADs with a TEXTURE1 and no PNAMES are not "portable", they are absolutely tied to the IWAD they are meant for"

"If you don't also include your own PNAMES, then I don't think we can guarantee compatibility"

PNAMES wad for FreeDoom

DTWID doesn't run

 

(Search the Freedoom forum for "TEXTURE2", "PNAMES" etc.)

[Jon]

WadC currently only includes a PNAMES lump if you define new patches (I think). So I guess the proper behaviour should probably be

 

 * generate TEXTURE1, not TEXTURE2, and import the IWAD's definitions

 * always include PNAMES if including TEXTURE1

[Reisal]

I'm using TEXTURE2 for my Hellbrary 2 map and with GZDoom (and I think classic ZDoom), I've not come across any visual anomalies.

[kb1]

Please correct me if I'm wrong: I think the only time something undesirable/weird happens is when a texture name is defined more than once. In that case, the definition that the engine will use is unpredictable, as it is based on how the texture lookup function (TextureNumForName) is written in the port being used.

[Urthar]

13 hours ago, Glaice said:

I'm using TEXTURE2 for my Hellbrary 2 map and with GZDoom (and I think classic ZDoom), I've not come across any visual anomalies.

Yeah the ZDoom family of ports are more robust in that regard, though the TEXTURES lump is the reccomended option:

 

https://zdoom.org/wiki/TEXTURES

[scifista42]

10 hours ago, kb1 said:

Please correct me if I'm wrong: I think the only time something undesirable/weird happens is when a texture name is defined more than once.

The issue mentioned by RjY causes something undesirable regardless of texture names.

[Mordeth]

A while ago I removed stock Doom2 texture definitions from my M:E2 TEXTURE1 lump, since it got kinda big and cumbersome with these three different episodes in the making. PNAMES still contains everything. In this custom TEXTURE1, only modified or completely new textures are thus defined. There are also new graphic patches for stock vanilla textures.

 

First there seemed to be no problems, as long as the first entry was still the dummy AASHITTY texture. A few weeks ago I noticed that some stock Doom2 textures (notably the brown ash walls in vanilla MAP01) were still missing in-game. But not all stock Doom2 textures, even if those textures were no longer defined in my custom TEXTURE1 lump. For example, the entire start area of MAP01 rendered just fine. GZDoombuilder also did not seem to have a problem. Just some textures went poof in-game.  Perhaps the inclusion of new graphic patches for vanilla textures is somehow causing some problems in processing down the line..?

 

Renaming my TEXTURE1 lump to TEXTURE2 solved this problem, and I can use/see both stock Doom2 textures as well as my new or modified ones. Using Eternity Engine, naturally.

 

So basically, I do not see the issues @Linguica just mentioned. Unchanged TEXTURE1 stuff is still there; modified (in graphic/dimensions) TEXTURE1 textures now in TEXTURE2 also display fine.

[printz]

I didn't even know Doom 2 supports TEXTURE2. I thought it's only for registered Doom 1.

[Gez]

10 hours ago, Urthar said:

Yeah the ZDoom family of ports are more robust in that regard

ZDoom behavior:

Quote

Vanilla Doom only loads one PNAMES, one TEXTURE1 and one TEXTURE2 lumps; each being the last encountered. ZDoom allows cumulative loading, though only one TEXTURE1 and one TEXTURE2 lump will be loaded for each archive; and in each archive TEXTURE1 is loaded before TEXTURE2. Each TEXTUREx lump uses the last previously-loaded PNAMES lump as a reference (so for example, the IWAD textures always use the IWAD patches).

A single texture can be redefined by a later TEXTUREx lump, however if a texture is defined more than once in the same TEXTUREx lump, the later definitions are skipped. In other words, a texture uses its first definition in the last lump.

 

[ukiro]

The biggest issue with this approach is skies, specifically if you're mapping for vanilla and thus won't use sky transfers. Since the sky is a texture and F_SKY1 automatically links to the TEXTURE1 definition of the episode-appropriate sky, it seems you can't override the IWAD SKYn with TEXTURE2.

 

When loaded this way, Doom tries to find patches for the original SKYn but that isn't included in my custom-textures-only PNAMES. So it just seems to grab whatever patch was at that same position in the file (?), which in my case is a patch that isn't fully 128px tall, resulting in a medusa error. PrBoom+ shows a mostly black sky and runs smoothly, but GZDoom slows to 1 fps on a 980Ti.

 

My solution, for now, is to add a TEXTURE1 which just redefines SKY1 through SKY4. (And AASHITTY since that acts as a marker). But this is not the elegance I wanted: Ideally my TEXTURE2 based resource WAD should be compatible with all WADs using TEXTURE1, and I just redefine the skies. Is that possible and I just screwed up somehow?

 

 

 

[Xaser]

For TNT2.wad (yes it exists), I have all the custom stuff in TEXTURE2 for organization's sake; however, there's still a TEXTURE1 lump present that has all the IWAD stuff in place. The idea of omitting it, only adding new textures with new names, and relying on the IWAD's TEXTURE1 lump sounds intriguing, but skies indeed throw a monkey wrench into the mix.

 

Overall, Doom's texture management sucks donkey balls no matter how you kick it.