Texture colors super messed up when loading multiple texture packs

[Alexagon]

I cannot find an answer on google about this.

 

In my map I want to use textures from a few different texture packs I downloaded from Realm667. When I load then alongside DOOM2.wad some of the texture colors get super messed up, like random colors all over them. Same thing happens with monsters and other things. When I do this, I also get 136 errors with a bunch of "Missing patch lump...".

 

Anyone have any advice?

[Dark Pulse]

IIRC if they're oldschool Doom-style textures (i.e; using TEXTUREX lumps), you have to merge them or PATCHES lumps into one WAD in order to properly use them both, or something like that?

[Kappes Buur]

 

1 hour ago, Alexagon said:

I cannot find an answer on google about this.

 

In my map I want to use textures from a few different texture packs I downloaded from Realm667. When I load then alongside DOOM2.wad some of the texture colors get super messed up, like random colors all over them. Same thing happens with monsters and other things. When I do this, I also get 136 errors with a bunch of "Missing patch lump...".

 

Anyone have any advice?

 

Some of the texture packs from REALM667 define not only the custom patches but also the patches from DOOM2.wad. It is too bad that they did not make use of Texture2.

 

Can you tell us which game port, which mapping format and which texture packs you are using.

Meanwhile read this.

 

 

 

 

[Alexagon]

2 hours ago, Kappes Buur said:

 

 

Some of the texture packs from REALM667 define not only the custom patches but also the patches from DOOM2.wad. It is too bad that they did not make use of Texture2.

 

Can you tell us which game port, which mapping format and which texture packs you are using.

Meanwhile read this.

 

 

 

 

I'm using the Gothic, medieval, final doom, and original doom texture packs. I'm mapping with the Boom format. No source port in particular I don't think.

[Gez]

5 hours ago, Alexagon said:

When I load then alongside DOOM2.wad some of the texture colors get super messed up, like random colors all over them.

what format are the texture images in? Doom format graphics or PNG?

[Alexagon]

1 hour ago, Gez said:

what format are the texture images in? Doom format graphics or PNG?

According to the site, two of them are TEXTURE1 and the others are TEXTURE. The medieval one also says PNAMES. 

[Gez]

TEXTURE* and PNAMES do not actually contain any image data. They are not graphics. They just build textures out of other graphics, called patches in Doom jargon, and that's the patches I was talking about.

 

Specifically you have a bunch of images, then PNAMES gives each image a number, then TEXTURE1 says "use patch #X, #Y, #Z to make texture T".

[Alexagon]

12 hours ago, Gez said:

TEXTURE* and PNAMES do not actually contain any image data. They are not graphics. They just build textures out of other graphics, called patches in Doom jargon, and that's the patches I was talking about.

 

Specifically you have a bunch of images, then PNAMES gives each image a number, then TEXTURE1 says "use patch #X, #Y, #Z to make texture T".

How can I find out what graphic format they are? Open it up in slade? 

[Kappes Buur]

17 hours ago, Alexagon said:

No source port in particular I don't think.

 

That makes all the difference.

 

In source ports aiming for true old Doom conformity, such as Choco or PrBoom+, TEXTURE1 lumps are not cumulative, meaning that only the last loaded TEXTURE1 lump will be used.

 

In advanced source, such as GZDoom, they are cumulative, so that all TEXTURE1 lumps are used.

 

Making matters worse, the Final Doom texture pack, tnttextures.wad, is structured with TEXTURES, which is a GZDoom lump and not at all supported by vanilla Doom ports.

[Kappes Buur]

22 minutes ago, Alexagon said:

How can I find out what graphic format they are? Open it up in slade? 

 

Instead of asking a question like that it would have taken you literally 5 secs to load the texture pack into Slade3 and you would have had the answers right there.

[Alexagon]

6 minutes ago, Kappes Buur said:

 

That makes all the difference.

 

In source ports aiming for true old Doom conformity, such as Choco or PrBoom+, TEXTURE1 lumps are not cumulative, meaning that only the last loaded TEXTURE1 lump will be used.

 

In advanced source, such as GZDoom, they are cumulative, so that all TEXTURE1 lumps are used.

 

Making matters worse, the Final Doom texture pack, tnttextures.wad, is structured with TEXTURES, which is a GZDoom lump and not at all supported by vanilla Doom ports.

I'm still extremely new to doom mapping. When I load the map, I select Boom format. I load the game with gzdoom just because that's what I play with. I am using gzdoom builder, so maybe it's gzdoom? I genuinely am not sure. 

[Alexagon]

4 minutes ago, Kappes Buur said:

 

