Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
deep

Textures higher > 240 on a 2-sided wall

Recommended Posts

In making (modifying) a theater level while testing DeePsea, I accidently ran across a way to display a texture on a 2-sided wall over 240 tall.

My favorite textures are lovely nude females (so this is now called Xtheater of course), but I could never get them to display over 240 without either an ugly line (at 240) or having to split stuff up. This is for ZDOOM (DOOM2 doesn't work - others haven't tested).

I'm still playing around with it, but right now I have one texture (1 patch) that's 480 tall and she's lovely. If I have time, I'll see how far I can push this. Wouldn't it be cool to have one texture that's 1024 tall? I'll see if it works with multiple patches too. Still limited to 256 wide - too bad:)

Share this post


Link to post

My favorite textures are lovely nude females

Rofl, and that comes from someone who's representing a commercial product

Share this post


Link to post

I accidently ran across a way to display a texture on a 2-sided wall over 240 tall.

Care to share the techniques with the rest of us?

Share this post


Link to post

My favorite textures are lovely nude females

Rofl, and that comes from someone who's representing a commercial product

Don't you know there is a lot of them like that out there already when you search for them with google's engine?

Share this post


Link to post

Wouldn't it be cool to have one texture that's 1024 tall?

YES, OH YES OH YES OH YES!!!

