Texture/patch limits in vanilla doom

So I am doing some work on the TNT2 texture pack, and I just wanted to ask about various vanilla limits with regards to putting together a texture pack.

For example, I know from the Doom wiki that a texture can be no more than 128 units high, but there is no horizontal limit. Is the same true for patches, as well as textures, or do patches have a horizontal size limit?
-Is it better to combine, say, 4 patches into a single patch via GIMP, and have textures that are composed of only one patch, or have multiple smaller patches which are combined to form multi patch textures? (So bigger patch sizes vs more patches in each texture?)

-Is there any limit to the number of patches I can have present and listed in the PNAMES lump?
-Is there any limit to the number of textures I can create in the TEXTURE1 lump?
-Is there any limit to the number of FLATS that I can have?
-Is there any limit to the number of patches that I could theoretically place in a single texture?
-How would I create new animated textures, or am I limited to the ones defined in TNT itself?

-Any other limits/things that I should take into consideration when creating a vanilla texture pack?

Thanks guys. :)

What engine are you using ?

KiiiYiiiKiiiA said:

blah blah vanilla blah blah vanilla blah vanilla blah?

There's no limit to the number of textures, patches, or flats you can have.

There is a limit to the number of patches you can place in a single texture, but I'm not sure what it is. I believe this limit is a holdover from the earlier days of Doom's development, before it became 32-bit, or something to that effect.

You can't create new animations, but you can replace the existing ones with animations that use however many frames you want, by placing however many textures you like (their names being irrelevant, only the order they're placed in mattering) in between the first and last frame in the texture1 list or in the flats list.

This is used in both TNT and Plutonia to replace some of Doom's animations with custom ones. In TNT, some switch textures were also placed in between animation start/end frames, to create the animated flaming skull brick switch thingys.

You can also take advantage of the ability to use wide textures, by arranging multiple animations in the same texture and using x-alignment to choose between them in your maps. I think TNT used this, as well.

As far as other things to consider, remember that any texture that isn't exactly 128 units tall will not be able to tile vertically in vanilla. In KDiKDiZD, I created 128-tall tiled duplicates of all the step textures to avoid tutti-frutti problems with them in cases where tiling or abnormal y-alignment was needed.

esselfortium said:

You can also take advantage of the ability to use wide textures, by arranging multiple animations in the same texture and using x-alignment to choose between them in your maps. I think TNT used this, as well.

And Icarus, to striking effect. Look, it's a waterfall! Move the X-offsets over far enough, and you've got some windmills! :)

In KDiKDiZD, I created 128-tall tiled duplicates of all the step textures to avoid tutti-frutti problems with them in cases where tiling or abnormal y-alignment was needed.

What exactly was the point of that? There's no tutti-frutti error in ZDoom. Unless a project called KDiKDiZD inexplicably doesn't use ZDoom as its primary platform.

Megamur said:

What exactly was the point of that? There's no tutti-frutti error in ZDoom. Unless a project called KDiKDiZD inexplicably doesn't use ZDoom as its primary platform.

It's for DOOM2.EXE, yo.

What an insanely confusing title. I request a patch solely to make the mod have a more sensible name.

Megamur said:

What exactly was the point of that? There's no tutti-frutti error in ZDoom. Unless a project called KDiKDiZD inexplicably doesn't use ZDoom as its primary platform.

It doesn't.

Knee Deep in Knee Deep in ZDoom is a project with the goal of converting Knee Deep in ZDoom into a 100% vanilla compatible WAD.

esselfortium said:

There is a limit to the number of patches you can place in a single texture, but I'm not sure what it is. I believe this limit is a holdover from the earlier days of Doom's development, before it became 32-bit, or something to that effect.

