Scaling issues on translucent, wrapped midtextures

[InsanityBringer]

Sample map, and a screenshot (but really it doesn't show you much, the bug generates absolute noise)

I've been noticing in recent dev builds (since the FP rewrite most likely, as it looks alright in ZDoom 2.8.1) that some maps like a few KDIZD maps from what I remember, which use translucent midtextures, if they enable the "wrap midtexture" flag on the line, the texture is scaled horribly to the point where its an absolute moirefest. The sample wad demonstrates this, with one line using wrapped midtextures and no translucency, while the other has wrapped midtextures and translucency. When rendered in recent builds of ZDoom (I tested the latest one for this), the translucent one exhibits the scaling artifacts, while the opaque one doesn't.

From further testing, translucent midtextures are fine. Its just wrapped ones that aren't.

[Graf Zahl]

This looks like something for dpJudas. It's still present in the latest build as of today.

[Edward-san]

Could it be the same as the one in Daedalus map25 at coordinates 227 -1713 on the right side?

[Graf Zahl]

Yes, looks exactly the same.

[dpJudas]

Interesting. This doesn't seem to be happening in QZDoom: http://imgur.com/a/77KIw (top image true color, bottom palette)

That means it must be an issue with wallscan, which I rewrote in QZDoom to fix a buffer overrun situation. I can't really fix the current wallscan, its code is too cryptic to me, but I can backport my rewritten wallscan to ZDoom if you'd like.

[Graf Zahl]

That's definitely worth a try. That is, unless it affects performance too much.
On the other hand, getting rid of that mess of code would definitely be an advantage.

[dpJudas]

Honestly, I don't know how well it competes with the original. I don't know if the original did it in such a convoluted way for some speed reason, or just to make it complicated for itself. With code one never knows.

[Graf Zahl]

Well, the code originates from Build, I think that says it all...

[Gez]

All the more reason to get rid of it, IMO.

[dpJudas]

Alright, here's the pull request with my rewritten wallscan: https://github.com/rheit/zdoom/pull/892

Note that if you merge this, wallscan/maskwallscan/transmaskwallscan can be removed from the list of build dependencies on the wiki.

[Rachael]

Just to be sure, I trialed your fix through the swimming marine test. Something I randomly invented for the purposes of testing the wall masking drawer.

It passed.

[dpJudas]

Hmm, not sure what that wad tests exactly. One thing that strikes me as a little odd, though, is that the vertical position of the marine is further up when seen from the front.

[Rachael]

It's to test to see if the midtex is clipped through the floor, or if it is rendered through the floor. The sprites I didn't need to test, because they were still going through the floor just fine.

I dunno - like I said I randomly invented it. I just wanted to be sure the new wall drawers worked as expected.

You could say, everything went swimmingly in that test.

Okay, okay, I'll stop.

[dpJudas]

Ah, but you've been looking at the new wallscan function for quite a while in QZDoom. It, and my earlier truecolor branch, has been using it there for 6 months soon in both pal and true color.

One of its changes in an ocean of changes!

[Graf Zahl]

Looks correct, no apparent performance hit, and getting rid of some Build code. Can it get any better...?