[Fixed] Texturing problem

[Kappes Buur]

This thread over at Doomworld
http://www.doomworld.com/vb/doom-editin ... -renderer/
made me curious about how ZDoom renders non-power-of-2 textures.

Whenever this topic came up in the past, the simple answers has always been 'Use power-of-2 textures'.
However, in the examples given by GoatAvenger in his thread and by me below

Spoiler:

it clearly shows that, at present, only alternate rows are rendered incorrectly.

Can this not be fixed to show everything correctly ?

[Graf Zahl]

Of course it could be fixed. Even Boom had a proper routine for such textures. ZDoom just never got that far. The main issue is that it can't perform as well as a power of two version and had to be coded separately.

[Kappes Buur]

Just wondering, why this happens only on every other tier.
To me that would suggest, that the rendering code is working correctly at least 50% of the time.

Maybe I should have mentioned, that the above example shows a 72h x 24w gray texture on a linedef of 448 units and a sector with a height of 512 units. So, for the time being, one could use a hack by inserting a sector, 2 map units smaller on each side, with a 68 map units height (floor at 57 and ceiling at 127), to have it show correctly.

Spoiler:

The drawback is, that one can see the flaw when close to the wall

Spoiler:

[randi]

You should use a real texture instead of solid gray. I think you'll come to a much different conclusion about what's "working".

[Project Dark Fox]

Disregard, I'm talking out of my ass.

[Kappes Buur]

I really don't want to flog a dead horse here, so I just make one more post on the subject

You should use a real texture instead of solid gray. I think you'll come to a much different conclusion about what's "working".

Whatever non-power-of-2 texture I use, the result is always the same. Every even tier is rendered correctly and every odd tier is rendered with tutti-frutti.

Spoiler:

If this cannot be fixed, well, so be it.

[randi]

Fixed.

Every even tier is rendered correctly and every odd tier is rendered with tutti-frutti.

So, maybe I should have been more specific. For rendering purposes, the texture's height is rounded up to the next power of 2. Since this is taller than the texture is in reality, the extra pixels at the bottom come from the next column to the right, since columns are stored consecutively in memory. There is no column to the right of the right-most column, so the extra pixels drawn at the bottom of that column are garbage.

[Graf Zahl]

Nice to see this one finally being resolved.

[Gez]

Not entirely fixed, though. I'll make a new thread for the remaining issue.