Talk:Doom rendering engine

From DoomWiki.org

Comment for last paragraph of "Drawing floors and ceilings" section - main reason for Doom drawing flats as horizontal strips is different. Every horizontal strip of a flat has the same depth in the scene, so entire strip uses the same texture scale. Drawing flats as vertical strips requires quite costly division by depth for every pixel and rendering speed would really suffer from it at the time. -- KrzysiekK

I've tried to make this clear in a revision. As an aside, the format of the flats has nothing to do with whether its easier to draw them horizontally or vertically. Because the player view can rotate, the texture needs to be traversed in arbitrary directions; up, down, left, right, and any angle even, as drawing moves across the span. Contrast with wall and sprite drawing, where moving down the screen is always moving down the texture. See (as in linuxdoom-1.10) r_draw.c, lines 489-564. The code begisn with some explanitory comments that are sort of what I just said, and the final do loop is the texture traversal at an arbitrary angle. 71.58.109.233 22:40, 16 September 2007 (UTC)

"An upper or lower texture on a one-sided linedef, or on a two-sided linedef whose adjoining sectors always have the same floor and ceiling heights, is highly unusual and may even cause rendering problems if not handled carefully by the level designer(s)." <- I agree it's unusual because it's useless. But what problems can it cause? The only one I know is that they can work as hidden switches, but otherwise, what rendering problems are there?--82.208.146.89 09:34, 23 February 2015 (UTC)

I'm not even sure the "highly unusual" part is correct, I believe they end up happening pretty often in Doom Builder as a part of texture fill pasting or some other common function. I know when I changed my texture WAD for a project around I had to fix some texture references that weren't visible and weren't on moving parts. -- ETTiNGRiNDER (talk) 14:07, 23 February 2015 (UTC)
To clarify since it occurs to me that the way I put this might be misinterpreted. When I referred to fixing the texture references, I only meant removing the references because of the texture with that name no longer being present in my resource, not that I had to fix them for the issues being discussed here. My point being that I don't think they're a problem, not that they are. -- ETTiNGRiNDER (talk) 13:15, 24 February 2015 (UTC)
Hmm.  Apparently I added this, but can't recall the reasoning.  I was immersed in shovelware WADs (so definitely not DB) and got the impression that the most minor structural errors could induce runtime instability, but maybe it was because vanilla running on WinXP is crap!  If someone knows better, I encourage them to rework that bit.    Ryan W (talk) 21:24, 23 February 2015 (UTC)
The only situations I'm aware of where it would be detrimental are where either you're depending on the behavior of a raise-by-lower-texture line, or special effects are being attempted. Even then, the worst that is going to happen will be the effect not working as intended. --Quasar (talk) 22:57, 23 February 2015 (UTC)