Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • 0
NiTROACTiVE

Regarding Texture Widths and Heights for Vanilla Doom

Question

I have a question to ask when it comes to custom textures for a vanilla Doom WAD.

 

Is there a limit on how tall or wide a texture can be for a vanilla Doom WAD? I'm aware that textures should at least be 128 pixels high to avoid the Tutti-frutti effect, but let's say I wanted to add a texture that was at least 256 px by 256 px, or even 768 px by 384 px. Would vanilla Doom, which would include the original MS-DOS Doom and Chocolate Doom, be able to support textures of those dimensions?

Share this post


Link to post

20 answers to this question

Recommended Posts

  • 1

In situations like these, I feel the easiest way to find out is trying it out for myself and seeing what happens. So I spliced together the existing Icon of Sin textures in two different ways:

 

1. making three 256x384 textures comprised of the original 128x256 patches

2. making three 256x384 textures that use new, large 256x384 patches

 

Immediately I ran into an error getting Chocolate Doom to load the level though, with the following crash message:

 

image.png

This was coming from the multi-patch textures, so I changed their dimensions to 128x384 and made 3 more textures to cover the whole Icon of Sin.
After making that adjustment, Chocolated Doom didn't crash immediately on opening the map, and this was the result:

Spoiler

image.png

The middle Icon of Sin is made using the conventional/"id-approved" method of 9 textures and displays just fine; the left-most one is made using the three large 256x384 textures made from a single large patch each, and the right-most one is made using six 128x384 textures made out of the original patches.

 

Single patch tall textures:

image.png

 

Multi-patch tall textures:

image.png

 

tl;dr Chocolate Doom does not seem to like textures that are more than 128 pixels tall.

 

Attached is my WAD with the redone textures and sample map if you're curious: tall_icon_of_sin_textures.zip

Share this post


Link to post
  • 1

Look at the icon of sin for guidance on how to do tall textures, you will want to make basically a very thin staircase at 128px height increments per step. It limits the use if you are keeping visplanes, etc in consideration, but it lets you give the impression of larger textures.

You can almost certainly use textures with a width of powers of 2, up to at least 1024 (a lot of custom skies are this way). Patches may be limited to 256x128, that's the biggest size that exists in any IWAD. Some of the patches are taller than 128 (the patch for doorstop and some of the SHAWN textures, iirc, though this may only be in the alpha wads, i do not remember) but they are cut to 128 px height by the texture dimensions.

To sum up, Textures for vanilla can be 2, 4, 8, 16, 32, 64, 128, 256, 512,  and at least 1024 px wide, and can be up to 128 px tall. I would keep patches limited to 256x128 to be safe. If you make a texture not a power of 2, for example, I was making a vanilla level with Doom alpha resources that used a texture defnied as 96x96px, it will render like the next smallest increment, in this case, as 64x96px. Heights can be any arbitrary value but are subject to the tuttifrutti bug.

Share this post


Link to post
  • 1

^ good post!

 

128 units is max height for textures in vanilla doom. Doom II map 30 should be the perfect example why, there would be no point in dividing the left/right sections of the zzzfaceX textures if textures could be higher than 128. Width, I don't know if has any limits - but don't think I've ever seen a texture bigger than 128x256 in vanilla doom - and of course, a texture with those dimensions consists of 4 patches measuring 128x256.

Share this post


Link to post
  • 0

It's multiples of 128, so 128, 256, 384 and so on. 512 is I believe the maximum dimension of a patch, but a texture assembled from patches can be 1024x1024.

Share this post


Link to post
  • 0
15 minutes ago, Edward850 said:

It's multiples of 128, so 128, 256, 384 and so on. 512 is I believe the maximum dimension of a patch, but a texture assembled from patches can be 1024x1024.

 

I'm guessing this is a typo but unless I am very mistaken, textures in vanilla doom can only be 128 highx1024 wide, not 1024x1024.

Share this post


Link to post
  • 0
25 minutes ago, Kyka said:

I'm guessing this is a typo but unless I am very mistaken, textures in vanilla doom can only be 128 highx1024 wide, not 1024x1024.

There's no restriction on a 128 unit height as far as I know. and the Wiki page even talks about this.

Share this post


Link to post
  • 0

I've always heard the height must be exactly 128 if the texture is to be tiled, but it can be less if the surface that is textured doesn't exceed 128 pixels in height. I can't remember seeing a wad that doesn't adhere to this unless it's for more advanced source ports and even then it seems rare. In map 30 of Doom II you'll see that the IOS has small ledges so that it can be composed of textures not exceeding the 128 height limit. At least the original team treated 128 as the maximum height.