(and I haven't even seen your texture yet :P )

Share this post


Link to post

YES! It works at 1024 high and for multi-patch. Also works on 1-sided, although slightly differently (if you want to avoid the horizontal line. Also got it over 1024 wide as well. Ran into a zmalloc error at 8096x1024, must be a ZDOOM bug(?) - I gave it a 64mb heap.

Need to finish it after all this playing around. Now my dilemna is that it's "best" with my original models, but I suspect that I'll get a lot of flack if I leave the cuties in there. So I need to dig up some fresh meat, but not too fresh (hahahaha).

Looks like this accidental feature was created by BOOM, so should work on most BOOM derivates.

Share this post


Link to post

Looks like this accidental feature was created by BOOM, so should work on most BOOM derivates.


Accidental? Removing the fixed tiling height of 128 for textures was a deliberate Boom feature (unfortunate in some respects, removing the requirement for power-of-two height textures was one of the more regrettable Boom changes, it's a right PITA to support). I wasn't aware of any particular limit on texture sizes, other than practical ones.

Share this post


Link to post

There are indeed problems with texture sizes. Those who edit levels know all about the problems.

The big HORIZONTAL line is one biggie (oogly looking), 2-sided lines presented another.

So you see, it is "accidental" that I ran into simple methods to make it look ok. 2-sided one has a razor thin line (at some angles), the other has NONE.

I'm not aware of anyone having textures over 240 tall without a line or other anomaly. And the 2-sided ? has come up lots of times.

Share this post


Link to post

There are indeed problems with texture sizes. Those who edit levels know all about the problems.
...
I'm not aware of anyone having textures over 240 tall without a line or other anomaly. And the 2-sided ? has come up lots of times.


Well, to put it another way, I thin the only problem is having to work around the limitations of the graphics format, i.e. when converting to Doom's graphics format you have to break things up into posts <256 tall. (Not sure where the magic number 240 is coming from, might have to investigate that). Since original Doom didn't support non-128-height textures I don't know if there are any tools available that do this.

Ah now I see the problem, Boom is too clever and would spot that these aren't multi-patch columns and wouldn't convert them into a single post internally. So let me guess, the trick is to deliberately include a second patch underneath so the engine has to treat all the columns as multi-patch?

The situation for 2S lines is a bit different, because Boom does two post->column passes - one pass to convert a possibly multi-patch column into a single column, and then a second pass (because that column may still contain multiple posts, 2S textures may contain gaps). So that probably requires a more complex workaround; you could cheat by embedding post start data inside the patches, I suppose, but that would be horrible.

Share this post


Link to post

Ok, I've done some experiments and it's time to correct my previous reply. It's not as simple as breaking it up into <255 posts, as all posts are offset relative to the top of the texture by at most 254. So a patch can't be more than 254+255 high. (I was thinking offsets were relative to the previous post, which would make more sense, but alas not).

I was also wrong about forcing multi-patch columns as a solution; it could work but because Boom constructs columns correctly, R_GenerateComposite will write junk into the column in order to put the end-of-posts marker in place.

You can get arbitrarily tall 1S line textures by cheating, by just writing a post longer than the post header says (i.e. have one post header record, with delta = 0xff to indicate last post, length 0, then just put 1024 or however many bytes of pixels following - Boom assumes that single-patch columns have only one post per column and of the correct length, so it just works). I can put up a wad to demonstrate this if anyone's interested.

Tall 2S textures are a different kind of problem as I said, masked texture rendering obeys the post length field. You can do up to 254+255 with multiple posts in a single patch as noted above, not sure if there's any way to exceed that without some really bad cheating.

Share this post


Link to post

Well, you saved me some time to explain things. 240 is somewhat supported via the sky mods and somebody did a conversion pgm for that too. That's the only reason I listed it - it was a familiar standard.

The tallest single patch is 508 and stay within safety rules (deleted the FF issue, just depends on the code). It would be an interesting way to let it be "unlimited". Now that I know higher textures can be displayed, I think I'll let that be an option.

It's generally not a good idea to let it run amuck, but I'll play around with it and see how much trouble it causes. Right now DeePsea checks for valid columns, and I suppose others might too to make sure nothing is going awry. However, DeePsea is capable of creating the 508 right now.

I played around with single 508 patches long ago but wasn't happy with the results. Tried to goad somebody into doing it the "right" way - nothing happened:)

The heights can not be arbritrary -sometimes one can, sometimes not - depends - or else you get an ugly line. Go ahead and try it some more.

What I discovered is fairly simple, merely by removing DeePsea to let it create higher textures than 508. The limit was only there since I never could get it to look good so didn't realize that going higher would work.

Essentially, there are various ways to make it work. One way is to make the texture height a multiple of 256 and make the width also a multiple of 256 so it won't chop there. And you can do 2-sided too! No cheating involved.

When I find suitable replacement graphics I'll post the level for everyone to see.

Share this post


Link to post

Oops forgot about the transparency issue. You can't just continue unabashed unless there is no transparency to worry about. Think I'll leave this for a later day.

Share this post


Link to post

Demo of 1024 high texture: http://www.cph.demon.co.uk/doom/tall.wad replaces texture BSTONE1 by a simple 1024 high texture. Make your own demo level. It probably only works with a few ports, but I think Boom will be one of them (only tested on PrBoom myself). It really is cheating though, and I intend to fix PrBoom so it won't work in future. http://www.cph.demon.co.uk/doom/make.pl generates the actual patch lump.

From the Boom code, it appears there are several places that assume single-patch-in-a-column => single-post-in-a-column , and these are all basically errors which should be fixed.

I wonder if it's worth changing the code to use a different post header internally, in order to allow multi-post columns totalling over 256 high to be composed correctly into a tall post; this would allow tall textures correctly in all circumstances without cheating, just by using multiple patches. In fact there's a spare byte between the post header and data if I read the code right, so this doesn't even need to change the format, just change the struct definition and use the space.

Share this post


Link to post

You forgot about the LENGTH of the column data. If you look carefully that's required for transparent areas to jump Y offsets. IOW, you can't just string data together without taking some more measures.

However, what you did is a cheating hack and taking advantage of the fact that no safety checking is done (which should be fixed).

What I did is NOT cheating and preserves 100% integrity in all respects. DeePsea detects there's a "mistake" in your patch and won't display it:)

There's nothing to "fix" for doing it legitimately. However, as I already mentioned, this also works for NON multiples of 256 in some cases. As I pointed out in the 1st post, I did it for 480 - a single patch in this case, although one could do a composite too - which I also tested.

The OTHER thing that has to be fixed (besides safety checking) to make this look better with less work is to get rid of the relatively large horizontal "mistake" in some cases when it's not a 256 multiple.

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this  
×