Demon
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Doom Editing > Transparent midtextures: linedef length >512 weirdness.
 
Author
All times are GMT. The time now is 01:54. Post New Thread    Post A Reply
KiiiYiiiKiiiA
Senior Member


Posts: 1421
Registered: 04-11


http://i.imgur.com/0HIqRd2.png

http://i.imgur.com/dJMC0L3.png
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.

Old Post 04-26-13 18:39 #
KiiiYiiiKiiiA is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Tarnsman
Forum Regular


Posts: 897
Registered: 05-11


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.

Old Post 04-26-13 19:11 #
Tarnsman is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
BaronOfStuff
Senior Member


Posts: 1368
Registered: 06-08


Divide the texture into several smaller textures. Problem solved.

Old Post 04-26-13 19:21 #
BaronOfStuff is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
KiiiYiiiKiiiA
Senior Member


Posts: 1421
Registered: 04-11



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.

Old Post 04-26-13 20:59 #
KiiiYiiiKiiiA is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Xaser
Forum Staple


Posts: 2656
Registered: 07-03



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.

Old Post 04-27-13 01:11 #
Xaser is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
andrewj
Senior Member


Posts: 1641
Registered: 04-02


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.

Old Post 04-27-13 10:28 #
andrewj is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
wesleyjohnson
Senior Member


Posts: 1056
Registered: 04-09


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.

Last edited by wesleyjohnson on 04-27-13 at 15:51

Old Post 04-27-13 15:45 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Maes
I like big butts!


Posts: 12750
Registered: 07-06


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).

Last edited by Maes on 04-27-13 at 18:07

Old Post 04-27-13 18:02 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
wesleyjohnson
Senior Member


Posts: 1056
Registered: 04-09


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.

Old Post 04-27-13 23:28 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11389
Registered: 07-07


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

Old Post 04-27-13 23:58 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
wesleyjohnson
Senior Member


Posts: 1056
Registered: 04-09


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.

Old Post 04-28-13 17:13 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Maes
I like big butts!


Posts: 12750
Registered: 07-06


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:

code:
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:

code:
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:

code:
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).

Last edited by Maes on 04-30-13 at 12:18

Old Post 04-30-13 10:08 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
andrewj
Senior Member


Posts: 1641
Registered: 04-02


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.

Old Post 05-01-13 03:50 #
andrewj is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
wesleyjohnson
Senior Member


Posts: 1056
Registered: 04-09


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

Old Post 05-03-13 19:18 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
All times are GMT. The time now is 01:54. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Doom Editing > Transparent midtextures: linedef length >512 weirdness.

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.