Instead of asking a question like that it would have taken you literally 5 secs to load the texture pack into Slade3 and you would have had the answers right there.

I'm not even remotely close to my computer right now, so I don't have access to that. There's no need for you to be rude about it. 

[Kappes Buur]

1 minute ago, Alexagon said:

I'm not even remotely close to my computer right now, so I don't have access to that. There's no need for you to be rude about it. 

 

That was not rude, it was blunt.

 

[Kappes Buur]

In a post above I linked to this page

https://zdoom.org/wiki/TEXTUREx

which explains the situation with TEXTURE1 and TEXTURES. It is worth a read.

The WIKI is your friend ™

 

I loaded the three, four if you count the DOOM2 textures, texture packs into the editor

with a quick test map

 

 

All textures are perfectly usable, except for Yarrow (which is undefined in MLCETEX.WAD)

 

 

 

When opened with GZDoom, a potpourri of textures

 

 

 

 

 

[Alexagon]

9 minutes ago, Kappes Buur said:

In a post above I linked to this page

https://zdoom.org/wiki/TEXTUREx

which explains the situation with TEXTURE1 and TEXTURES. It is worth a read.

The WIKI is your friend ™

 

I loaded the three, four if you count the DOOM2 textures, texture packs into the editor

with a quick test map

 

 

All textures are perfectly usable, except for Yarrow (which is undefined in MLCETEX.WAD)

 

 

 

When opened with GZDoom, a potpourri of textures

 

 

 

 

 

Alright. I looked at the wiki page. Not gonna lie, it's not helping me understand much. Like I said, I'm extremely new to all this so I don't really understand the environment and language associated with all of this yet. Like I'm not sure what I need to do to get it to work. What did you do differently? 

 

Pretend I'm a 5 year old trying to get into doom editing. 

[Doomkid]

If you look at each different texture resource wad in SLADE, all the actual images that the textures are composed of will be in there. Some very oldschool texture resources construct textures from multiple images, but MOST do not.

 

What this essentially boils down to: To avoid conflicts between packs, you should peruse all the texture images in each one - the images will usually be between P_START and P_END lumps if it was competently made - and pluck each one you actually want to use out and paste them into your own “new” texture wad.

 

Once you have all the texture images you want, put a P_START and P_END marker surrounding all of them. Then, select all the images (but not the markers), right click them, and “add to patch names/pnames”, then “add to TEXTURE1”.

 

What this is doing is making sure all of the textures you actually want are in one easy wad with just one TEXTURE1 lump (which slade auto-generates when you follow my instructions above). Since all the different packs had their own TEXTURE1 lumps (with some variations) it was causing issues because, as Kappes Buur said, only one of those TEXTURE1 lumps was being read, and that’s the lump which tells the engine “hey, use this image, which is defined in PNAMES”. What that boils down to is, all the textures from disparate packs pretty much can’t be unanimously loaded because most textures will “lose” their definitions as a result.

 

Any trouble, just let me know.

[Kappes Buur]

1 hour ago, Alexagon said:

 

Pretend I'm a 5 year old trying to get into doom editing. 

 

I'll try.

My first advice would be to take it slow and easy and learn this one little step at a time.

Consult the WIKI often.

 

 

I reread an earlier post of yours about which texture packs you are using. I assumed it was MLCETEX.WAD when you probably meant MEDIVLTX.WAD.

 

Now, MEDIVLTX.WAD is a different texture pack in that it uses its own PLAYPAL, which IS quite different from the standard PLAYPAL of DOOM2.WAD

 

 

Hence you saw some messed up looking textures.

 

Since you are using GZDoom this can be remedied quite easily when using Slade3.

GZDoom, while compatible with it, does not need the TEXTURE1/2 and PNAMES lumps, to display textures. Textures can be placed between TX_ markers (TX_START and TX_END) and they can be png images. And they can be placed on walls as well as floors/ceilings.

 

All you would have to do is to highlight all images and then rightclick to select Graphics - Export to PNG tosave the images as png in a specific folder.

 

I have made a tutorial doing that kind of transformation with Eviternity's OTEX textures. Maybe that will be of help.

[Alexagon]

I appreciate the help, guys. I got the texture packs aside from the medieval one to work properly.

[Doomkid]

If you actually want to use those as well despite their different palette, you can export all the medieval patches as PNGs, then import them back into your own texture wad, select them all, right click and "convert to Doom image format". This will result in them looking kind of low-quality, as they want colors that go beyond the range of Doom's palette, but the benefit of this approach is cross-port compat. If you only care about GZDoom compat however, Kappes Buur's method is absolutely preferable.

