TEXTURES scaling does not work with a certain compat flag

[Talon1024]

Title says it all. Texture scaling factors specified in TEXTURES do not work on the Linux version of GZDoom.

Example ZIP: http://www.ciinet.org/kevin/myimages2/d ... hdtest.zip.

hdtest.zip

Example - attached for people who cannot download from my site.

(8.84 KiB) Downloaded 41 times

EDIT: It's not an issue with the Linux version of GZDoom, but rather the "Ignore Y offsets on masked midtextures" compatibility flag.

Is it supposed to break scaling defined in the texture definitions like that? Texture definition scaling is not broken when I use either the planar or polygonal software renderers.

[_mental_]

Could you please attach example to the post? Download requests timed out for me.

[Talon1024]

All right, I attached the example to my post.

[_mental_]

Works for me in Ubuntu 16.04 VM. Could you please post a screenshot?

EDIT: Did you have something different from the pictures below?

With scale:

Without scale:

[Talon1024]

Turns out I had my compatibility options set for Boom compatibility. One of the options that gets enabled when I use Boom compatibility mode is "Ignore Y offsets on masked midtextures". Apparently, that flag breaks texture scaling from TEXTURES in the OpenGL renderer, but texture scaling specified in TEXTURES is unaffected in both the softpoly and classic planar renderer.

[_mental_]

Paletted renderer:

True color renderer:

Only poly renderer is not affected by this compatibility option. I guess that's only because it doesn't taken into account in poly renderer.

[Talon1024]

Well, the polygonal renderer isn't fully mature yet, so there's still some stuff that doesn't work, like self-referencing sectors, Boom height transfers, etc.

But, the issue I'm talking about is the fact that the aforementioned compatibility flag breaks scaling on textures defined in TEXTURES in the OpenGL renderer.

[_mental_]

Sure, I got it. The thing is such handling of this compatibility flag was explicitly added in hardware and software renderers to work this way.
Maybe Graf can tell us more about it.

[Graf Zahl]

If the renderers behave differently it is a bug. This should not affect scaling.

[Graf Zahl]

The problem here comes from that flag being a very 'dirty' implementation. The way this is handle it simply loses the scale factor along the line - and apparently one of the renderers even mixes data from both the scaled and unscaled version of the texture. Ugh...

It was just a quick hack to get things working for maps that actually need the flag.