Re: Problem with Transfer_Heights
Posted: Mon Dec 06, 2010 8:19 am
Then might I suggest that you do so yourself?koverhbarc wrote:I can't see why that should be hard.
Then might I suggest that you do so yourself?koverhbarc wrote:I can't see why that should be hard.
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.DavidPH wrote:Then might I suggest that you do so yourself?koverhbarc wrote:I can't see why that should be hard.
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.
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.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.
I think this would be why: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 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.koverhbarc wrote:I barely know how to program, and have no idea about the Doom source code.
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!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.
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 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.