[Kappes Buur]

2 hours ago, Alexagon said:

I am using gzdoom builder, 

 

GZDoom Builder is no longer maintained and since then bugfixes have been resolved and mapping gizmos added. Therefore I would suggest using Ultimate Doom Builder r3447 if for nothing else the improved 3D Preview Mode.

See the thread on ZDoom forum.

 

See my tutorial about starting out to map.

[Alexagon]

7 minutes ago, Kappes Buur said:

 

GZDoom Builder is no longer maintained and since then bugfixes have been resolved and mapping gizmos added. Therefore I would suggest using Ultimate Doom Builder r3447 if for nothing else the improved 3D Preview Mode.

See the thread on ZDoom forum.

 

See my tutorial about starting out to map.

Can I just use my existing map in UDB without having anything mess up?

[Kappes Buur]

1 minute ago, Alexagon said:

Can I just use my existing map in UDB without having anything mess up?

 

Of course.

UDB is just the latest iteration of GZDB, just with a new name.

[Gez]

3 hours ago, Alexagon said:

I appreciate the help, guys. I got the texture packs aside from the medieval one to work properly.

The medieval texture pack is for Heretic, so it's in the Heretic palette, which is very different from the Doom palette. When loaded with the Doom palette, the colors will not correspond to what the image intended.

 

You can select all the medieval patches and convert them to PNG, so they'll work in GZDoom (and other PNG-compatible ports) just fine. Or you can convert them to the Doom palette, which will cause some color degradation but will make them work also in other Boom-compatible ports that do not handle PNG graphics.

 

To do the latter, it's just like the former: you use the "convert to" option, but you keep it in "Doom Gfx" format (or "Doom Flat" for the flats; which are textures that go on floors and ceilings instead of on walls). However, look at the palette drop-downs: select "Heretic" for the "current graphic" box, and "Doom" for the "converted graphic" box. In some cases it'll work fine if both palettes have colors that are sufficiently close. E.g., for this patch the differences are subtle enough that you can barely tell.

 

For others it can be more drastic, like this olive green getting slightly more orange, and the stain and wear patterns becoming starker:

 

And when there's no close-enough colors in the destination palette, the result can be truly disappointing, like this desaturated blue just turning gray:

 

I'll also note in passing that, since Medieval Textures is meant for Heretic, the textures it contains are there to complement the base Heretic resources, which you won't have in Doom, so it'll have kind of gaps in the texture themes it offers.

[Alexagon]

Do you guys know where I can find the switch texture that looks like a sideways chain pulley? I'm not sure how else to describe it.

[Kappes Buur]

On 5/29/2020 at 4:02 AM, Alexagon said:

Do you guys know where I can find the switch texture that looks like a sideways chain pulley? I'm not sure how else to describe it.

 

Is that the one you are looking for?

 

 

GuildNavigator used it extensively in his pwad as a switch, activated  with scripting

 

 

 

Edited May 30, 2020 by Kappes Buur

[Alexagon]

13 hours ago, Kappes Buur said:

 

Is that the one you are looking for?

 

 

GuildNavigator used it extensively in his pwad as a switch, activated  with scripting

 

 

 

No, not that one. It's a flat square texture, and it has a bar with a sideways chain and goes left to right. I remember seeing it in a level in Sunlust and a whole bunch of other wads.

[NiGHTMARE]

That sounds like one of the Hexen switches.

[Alexagon]

I opened the wad for Sunlust and found it there. I dragged it into another texture wad i'm using but now it's not showing up at all in the editor.

 

EDIT: It's actually there, but as a severely warped floor texture. Not sure how to get it to work properly.

[Gez]

1 hour ago, NiGHTMARE said:

That sounds like one of the Hexen switches.

Yeah. W_339 to W_343 in hexen.wad. Texture names SW_OL1 to SW_OL5. In Hexen you get an animated transition in five steps, in Sunlust since they've changed it to Doom-style there's only on and off.

 

1 hour ago, Alexagon said:

EDIT: It's actually there, but as a severely warped floor texture. Not sure how to get it to work properly.

As already alluded to, there are two different (and incompatible) texture formats in Doom:

 

-flats are square images (64x64 pixels) that are displayed on floors and ceilings. These graphics are written just as a bunch of 4096 palette indices, and as long as a lump is at least 4096 bytes in length, the engine can technically use it as a flat (that doesn't mean it'll look good though). There are three things to know about flats:

