Transparent midtextures: linedef length >512 weirdness.

The pics above are of a single 832 length linedef with a single 1024 length midtexture in place.

I made a 1024 length midtexture because I wanted to fill the 832-length window with a single texture rather than having a repeating 128-length midtexture with the two 32-length 'bookends' on either side. (Saving me several dozen sidedefs in this rather large vanilla map.)

But everything longer than approx 564 pixels in length goes all tutti frutti on me.

I had assumed that midtextures could be 1024 in length, the same as regular textures, but this does not seem to be the case.

So is it possible to have longer than 512 midtextures, or is there something else going on? (I am pretty sure I have got all the obvious things right: the midtexture is composed of a single patch, etc etc.)

Any thoughts?

Thanks guys.

You need to make a multipatch texture beyond that length, which you can't because MEDUSA. So you just need to figure out a different way to do what you want.

Divide the texture into several smaller textures. Problem solved.

Tarnsman said:

You need to make a multipatch texture beyond that length, which you can't because MEDUSA. So you just need to figure out a different way to do what you want.

Took your advice and went and messed around until I worked out a different solution. As you rightly pointed out, I need to have a multipatch texture beyond that length, but medusa generally kicks in if you do this.

But interestingly enough, I discovered that it is possible to have at least some multipatch midtextures that don't cause medusa. (tl;dr: Back in the early days of putting together the tnt2 texture pack I had no idea that multipatch midtextures caused medusa and so made lots of them. I found out about medusa pretty quickly, but I also noticed that not all those midtextures were screwed.) Provided the patches do not overlap; are not above or below any other patches, and are all the height of the texture itself, you shouldn't get any medusa.

So problem solved. I was going to just split the linedefs, but your post got me to thinking about multipatch midtextures again and I have managed to swing an 832 long midtexture on a single linedef.

BaronOfStuff said:

Divide the texture into several smaller textures. Problem solved.

Correct! I could easily solve this issue by dividing the long linedef into several smaller linedefs. But that doesn't solve the original problem of this huge map having too many damn linedefs and generally being a huge pile of hugeness and needing the removal of as many linedefs as I can manage. Making this map functional is the Dooming equivalent of Jenga. Except it is weird jenga played in some alternate universe where if you remove enough lindefs, everything works as it should and the level won't crash with blockmap issues.

Tarnsman said:

You need to make a multipatch texture beyond that length, which you can't because MEDUSA.

This isn't quite true -- Medusa only happens if you have overlapping columns in multipatch textures. If you want to do what Kyka's trying and have, say, a 256x128 patch repeated 4 times to create a 1024x128 texture, you're totally fine.

I'm pretty sure the DOOM engine is capable of 1024 (or wider) midtextures.

What I think happened here is that _patches_ have a size limit of 65536 bytes (because the engine uses 16-bit values to reference the columns in a patch), and because you made such a wide texture you overflowed this patch-size limit.

That's why the 1024-wide skies in Final DOOM are split into four separate patches.

Might work if your bars were thinner and if there were fewer of them, then could get more into a patch before exceeding 16bit limit.
The number of bars costs a bit more than the thickness of the bars.

Try making it that flat strip barbed wire, widely spaced.
Then you probably can get a much longer patch.

If your patch editor is not going to tell you when the 16bit column lookup table entries have values > 65K, then keep an eye on the patch file size. If your engine insists on using signed indexes (instead of unsigned) that limit may even be 32K for a patch. I cannot promise anything right now without looking myself.

Yep, going with the 64K patch size limit theory too. However that should not affect a texture composed of multiple legal patches. Did you try making a texture composed of 4x patches, or to make a new, single patch? These two are quite different beasts to the engine.

Xaser said:

This isn't quite true -- Medusa only happens if you have overlapping columns in multipatch textures.

And said textures are rendered as middle textures of two-sided linedefs. Using them as upper/lower/single-sided linedef textures is just fine (provided they don't have other problems, e.g partial transparency, in which case you'll get Tutti Frutti of the second kind).

Another trick was done in Requiem where they compressed the patches.
Any columns that were identical had only one copy.
Your patch texture looks like it has many columns that are identical.
A dumb patch editor will create separate data for each column.
I do not know what tool they used in Requiem to compress the patches.

The compressed patches caused problems in DoomLegacy until I recently added special handling for them. We combine patches into a texture at load time and it messed with the estimates for memory allocation.
Ports that draw like vanilla won't even notice that the column table is pointing to reused columns.

Fraggle has a program that can compress patches here. I've recently looked into adapting the code into SLADE 3. :)

In case it was not clear, a compressed patch can have a much longer length before the indexes overrun 16bits. If the same few columns are simply repeated, then it is only limited by the column index table size.

The problem comes in compression. Can the compression tool deal with a patch that has already overrun the 16bit limit in the column indexes.
I will guess not.

Then what is needed is a tool that can stitch together patches, or repeat a patch several times as it generates a compressed patch.
I suspect someone will have to write code.

Might want to consider compressing patches before stitching them together in your Slade3 toolset.

Looking at the source code of linuxdoom again, I can't understand where the 256-width limit for patches comes from, nor why/where there should be a 64K size limit to the entire patch.

The patch_t header uses 16-bit shorts for width/height/offset information, so at worst those are -32K/+32K. The column offset table itself is composed of 4-byte integers, and is typically read this way:

    column = (column_t *)((byte *)patch + LONG(patch->columnofs[col]));

so there's nothing forbidding you from having up to 2^31-1 columns in a patch (and even negative offsets), or pointing in the "middle" of previously used columns and do partial redraws, if your compression tool is "smart" enough to detect and do that.

Speaking of such a tool, it should work more or less like a gzip/tar algorithm, by creating a "vocabulary" of columns as it compresses.

Edit: it seems that the the 64K limit for column offsets is not inherent in the patch_t format itself, but in the R_GenerateComposite method:

void R_GenerateComposite (int texnum)
{
    byte*		block;
    texture_t*		texture;
    texpatch_t*		patch;	
    patch_t*		realpatch;
    int			x;
    int			x1;
    int			x2;
    int			i;
    column_t*		patchcol;
    short*		collump;
    unsigned short*	colofs;

and before that, to the texturecolumnsofs array:

unsigned short**	texturecolumnofs;

This affects both masked and unmasked texture, as the texturecolumnofs table is used for drawing both.

Other than saving memory and bandwidth, I can't think of any reason for them to be 16-bit in memory, when they are 32-bit on disk. If source ports change just this aspect, the 64K per-patch limit should be a non-issue.

The 256-pixel width limit mentioned by the wiki however must probably be an overgeneralization. I think skies are divided into 4 parts simply because it's a nice, power-of-2 number. Perhaps each part could be made 384 or 412 pixels wide each before hitting the 64K limit. After all, even in the case of the masked wall the part of the patch that renders correctly is longer than 256 pixels. There's still a 127 pixel height limitation per columnn, but that's another pair of socks (e.g. DeePSea tall patches).

The above being said...since each column offset is 4 bytes on disk, you can fit at most 16000 of them or so in a patch_t, thus putting the practical width limit near there (of course, you'll have to be super-economical with actual column data).

Yes, texturecolumnofs[] is the main cause of the DOOM engine's limitation on patch sizes.

I think the TNT skies have 256 wide patches simply because 512 was still too big (about 70K) and 3 does not divide evenly into 1024. Anything other scheme would've been a little bit more complicated.

DoomLegacy seems to keep the patch column tables as 32bit (same as in wad).
I wonder how those textures would look running under DoomLegacy.