Share this post


Link to post
  • 0

Vanilla doom will assume every texture is 128 units tall, which means it will fill screen with junk data if it is shorter and tiles, or offset; and will cut it if it's taller.

It also needs width that is a power of 2 - and unlike height it's actually not fixed in most ports. It can handle textures at least up to 1024 units wide, but might not be able to handle patches that is more than 256 units, but I'm not 100% sure - just assuming because longer textures are often split.

Share this post


Link to post
  • 0

Thanks for the answers guys, and according to @TheHambourgeois, @Uncle 80, and @SMG_Man, looks like I would have to find a workaround for textures higher than 128 pixels.

 

I do have one last question. Just to be sure, the 128 pixel height limit also applies to patches in the PNames lump, and not just the textures in the TEXTURE1 lump, correct?

Share this post


Link to post
  • 0

iirc and remember my testing right. 128+ height texture can be stored in the wad file, but it never be rendered higher than 128.So there is simply no reason to include them. Same goes with patches lump, you can make higher textures with patches, but it will render only what comes to 128. You can make 2x 128 height texutre with seamless divide in the middle, apply upper part at upper sector wall and lower to the lower sector wall and "Seal" them.That way you can have 256 height texture wall. I still testing but i think sealed sectors did not increase vis count

Edited by INfront95

Share this post


Link to post
  • 0
15 hours ago, NiTROACTiVE said:

Thanks for the answers guys, and according to @TheHambourgeois, @Uncle 80, and @SMG_Man, looks like I would have to find a workaround for textures higher than 128 pixels.

 

I do have one last question. Just to be sure, the 128 pixel height limit also applies to patches in the PNames lump, and not just the textures in the TEXTURE1 lump, correct?

 

