Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Doom Marine

Y-Dimensions of Textures in Source Ports

Recommended Posts

I noticed Scythe II utilizing some textures with Y-dimensions exceeding that of 128 units, namely the Egyptian Hieroglyphics and Sarcophaguses. The textures seemed to display properly in PrBoom 2.2.4 and Zdoom.

I didn't know that such source ports allowed textures with Y-Dimensions greater than 128 units, so my questions are:

1) What is the maximum limit of the texture height [Y-Dimension] in Boom?

2) With regards to the question above, will anything strange happen if I were to give a texture a particular height along the lines of 44, 77, 96, 190, ie something that doesn't fit the powers of two?

Share this post


Link to post

1) for software ports, the maximum texture height is something like 508. That limit is imposed by the format of posts (a post is a vertical column of pixels upto 254 long). For OpenGL ports, it is possible there is no limit on texture height, almost certainly when using PNG images.

2) Sometimes. In original Doom, Boom 2.02 and EDGE if the texture is not a power of two high but the wall is higher (i.e. the texture would repreat) then it causes the "tutti frutti" effect (garbage pixels, though in EDGE it is black space). The same problem can occur when using negative Y offsets on the sidedef. PrBoom and other ports don't require a power-of-two, the clipping equation was changed to modulus so textures always repeat with no gaps/garbage.

Share this post


Link to post
Ajapted said:

1) for software ports, the maximum texture height is something like 508. That limit is imposed by the format of posts (a post is a vertical column of pixels upto 254 long). For OpenGL ports, it is possible there is no limit on texture height, almost certainly when using PNG images.


There is a workaround for software ports. I know that at least ZDoom is using it but others may as well. But please don't ask me how it works.

For OpenGL there is still a limit imposed by the hardware. Mostly it is 4096.

Share this post


Link to post
Graf Zahl said:

For OpenGL there is still a limit imposed by the hardware. Mostly it is 4096.

Yeah, for many older cards (non-Doom-3 capable) the hardware limit is 1024, and early cards (Voodoo3) has a mere 256 limit. I presume most OpenGL ports will squash the texture to fit, so it's more a "soft" limit (loss of detail) than a "hard" limit.

Share this post


Link to post
Ajapted said:

and early cards (Voodoo3) has a mere 256 limit.



I think that was one of the things that killed 3Dfx... ;)

Share this post


Link to post

Actually BOOM derivatives still do not support *textures* with heights greater than 128. Try it sometime and you'll see it crashes during R_Init somewhere deep inside the texture cache code (I actually never figured out the exact cause of the crash, this code is very dense). However, patches in textures taller than 128 are allowed. What the upper limit on patch height is, I have no idea, although 256 would be a good guess.

When dealing with textures under certain circumstances (like in the sky and on 2S lines), the entire patch will be displayed even if it is taller than the texture that contains it. This was complained about as a bug at one point to me, but actually, changing it would cause compatibility problems and would disable the use of patches taller than 128.

BTW, BOOM has always fixed texture tiling. No released version of BOOM ever had the tutti fruiti error in it.

Share this post


Link to post
Quasar said:

When dealing with textures under certain circumstances (like in the sky and on 2S lines), the entire patch will be displayed even if it is taller than the texture that contains it.

Yes, the railing texture in Aliens TC is like this, EDGE doesn't display it since the texture itself (REDWALL) is 128 high but the patch is 200 high (and mostly blank, the bottom part which contains the railing is clipped by the texture loader). Damn nuisance :).

BTW, BOOM has always fixed texture tiling. No released version of BOOM ever had the tutti fruiti error in it.

You're right. I was thinking of the handling of negative Y offsets which did change from Boom to PrBoom.

Share this post


Link to post

ok, so all very interesting, has anyone any quantifyable results from prboom/eternity/zdoom etc? i can make a test wad tonight and report back if yer all like?

Share this post


Link to post
Graf Zahl said:

I think that was one of the things that killed 3Dfx... ;)


the other one was crappy resolution and playstation like graphics

Share this post


Link to post
Graf Zahl said:

There is a workaround for software ports. I know that at least ZDoom is using it but others may as well.