• They should be in the flat namespace (between F_START and F_END). There's a subtlety about what this means exactly given the way Doom loads multiple archives, but I'm gonna slide over this for the time being.
• They are row-major, meaning that pixels are described from left to right first, and from top to bottom second: the first 64 bytes are the first row of pixels, the next 64 bytes after that are the second row, and so on.
• They do not have any metadata or format info: every single of the 4096 bytes in the lump is graphic data. (Bytes after the 4096th are simply ignored; they're not supposed to be there. (Except in Heretic and Hexen for scrolling flats but let's ignore that since it's not relevant to Doom ports.))

- wall textures are made out of patches, given an index number in PNAMES, and composited together in the TEXTUREx lumps. Things that you should know if you want to use textures:

• The patches are in a format completely different from the flats: they're column-major (describing the image pixels from top to bottom first, and from left to right second, covering a column and then the next column. Columns are themselves split into posts, which is an uninterrupted run of pixels. There can be gaps between two posts, and this is how transparency is handled.
• The patch format is not fixed-size like the flats, so it contains metadata indicating the image width and height, the number of posts for each column (note: a column can have zero posts, making it fully transparent from top to bottom), and the start offset and length of a post.
• a single texture can be made of several patches. Patches need to cover the entire length of the texture, though -- you can't make a transparent texture by having a gap between patches, it's up to the patches to provide transparency.

So what happens if you have a texture patch, and the game reads it as a flat? Well first, since they're not read in the same direction, the "flat" will be mirrored and rotated compared to the patch. Secondly, since flats are always 64x64, if the patch does not match these dimensions, the image will get warped diagonally. Finally, since the flat reads every single byte as being pixel data, the patch's metadata (width, height, column and post info) will be read as pixels too.

 

How to fix it? Well, put the image in the patch namespace, add it to the patch table (PNAMES), and define the texture from that patch using the texture editor.

[Alexagon]

16 hours ago, Gez said:

Yeah. W_339 to W_343 in hexen.wad. Texture names SW_OL1 to SW_OL5. In Hexen you get an animated transition in five steps, in Sunlust since they've changed it to Doom-style there's only on and off.

 

As already alluded to, there are two different (and incompatible) texture formats in Doom:

 

-flats are square images (64x64 pixels) that are displayed on floors and ceilings. These graphics are written just as a bunch of 4096 palette indices, and as long as a lump is at least 4096 bytes in length, the engine can technically use it as a flat (that doesn't mean it'll look good though). There are three things to know about flats:

• They should be in the flat namespace (between F_START and F_END). There's a subtlety about what this means exactly given the way Doom loads multiple archives, but I'm gonna slide over this for the time being.
• They are row-major, meaning that pixels are described from left to right first, and from top to bottom second: the first 64 bytes are the first row of pixels, the next 64 bytes after that are the second row, and so on.
• They do not have any metadata or format info: every single of the 4096 bytes in the lump is graphic data. (Bytes after the 4096th are simply ignored; they're not supposed to be there. (Except in Heretic and Hexen for scrolling flats but let's ignore that since it's not relevant to Doom ports.))

- wall textures are made out of patches, given an index number in PNAMES, and composited together in the TEXTUREx lumps. Things that you should know if you want to use textures:

• The patches are in a format completely different from the flats: they're column-major (describing the image pixels from top to bottom first, and from left to right second, covering a column and then the next column. Columns are themselves split into posts, which is an uninterrupted run of pixels. There can be gaps between two posts, and this is how transparency is handled.
• The patch format is not fixed-size like the flats, so it contains metadata indicating the image width and height, the number of posts for each column (note: a column can have zero posts, making it fully transparent from top to bottom), and the start offset and length of a post.
• a single texture can be made of several patches. Patches need to cover the entire length of the texture, though -- you can't make a transparent texture by having a gap between patches, it's up to the patches to provide transparency.

So what happens if you have a texture patch, and the game reads it as a flat? Well first, since they're not read in the same direction, the "flat" will be mirrored and rotated compared to the patch. Secondly, since flats are always 64x64, if the patch does not match these dimensions, the image will get warped diagonally. Finally, since the flat reads every single byte as being pixel data, the patch's metadata (width, height, column and post info) will be read as pixels too.

 

How to fix it? Well, put the image in the patch namespace, add it to the patch table (PNAMES), and define the texture from that patch using the texture editor.

Well I tried what you said, and I'm not really getting it. Is the patch namespace the files in between the PP_START and end markers? If so I put it there. When I try to add the switches to the PNAMES table, it says I shouldn't do it without using the texture editor, so I go to that, make a new patch, then try to add the switch textures to the patch but they're not there.

 

I have no clue what to do.