Not on the number of patches, but on their combined size. If the composite texture exceeds 64KB, the game will exit with an error message. There is absolutely NO technical reason for this exit, leading me to believe it must somehow be a left-over from VERY early (DOOM 0.2 alpha or before, maybe even from one of Carmack's experimental predecessor engines) - because a hallmark characteristic of DOS real mode is that segments are limited to 64KB. But DOOM doesn't run in real mode...

There is another similar bizarro code segment in the engine which is related to loading of the COLORMAP lump - it will be aligned to a 64K boundary for no apparent reason.

Megamur said:

What an insanely confusing title. I request a patch solely to make the mod have a more sensible name.

Megamur I don't think you "get" kdikdizd

Quasar said:

If the composite texture exceeds 64KB, the game will exit with an error message.

then how TNT's skies can exist? they are 1024*128=128 kb

tempun said:

then how TNT's skies can exist? they are 1024*128=128 kb

Are they single-patch textures? Because single-patch textures are not subject to this limitation. It is only for composite textures, meaning ones made of multiple patch graphics.

if (patchcount[x] > 1)
{
   // Use the cached block.
   collump[x] = -1;	
   colofs[x] = texturecompositesize[texnum];    
     
   if (texturecompositesize[texnum] > 0x10000-texture->height)
   {
      I_Error ("R_GenerateLookup: texture %i is >64k",
               texnum);
   }    

   texturecompositesize[texnum] += texture->height;
}

Quasar: They're 1024x128 textures made of four 256x128 patches.

if (patchcount[x] > 1)

I think you need something like that:

           x  y    w
patch#1:   0  0  256
patch#2: 256  0  256
patch#3: 512  0  256
patch#4: 768  0  256
patch#5:   0  0  256
patch#6: 256  0  256
patch#7: 512  0  256

256*128*3 (patches 1/2/3/5/6/7) > 65536

I think that code isn't doing exactly what I thought it was doing before after looking at your explanation. Only now it seems even MORE bizarre and less explicable.

Quasar said:

now it seems even MORE bizarre and less explicable.

Probably that's because it crashes somewhere earlier.

(0 0)+(256 0)+(512 0)+(0 0)+(256 0)+(768 0) = (256+256)*128 = 65536-> works fine

(0 0)+(256 0)+(512 0)+(0 0)+(256 0)+(767 0) = (256+256+1)*128 = 65664 > 65536 -> crash

KiiiYiiiKiiiA said:

-Is there any limit to the number of patches I can have present and listed in the PNAMES lump?
-Is there any limit to the number of textures I can create in the TEXTURE1 lump?
-Is there any limit to the number of FLATS that I can have?

WISE FWOM YOUR GWAVE

I just noticed this https://github.com/id-Software/DOOM/blob/77735c3ff0772609e9c8d29e3ce2ab42ff54d20b/linuxdoom-1.10/r_data.c#L451

int* patchlookup;

[...]

names = W_CacheLumpName ("PNAMES", PU_STATIC);
nummappatches = LONG ( *((int *)names) );
patchlookup = alloca (nummappatches*sizeof(*patchlookup));

As detailed in http://www.doomworld.com/vb/source-ports/57163-surprising-strict-limit-on-pwad-size-in-vanilla-doom/, alloca() is a nonstandard function that allocates memory directly on the stack, and Doom's Watcom compiler had a 64-KB stack. So doesn't that mean there's a hard vanilla limit of 65536 / 4 = 16384ish patches?

(And yes, I know that the thread I just linked shows there's a limit of 4046ish lumps per WAD, but I'm pretty sure you could theoretically have, like, 5 texture PWADs where the PNAMES lump contains information about all the patch lumps spread across all the WADs.)

(also there's this code:

flatpresent = alloca(numflats)
[...]
texturepresent = alloca(numtextures);
[...]
spritepresent = alloca(numsprites);

which suggests a hard limit of 65536ish textures, flats, and sprites, although that's somewhat more theoretical.)

(Also re: wide skies, patchcount[x] in that context is referring to the amount of patches per column, not the amount of patches used in the texture overall. So as long as each column of the wide sky is only a single patch, it's fine.)

This is interesting, looking at DooM's source code you can learn the basics of computer science. It makes sense for the game to crash when any patch has a total amount of bits that exceeds 65536 (2^16) simply because DOS is a 16-bit operating system.

https://en.wikipedia.org/?title=DOS

"IBM PC DOS (and the separately sold MS-DOS) and its predecessor, 86-DOS, resembled Digital Research's CP/M—the dominant disk operating system for 8-bit Intel 8080 and Zilog Z80 based microcomputers. DOS instead ran on Intel 8086 16-bit processors"

Anyway:

(Also re: wide skies, patchcount[x] in that context is referring to the amount of patches per column, not the amount of patches used in the texture overall. So as long as each column of the wide sky is only a single patch, it's fine.)

What if the patches themselves were greater than 512x128 = 65536 bits?

For example, the STRAIN Episode 3 sky texture is composed of 4 different sky patches that are 256x128 each adding up to 1024x128 bits. What if the composite texture was just 1024x128. Would DOS DooM then crash?

esselfortium said:

In KDiKDiZD, I created 128-tall tiled duplicates of all the step textures to avoid tutti-frutti problems with them in cases where tiling or abnormal y-alignment was needed.

SHOW ME THIS KDiKDiZD :) (at one time, it was my most-anticipated wad). Do give!

kb1 said:

SHOW ME THIS KDiKDiZD :) (at one time, it was my most-anticipated wad). Do give!

Haha, wow, this is an old thread.

To be totally honest, if I was going to start work on KDiKDiZD again, I'd probably completely redo the majority of the existing work on it. As-is, it's a not-really-releasable mess of half-finished brokenness. I didn't really know what I was doing back then, and I ended working myself into a lot of corners.

The project is definitely still feasible and I have interest in it, although I'm not currently working on it -- with the experience gained from working on BTSX (and from the mistakes made in KDiKDiZD's first go-around) it'd probably go a lot better. I just don't have the time and creative energy to do all the projects I'd like to! Maybe someday.

Linguica said:

(And yes, I know that the thread I just linked shows there's a limit of 4046ish lumps per WAD, but I'm pretty sure you could theoretically have, like, 5 texture PWADs where the PNAMES lump contains information about all the patch lumps spread across all the WADs.)

Or you can have 16K+ clones of the same texture made from the same patch...

Baphomet_15 said:

This is interesting, looking at DooM's source code you can learn the basics of computer science. It makes sense for the game to crash when any patch has a total amount of bits that exceeds 65536 (2^16) simply because DOS is a 16-bit operating system.

Doom did not run directly on DOS, though. It used a "DOS extender" (the famous DOS/4GW) to go into 32-bit mode. Wolfenstein 3D ran in 16-bit and has a lot of horrible memory workarounds (paginated memory stuff), with Doom they said "screw that" and went 32-bit and it made everything simpler, more elegant, and easier to port.

esselfortium said:

Haha, wow, this is an old thread.

To be totally honest, if I was going to start work on KDiKDiZD again, I'd probably completely redo the majority of the existing work on it. As-is, it's a not-really-releasable mess of half-finished brokenness. I didn't really know what I was doing back then, and I ended working myself into a lot of corners.

The project is definitely still feasible and I have interest in it, although I'm not currently working on it -- with the experience gained from working on BTSX (and from the mistakes made in KDiKDiZD's first go-around) it'd probably go a lot better. I just don't have the time and creative energy to do all the projects I'd like to! Maybe someday.

A lot of modesty above... Just the stuff you decided to share and post was bad-ass...

Instead of KDiKDiZD, I would have settled for "Holy Crap, Look What I Made Vanilla Doom Do" :)

this post was just a recap of the original ms dos or virtual dos or dosbox release of the game before it was ported again on computers then ported to consoles and handhelds finally though.

I’m so glad you felt the need to clarify that to these people in this thread from eight years ago.

A little slice of history. Whoah.

 

In the end, we did get KDiKDiZD. And it was very good.

what the hell? i was searching for doom texture specs today for a project and this thread shows up because of this necrobump. good lord XD