[Feature request] Get rid of TEXTURE1

[Hirogen2]

Hi,

it would be cool to have textures between, say, TX_START and TX_END, without having to add then to PNAMES and TEXTURE1. This would greatly improve the ability to load multiple texture packs on top of another without removing (cause of PN/TX1) other ones.
PN/TX1 was once invented so that patches can be used multiple times in a texture, but I think we nowadays have enough disk space

And for those WADs who still have PNAMES/TEXTURES1, it would be great to make them additive, so they work too.

[Chris]

This is kind of redundant to do since all you have to do is place a patch in a wad and use it whenever/whereever(once 48.cab gets out anyway *nudgenudgewinkwink Randy*).

But I think it'd be cool of TEXTURE1, TEXTURE2, and PNAMES could be made accumulative like MAPINFO and such are.. but I don't think that'd be really feasible given how they work. Although maybe it is feasible.. I dunno.

[Enjay]

Agreed, very soon to be redundant, but I thought Texture1 and Texture2 were already cumulative - at least in Doom 1. Not all the textures in Texture1 are in Texture2 and vice versa. IIRC one has the SW texture set, the other has the full game specific ones.

[Chris]

TEXTURE2 is cumulative to TEXTURE1, yes.. that's what it was designed for. But I think he means loading multiple wadfiles that each have TEXTURE1/2 and PNAME lumps, and have all the textures available.

[Enjay]

OK, yes, fair point.

[randi]

TEXTURE1/TEXTURE2/PNAMES are additive with the new texture system, to an extent. TEXTUREx lumps will always try to reference the PNAMES lump in the same wad as them (since they are PNAMES-specific). If you have a TEXTUREx lump in a wad without a PNAMES lump, then it will use the latest PNAMES lump in a wad loaded before it. You should only have ony PNAMES, TEXTURE1, or TEXTURE2 lump per wad, but you can have more than one wad with those lumps, and all their entries will be visible in-game.

If there are duplicate texture entries, then the one defined last is the one that gets used if it is not duplicated in a single wad. If a texture entry appears more than once in a single wad, then the first definition in the last wad where that texture entry appears is used.

[Hirogen2]

This is kind of redundant to do since all you have to do is place a patch in a wad and use it whenever/whereever(once 48.cab gets out anyway *nudgenudgewinkwink Randy*).

Would still require an unnecessary PNAMES lump.

@: Yes, but in the general case (Doom2), there is _only_ TEXTURE1 (remember, ZETH doesnot understand TX2 in a Doom2 WAD), and all texture packs use TX1.

IMO my proposed idea is best and easiest

[Enjay]

Would still require an unnecessary PNAMES lump.

Maybe, maybe not. From the news thread...

You can use any texture anywhere, with one exception:

Textures used as sprites must still be within S_START/S_END markers and must follow the naming convention, because that's the only way to tell Doom what its animation frames and rotations are. For everything else, the way you define the texture doesn't matter, so a floor or wall could use any of the following source images:

• A texture defined in a TEXTURE1/TEXTURE2 lump.
• A flat between F_START/F_END markers.
• A sprite between S_START/S_END markers.
• A single patch listed in a PNAMES lump.

Now, obviously I haven't seen how this actually works in practice, but it should be possible to put graphics between suitable markers and just use them regardless of texture1/texture2/pnames entries. Especially if your new graphics are 64x64 ones that could easily be included as flats.

I suppose it may be possible to put replacement graphics between s_start/s_end entries, but if they don't follow the sprite naming convention this might cause a problem??? Would it be possible to put graphics such as MYWALL1, MYWALL2 between these markers and have them useable on walls/floors, or would I need to call them something like WALL1A0, WALL2A0 etc? And would that even work?


Edit:
Actually, if the above would not work (even if it would) how about adding support for graphics between P_start and P_end as an additional alternative to requiring a patch to be named in one of the texture/patch control lumps? I know that ATM lots of people don't use the P_ markers, but if this was implemented, then they would because it would be a nice easy way of adding a bunch of custom graphics and identifying them as suitable for walls and floors. It should be newer wads that are using this feature anyway for adding new graphics, so backward compatability reqiring those markers in older wads isn't an issue.

How does this new system work with things like animations and switches?

Edit2:
OK, just tried a few things with the latest ZdoomGL beta. If Randy and timmie have implemented this in the same way, then this will apply to Zdoom as well as ZdoomGL:

I used Randy's texturefun wad and put titlepic, interpic, bossback and starms on a wall. All of these worked without any modification to the lumps concerned or adding any markers or anything to the WAD.

STBAR did not work - I just got the noflat graphic on the wall.