IIRC, there's actually a patch in Udoom that's 144 px tall. But like everybody has already stated, those 16 extra pixels are never drawn in-game. (Said texture is also 128x128 in the texture lump. Can't remember exactly which one it was, think it was one of the Doom(1) only grays....)

 

12 hours ago, INfront95 said:

You can make 2x 128 height texutre with seamless divide in the middle, apply upper part at upper sector wall and lower to the lower sector wall and "Seal" them.That way you can have 256 height texture wall. I still testing but i think sealed sectors did not increase vis count

 

 

Yep, this is a good workaround, I've also been using this method in a couple of recent maps where I needed 2 different textures on a wall length. And as you say, I don't think it affects Visplanes. Drawsegs is another story though, considering the "invisible" lines behind said 0-level sector is also "rendered" in the scene.

Edited by Uncle 80

Share this post


Link to post
  • 0
5 hours ago, Uncle 80 said:

 

Yep, this is a good workaround, I've also been using this method in a couple of recent maps where I needed 2 different textures on a wall length. And as you say, I don't think it affects Visplanes. Drawsegs is another story though, considering the "invisible" lines behind said 0-level sector is also "rendered" in the scene.


I started using "triangle pattern" instead of square in sealed sectors, 1 line and 1 vert less in the renderer. But again, it works with concave walls where useless geometry is outside of the map. Ah and width can be 256 (Heretic had one texture) never tried doing more than that. So.... in the end we have 256w+128h visual texture in vanilla. Gzdoom can do 512+512 that i tested and sure.

Edited by INfront95

Share this post


Link to post
  • 0

Using 'oversized' patches is a way you can save space. You can have a patch that is 192 pixels tall. Then you make one texture that uses the top 128 pixels and one the bottom 128 pixels. You could also have it as multiple patches, one 128 tall and one 64 tall, but that would "break" if you needed them as normal textures on a two-sided wall. You could of course make it into 2x128 tall patches, but that would duplicate a strip of 64 height pixels.

You could also have a large "background noise" patch and overlay other smaller patches on top of it and make many different textures that do not have identical 'background' pixels. Having just one background texture would make it easier to edit and change the texture.

There are definitely reasonable use cases for oversized patches.

Update: Esselfortium says this doesn't work in vanilla doom. However in doom2.wad this trick is used on several textures.

BROWN144: 1xWALL00_7 has an offset of -1, 1xWALL00_6 has an offset of -16.
GRAY2: W33_7 has an offset of -8.
GRAY4: W33_7 has an offset of -8.
GRAYVINE: 2xWALL00_1 has offsets of -16.

The WALL00_1 patch is 144 pixels tall and the top 128 pixels are used twice and the bottom 128 pixels are used twice to make the background for the vines.

If this is broken, that would mean that these textures display differently in the editor than in the game. That sucks :( I never noticed myself :D

Edited by zokum

Share this post


Link to post
  • 0
4 minutes ago, zokum said:

Using 'oversized' patches is a way you can save space. You can have a patch that is 192 pixels tall. Then you make one texture that uses the top 128 pixels and one the bottom 128 pixels. You could also have it as multiple patches, one 128 tall and one 64 tall, but that would "break" if you needed them as normal textures on a two-sided wall. You could of course make it into 2x128 tall patches, but that would duplicate a strip of 64 height pixels.

You could also have a large "background noise" patch and overlay other smaller patches on top of it and make many different textures that do not have identical 'background' pixels. Having just one background texture would make it easier to edit and change the texture.

There are definitely reasonable use cases for oversized patches.

Vanilla clamps negative y-offsets on patches to 0, so this doesn’t work, unfortunately.

Share this post


Link to post
  • 0
1 minute ago, esselfortium said:

Vanilla clamps negative y-offsets on patches to 0, so this doesn’t work, unfortunately.

Oh really? I didn't know! I have never experimented much with this. Then I'm corrected. I wonder why they did this and if they do it in all versions of the game.

Share this post


Link to post
  • 0
13 minutes ago, zokum said:

Oh really? I didn't know! I have never experimented much with this. Then I'm corrected. I wonder why they did this and if they do it in all versions of the game.

It’s a bug, there are a few textures that attempt to use negative y patch offsets and display weirdly as a result. Most of them it’s not super obvious though, which is probably how it avoided their notice.

Share this post


Link to post
  • 0

While you can have textures that are taller than 128 pixels, they will not work correctly in vanilla. The renderer is hardcoded to tile textures at the 128 point, it's just how it works. If the texture is shorter, then you get tutti frutti. If the texture is taller, you just don't get to see anything below the top 128 rows.

 

Sprites and full-screen graphics are a different issue. They can be taller than 128, but you still need to have them split up internally at the 128th row otherwise it'll tile. This can be seen in the Final Doom SSG: https://doomwiki.org/wiki/Shotgun_sprite_wraps_vertically_in_Final_Doom

 

28 minutes ago, zokum said:

Oh really? I didn't know! I have never experimented much with this. Then I'm corrected. I wonder why they did this and if they do it in all versions of the game.

Cf. https://doomwiki.org/wiki/Vertical_offsets_are_ignored_in_texture_patches

 

Edit: found back my post with the list of all affected textures in the official IWADs:

 

Edited by Gez

Share this post


Link to post
  • 0

Gez: We were talking about textures not taller than 128. One could use the same patch with different offsets to create different textures that have some of the same pixel data. The patch WALL00_1 is 64x144 and is used for this purpose in GRAYVINE.

slade.png

Share this post


Link to post
  • 0
11 minutes ago, zokum said:

Gez: We were talking about textures not taller than 128. One could use the same patch with different offsets to create different textures that have some of the same pixel data. The patch WALL00_1 is 64x144 and is used for this purpose in GRAYVINE.

slade.png

GRAYVINE is bugged, though, just like every other texture that uses negative offsets.

jfpcIrI.gif

This gif alternates between how it appears in editor and how it appears in vanilla.

Another example of the phenomenon:

SbtrZyq.gif

Pay attention to the round thing at the bottom. Then go take a look at this post:

https://www.doomworld.com/forum/post/2275140

The image embeds are dead unfortunately, but the gist is that the texture was carefully aligned to make the round detail the mouth of a cannon, except that of course once you go into the game, the round thing is pushed down and cut off and your Doomcute cannon is broken beyond repair.

 

This thing about accessing the pixels beyond the first 128 rows is a nice idea and it was most certainly what the texture designers intended -- but it just doesn't work.

Share this post


Link to post
  • 0
On 2/2/2023 at 12:49 AM, esselfortium said:

Most of them it’s not super obvious though, which is probably how it avoided their notice.

 

The bug also makes some textures work correctly in the first place, like doom.wad's BIGDOOR7 (it's fixed in doom2.wad).

 

 

On 2/2/2023 at 12:26 AM, zokum said:

If this is broken, that would mean that these textures display differently in the editor than in the game. That sucks :( I never noticed myself :D

 

On 2/2/2023 at 1:14 AM, Gez said:

This gif alternates between how it appears in editor and how it appears in vanilla.

 

UDB emulates the bug, so the textures look in-editor like they do in-game (except in the configurations for ports that fixed the bug, i.e. the ZDoom family and Eternity Engine).

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×