That of using the 8 unused bytes in each texture entry and 4 unused bytes in each patch entry in the TEXTURE1/2 lump to store extra height data?

Share this post


Link to post
Fredrik said:

That of using the 8 unused bytes in each texture entry and 4 unused bytes in each patch entry in the TEXTURE1/2 lump to store extra height data?


No, that wouldn't help. The problem is that the first byte in each post specifies the starting coordinate in the column. I think it is doing something like treating it as an offset if it is larger than the current position or something like that. But you have to ask someone else about the details.

Share this post


Link to post
Fredrik said:

That of using the 8 unused bytes in each texture entry and 4 unused bytes in each patch entry in the TEXTURE1/2 lump to store extra height data?

First of all BOOM can display textures greater than 128. In fact, it was my accidental discovery of this (made a wall 508 tall and it displayed completely) that led to the next step - technically unlimited height textures (patches actually) using essentially the DOOM method so it does not blow up DOOM or any port, although unless the additional 3-4 lines of code are included the image generated will look odd (it's very simple to decode).

This was created by DeePsea (not ZDOOM) and given to RH as a method to both generate tall textures and hires textures. RH first didn't believe it could be done, so I sent him the level to prove it could be done :)

Once you can get tall patches, hires bcomes obvious if you knew how JDOOM worked at that time. JDOOM merely compresses the image size down to the size found in TEXTUREx, hence you get "hires".

RH choose to use a different method which on the 1 hand is more flexible and on the other hand less flexible in terms of getting the exact size you want. This involves using some spare bytes in the TEXTUREx header stuff to provide x/y scaling info.

It would have been slightly better to use the JDOOM method since it would have enhanced port compatibility and it would have given him an automatic way to scale PNG images (ala JDOOM of course).

This is in the history logs of DeePsea sbsoftware.com

In essense what I came up with was the concept of using the "limit" of the DOOM format as a trigger to automatically extend the height to any height you want. Just look at the expansion code in ZDOOM or JDOOM, it's very simple stuff.

Share this post


Link to post

(almighty bump)

should solve a problem for people in the future searching the forums, the clue is in the first post in this thread

textures can be 256 (or more) pixels tall if you like

patches can only be up to 254 pixels tall max

so if you want a 256 tall texture use two 128 tall patches. i had this trouble with the cliff textures in my wad and only just found this fix, so sharing it here

Share this post


Link to post
cycloid said:

(almighty bump)

should solve a problem for people in the future searching the forums, the clue is in the first post in this thread

textures can be 256 (or more) pixels tall if you like

patches can only be up to 254 pixels tall max

so if you want a 256 tall texture use two 128 tall patches. i had this trouble with the cliff textures in my wad and only just found this fix, so sharing it here

For what - DOOM? For BOOM and for ZDOOM and some other ports, please reread my post. If a port supports it, patches can technically be unlimited in height (using the method described), just limited to 4096 since over that is not useful - yet.

Share this post


Link to post

sorry, to clarify these limitations apply to boom and direct derivatives. currently a 256 tall patch has 2 pixels of tutti fruttiy in eternity, prboom and winmbf for example. i also presume that this would apply to original doom exes also

Share this post


Link to post
cycloid said:

sorry, to clarify these limitations apply to boom and direct derivatives. currently a 256 tall patch has 2 pixels of tutti fruttiy in eternity, prboom and winmbf for example. i also presume that this would apply to original doom exes also

Not exactly. There's actually a way to "fix" that in BOOM (as noted above). That's how I found out that a 508 tall patch actually worked - without - any line artifacts (508 is the limit of the original format). This was demonstrated in the first xtheater.wad I made. This not a patch limitation per se, but a "bug" in the code.

You also need a conversion tool that works correctly to get tall patches. Some earlier versions of some tools did either not work at all or had errors.

Share this post


Link to post

ok, informative stuff, though you say you need a particular wad patch import tool to do it? my way you just chop it up! but my wad only has two >128 px textures in so it was easy for me to do that without any hassle.

Share this post


Link to post

No, they merely bought the remains of a company that didn't see how the development progressed. Without their latest flops they wouldn't have been weak enough to be bought.

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
×