I put a totally new 128x128 graphic into the WAD and put it on the wall. Again it didn't work (noflat graphic again). Next, I enclosed my graphic (called testwall) in s_start and s_end markers. It worked. I renamed the markers to p_start and p_end and again I got the noflat graphic.

Restoring the p_ markers to s_ markers, I was then able to put the testwall graphic on the floor - so it works for walls and floors (as expected).

So, assuming Zdoom and ZdoomGL do things the same, it should be possible to put graphics of any name between s_start and s_end markers and use them on the floor or wall without any additional lumps such as PNAMES listing them. Unfortunately, it seems support for P_ markers is not (yet?) included. I still think this would be a good idea for the sake of neatness as much as anything else. s_ markers are really to identify sprites and IMO this section shouldn't be cluttered up with other graphics.

I wonder why some graphics (titlepic etc) worked despite not being between any markers. Hang on....

Hmmmm, nothing to do with size. If I resize testwall to 320x200 it doesn't work without s_ markers. However, if I rename it to titlepic and leave it at 128x128 it works even without s_ markers. Have certain lump names been internally identified as suitable graphics or something?

[Cyb]

enjay: graphics like TITLEPIC, BOSSBACK et al are hard coded into the exe, they've always been that way. The doom graphic format is horribly limiting in that there's absolutly no way to be sure if something is a graphic without extensive tests and even then it still might not be a graphic. So that's why all the intermission and titlepic lumps work on walls/floors (to an extent anyway, they won't always tile properly on the floor since their dimensions not in powers of 2), their lump names are known to be graphics. Actually you can even rename a wav lump to be titlepic and it will still try to display it (prboom crashed when I tried it, but zdoom seemed to load no image, the screen was all black).

[Enjay]

OK, so those graphics only worked because the EXE already "knows" that lumps with those names are supposed to be graphics - right? Interesting that STBAR did not work, but STARMS did. I guess it "knows" one and not the other.

[Cyb]

yeah I'm not quite sure why it can't display STBAR but STARMS (and every other random graphic in the iwad it seems) displays fine. Perhaps randy can shed some light on this?

[Chris]

remember, ZETH doesnot understand TX2 in a Doom2 WAD

You should be able to add TEXTURE2 in doom2.cfg. I don't know if ZDoom will recognize it, though.

[randomlag]

Unfortunately, it seems support for P_ markers is not (yet?) included. I still think this would be a good idea for the sake of neatness as much as anything else. s_ markers are really to identify sprites and IMO this section shouldn't be cluttered up with other graphics.

If you want to separate for neatness, just add a dummy name at the end of the sprites and then add the textures.

For example add the lump name "-TEXTURE" followed by the textures you want to add. This keeps them separate and also makes it easier to explain for everyone. By the same token, you can add new sprites using the lump name "-SPRITES" followed by new sprites.

Now if one were to insist on some extra markers, then it should be NEW markers (as suggested by the topic starter). That clearly keeps it separate and easy to document.

As mentioned in my other post, the TITLEPIC, etc. bothers me a bit. It's not a good spec if exceptions creep in. As I mentioned when this was first brought up, any legit graphic could be eligible, but then that should be the spec. Doesn't matter, but let's make it so we don't have all these oddities floating about.

[IntergalacticWalrus]

enjay: graphics like TITLEPIC, BOSSBACK et al are hard coded into the exe, they've always been that way. The doom graphic format is horribly limiting in that there's absolutly no way to be sure if something is a graphic without extensive tests and even then it still might not be a graphic. So that's why all the intermission and titlepic lumps work on walls/floors (to an extent anyway, they won't always tile properly on the floor since their dimensions not in powers of 2), their lump names are known to be graphics. Actually you can even rename a wav lump to be titlepic and it will still try to display it (prboom crashed when I tried it, but zdoom seemed to load no image, the screen was all black).

Cyb is right, and I'd also add that it's not just graphics: pretty much every type of ressource in the DOOM engine has absolutely no header saying what it is. So basically any DOOM ressource, in their raw format, is completely unidentifiable just by looking at its contents. (I think MUS-format music lumps have a header, but that's about it.) The DOOM engine and wad-management programs such as WinTex "know" what a file is by having a hard-coded list of lump names and looking at stuff like PNAMES, TEXTURES and _START/_END delimiters.

Another thing worth mentionning is that flats and Heretic/Hexen screens are in a different format from every other graphic lump, so they are not mutually compatible.

BTW I agree with Hirogen2: a new set of delimiters for textures named after their lumps (as opposed to named sets of patches in TEXTURES) would be a good idea, since the TEXTURES thing is only an annoyance now that everyone just does 1-patch textures anyways.

[SargeBaldy]

i don't really see the point of doing this.. and i for one DO use multiple patches in textures and find TEXTURE1 a very nice and efficient way of adding stuff.