Problem with Transfer_Heights

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Problem with Transfer_Heights

Re: Problem with Transfer_Heights

by koverhbarc » Mon Dec 06, 2010 6:26 pm

Zippy wrote:I can understand why, in that position, you might say, "This might be a bug," or, "Well maybe this wouldn't be to difficult to do," but the real case here just isn't so simple.
I'm trying to use my best judgement. I don't need to know exactly how it works to understand that false ceilings are just the inverse of false floors and ought to have just the same code - indeed, that's why Boom added them, and using the same linedef!
I think with Transfer_Heights it functions, in part, by basically lying to the renderer about the actual heights of the sectors, which should tell you something about how the feature itself had to be designed.
Yes, I think I understand it now; it adjusts the sector floors and ceilings based on the current 'state' of the view - upper, middle, or lower. That being known, I feel pretty confident, unless someone explains to the contrary, that the failure of upper regions to work like lower ones is either a bug or an oversight.

I've downloaded the ZDoom source code. Since it has no useful documentation, it takes forever just to find all the places that might need to be changed for a given feature. This may be one reason there aren't moder code contributors.

Re: Problem with Transfer_Heights

by Zippy » Mon Dec 06, 2010 5:38 pm

koverhbarc wrote:I said, to allow this feature (only) for upper parts as well as lower and middle. I can't see why that should be hard.
I think this would be why:
koverhbarc wrote:I barely know how to program, and have no idea about the Doom source code.
I can understand why, in that position, you might say, "This might be a bug," or, "Well maybe this wouldn't be to difficult to do," but the real case here just isn't so simple. Now, I'm not terribly up to snuff on the exact workings of the renderer, having only familiarized myself with the principles behind it and the general function of vanilla Doom's, so I might not be on the best ground to speak about certain renderer "enhancements" from ZDoom either. But Doom's renderer was built for the very specific purpose of getting a lot of speed for the low power of 1993 machines, and in doing so didn't quite give it the expandability some would hope for. So Graf's use of the word hack is quite consciously chosen. It's not really a solution to add new powers to the engine, it's a trick to take advantage of the engine's design to get a certain visual quirk to work. It's inherently limited. I think with Transfer_Heights it functions, in part, by basically lying to the renderer about the actual heights of the sectors, which should tell you something about how the feature itself had to be designed.

Re: Problem with Transfer_Heights

by InsanityBringer » Mon Dec 06, 2010 1:27 pm

Pink Silver wrote:I'm surprised you weren't alerted that you weren't logged in by the fact that it asked you to solve a captcha to post.
This reminds me of a forum I once went to that, at one point in history, had CAPTCHAs on nearly every possible operation (including posting, logging off and on, and the like). They did it for security reasons and had no idea what was wrong with it.

Re: Problem with Transfer_Heights

by Graf Zahl » Mon Dec 06, 2010 8:28 am

koverhbarc wrote: When I made this test wad, I thought, based on the Boom reference, that it really divided the sector by height into two or three independent sectors. Apparently that's not within the renderer's capability.

No, it doesn't. What it does is, based on the current view point, hack the sector to display only one of the 3 parts. And that's precisely where it gets tricky. The engine never checks if the view transitions from middle to upper/lower or vice versa. So once it has made up its mind all sectors show the same area.

ZDoom extends this a bit that it only sets the viewpoint information when it really matters for the first time. In Boom it wasn't possible to look into a lower part from a sector without any Transfer_Heights at all.

Re: Problem with Transfer_Heights

by koverhbarc » Mon Dec 06, 2010 8:24 am

DavidPH wrote:
koverhbarc wrote:I can't see why that should be hard.
Then might I suggest that you do so yourself?
I barely know how to program, and have no idea about the Doom source code. Unless I'm given some clue as to why it can't be done, I'm hardly going to consider this a reasonable answer.

Re: Problem with Transfer_Heights

by DavidPH » Mon Dec 06, 2010 8:19 am

koverhbarc wrote:I can't see why that should be hard.
Then might I suggest that you do so yourself?

Re: Problem with Transfer_Heights

by Kate » Mon Dec 06, 2010 8:18 am

koverhbarc wrote:First, why does this board change my username to 'Betsy Senningtock'?
Names are randomly generated if you don't log in to post. I'm surprised you weren't alerted that you weren't logged in by the fact that it asked you to solve a captcha to post.

Re: Problem with Transfer_Heights

by koverhbarc » Mon Dec 06, 2010 8:13 am

First, why does this board change my username to 'Betsy Senningtock'? Whose cruel joke is that (I am male)? I registered under my usual handle.
Graf Zahl wrote:No, it isn't. The entire lower/middle/upper separation is global, i.e. if you once look into a lower sector it is set for the current frame and cannot be changed afterward for other sectors. So you won't be able to see middle and upper parts elsewhere. This is how the Boom team designed it 12+ years ago and it's really the only way to handle the feature. ZDoom is already more flexible by allowing to see into lower parts from non-Transfer_Height sectors
I said, to allow this feature (only) for upper parts as well as lower and middle. I can't see why that should be hard.
but this already needs some hacks directly in the renderer to work. Imagine what this might produce if it has to be done per sector.
When I made this test wad, I thought, based on the Boom reference, that it really divided the sector by height into two or three independent sectors. Apparently that's not within the renderer's capability.

Re: Problem with Transfer_Heights

by Graf Zahl » Mon Dec 06, 2010 7:23 am

Betsy Senningtock wrote: or at least something that could be easily fixed,

No, it isn't. The entire lower/middle/upper separation is global, i.e. if you once look into a lower sector it is set for the current frame and cannot be changed afterward for other sectors. So you won't be able to see middle and upper parts elsewhere. This is how the Boom team designed it 12+ years ago and it's really the only way to handle the feature. ZDoom is already more flexible by allowing to see into lower parts from non-Transfer_Height sectors but this already needs some hacks directly in the renderer to work. Imagine what this might produce if it has to be done per sector.

Re: Problem with Transfer_Heights

by Guest » Mon Dec 06, 2010 6:33 am

OK, thanks for looking at my wad. You seem to have determined the error and the explanation you provided seems to work. I still think that it is a bug, or at least something that could be easily fixed, that viewing from a normal sector works only for false floors and not for false ceilings - as I said, they should use the same code.

You're also right about the teleporter line, now that I think about it.

Re: Problem with Transfer_Heights

by Xaser » Sun Dec 05, 2010 4:38 pm

They look fine if you maneuver yourself into the correct position and don't move. :P

[Fun fact: during the boat launching sequence in Serpent: Resurrection, I was very impressed with the effect when the boat was pulling away from the dock... until I made the mistake of moving and spoiling the skybox-ness. :P ]

Re: Problem with Transfer_Heights

by Graf Zahl » Sun Dec 05, 2010 4:34 pm

The bigger problem with SSD were the hideous skybox windows anyway.,,

Re: Problem with Transfer_Heights

by Xaser » Sun Dec 05, 2010 4:30 pm

There's nothing wrong at all with using it in such a way if the limitations are kept in mind, which SSD did (though the doors looked very, very silly -- the texture could've at least been changed :P ).

Re: Problem with Transfer_Heights

by Graf Zahl » Sun Dec 05, 2010 4:25 pm

If you mean 'glitches just if you look from the right spot' you are correct.

Re: Problem with Transfer_Heights

by Guest » Sun Dec 05, 2010 3:10 pm

What definition of ROR are you guys using here? Super Sonic Doom (and LTSD for that matter) use Transfer_Heights for ROR effects with Bridge Things pretty well...

Top