Map Texture Scaling versus Scaled Textures (GZDoom 3.7.0 onwards)

[Enjay]

Edit: This was originally a thread in the editing forum but, as can be seen from my later posts, it seems that this is a bug, rather than something that can be solved via an editing query. So, I have moved the thread here in case anyone is still checking the GZDoom bugs forum. An issue has also been raised on the UZDoom GitHub page (linked in a post below).

As stated later, I have tracked this down to changing between version 3.6.0 and 3.7.0 of GZDoom. 3.7.0 contained a "fix" that specifically relates to this issue, but since 3.7.0 it has become impossible to create a straight drop-in hi-res replacement for a texture (e.g. a hi-res texture pack) if any of the textures being replaced are also scaled and offset in-map. The hi-res textures in such a situation should appear in exactly the same position as the original low-res version, but they do not.

Original post follows:

I'm having a problem with some scaled textures.

I have several existing (read, very old) maps where I put a poster "on" a wall by having a 2S line sitting in front of the actual wall. I wanted to drop in slightly higher resolution versions of the textures, but GZDoom is not behaving as I expected. Note, I don't say "wrong", just that it's not doing what I expect. It may be correct. Which is why this is here and not in the Bugs thread. However, if it is behaving correctly, then I don't think there is a way for me to do what I want without also editing the maps to fix the alignment of the textures.

So, I'd really appreciate it if someone could look at this and tell me if GZDoom is behaving correctly (and if there is a way to achieve what I want - a simple drop-in replacement without having to edit the maps).

All test maps are attached with a simple example texture. Just load each PK3 on its own into GZDoom and start a game.

Test01.pk3

Test01.pk3

(6.87 KiB) Downloaded 13 times

The base-line. A simple 1:1 texture that has been scaled in-map - the one on the right is the completely unscaled and not-offset version. The four larger copies of the scaled version have been scaled in-map by a factor of 2 in both the X and Y direction. The smallest one has been scaled by a factor of 3. They have all been given Y offsets to make them sit near the top of a brick to make spotting differences easier. The textures to not have lower unpegging set, so all offsets are -ve to move them downwards.
Texture definition:

Code: Select all

Texture "testpost", 64, 128
{
	Patch "Test01", 0, 0
}

Test02.pk3

Test02.pk3

(26.47 KiB) Downloaded 11 times

The texture has been replaced by dropping a 2x version of it into a HiRes folder in the PK3 (no change in texture definition). As far as I was aware, this should create a hi-res version of the original that automagically scales itself to the same dimensions as the original and respects offsets etc. However, as you can see, that doesn't seem to be happening with the scaled versions. (The smallest one has been pushed down below the boxes.)


Test03.pk3 (My preferred method)

Test03.pk3

(21.29 KiB) Downloaded 11 times

The texture has been redefined in the textures lump to use a bigger (2X) version of the patch, and scaled back down to the original image size via the texture definition. The textures lump specifies WoldPanning. There is no HiRes folder in the PK3.
I have used this method many, many times, but never with this kind of 2S line effect with in-map scaling. It usually gives the same effective result as using the HiRes folder.
Texture definition:

Code: Select all

Texture "testpost", 128, 256
{
	XScale 2.000
	YScale 2.000
	worldpanning
	Patch "Test01", 0, 0
}

The above seems to be giving the same result as Test02.pk3 (which I would expect it to) but, given that Test02 didn't do what I wanted, this isn't either. Like I said, I've used the method before and I expected the texture to behave as if it was its original size, and respect offsets and scaling (in much the same way as I expected for the HiRes folder method).

What I *think* is going on for Test02.pk3 and Test03.pk3, is that the textures have been offset by actual image-pixels in the map, but when a hi-res version is used, it is using effective scaled pixels for the offsets, and this is moving the image down by more than I want it to. So, (as an example - not the actual units used) what was an offset of -24 units has effectively become a world-units offset of -48 in the 2X scaled textures and -72 in the 3X one. Maybe.

I just realised that all these tests only check the Y offset. None of the textures in the tests have been given X offsets. My bad.

Test04.pk3

Test04.pk3

(21.28 KiB) Downloaded 10 times

This is the same as Test03, except that WorldPanning has been removed from the texture definition.
Texture definition:

Code: Select all

Texture "testpost", 128, 256
{
	XScale 2.000
	YScale 2.000
	Patch "Test01", 0, 0
}

This is still not doing what I want. The posters all sit higher than in Test01.pk3 (except the unscaled one). Notably, the smallest one has moved up proportionally more than the others. So, I guess that the in-map offsets are now being used as actual image-pixel-offsets, but because these are smaller than on the original image, it doesn't move the texture as far... or something.

So, sticking with the example, an original offset of -24 has become an effective -12 for the 2X and -8 for the 3X scaled textures. But I'm really just guessing here.


So, there's the problem. No matter what method I use (unless there is another) I don't think I can create a drop-in replacement that will respect the scaling and offsets of the textures already in the map.

I realise it's a problem of scaling versus scaling - two different scaling methods bumping up against each other - but I thought that at least one of these methods (particularly Test02 and/or Test03) should have done what I am looking for.

So, is GZDoom behaving correctly?
If so, is there a way to do what I want?
If not, I can go in and edit all the maps that are affected, but I don't want to do that only to find that GZDoom was wrong and I have to go back and unedit them.
Surely there must be a way to create a drop-in replacement without having to edit the maps anyway though?

[Enjay]

In the unlikely event that anyone has been waiting to see what is happening with this, I have opened a UZDoom issue for this and transferred all of the releavant information from this thread to there. https://github.com/UZDoom/UZDoom/issues/224

FWiW, I have also tracked this behaviour down to starting some time between GZDoom 3.6.0 and 3.7.0.
3.6.0 works as expected, 3.7.0 shows the broken behaviour explained above. So, it does indeed seem to be a bug.

[Enjay]

As mentioned above, through a bit of trial and error, I tracked down things to 3.6.0 working as expected and 3.7.0 showing the above behaviour.

In the detailed release notes for 3.7.0 there was this:

● fixed incorrect alignment of scaled world panned textures combined with per-sidedef scaling in the hardware renderer
This particular case incorrectly factored in the sidedef's scaling factor for how to calculate the offset.
Fortunately this is a very rare case - a quick check yielded no maps depending on it.
Should any map surface that depends on this bug a compatibility option may be needed but it doesn't seem likely that this may be the case

So, that seems very likely to be where and why this started happening. The problem is that there is clearly something wrong with the fix because it is now impossible to to replace a standard (1:1) texture with a hi-res one if the standard texture has been scaled in-map and have the replacement texture appear in the correct position. So, while the combination might be rare when only considering individual WADs, if a WAD that scales textures in-map is used in combination with a hi-res texture pack, things will be broken.

At present, there is no way to use a hi-res texture replacement wad/pk3 of any type in conjunction with a map that has a texture scaled in-map on a per-side-def basis and have the scaled textures appear in the correct position.

I am currently working on a project where I have several hi-res textures and, sometimes, those textures need to be further scaled in-map. UDB shows them in accordance to the correct rules, but GZDoom does not. So, when I'm editing, I can't even see where the textures are going to end up in game until I actually run the game and have a look. I have checked the maps in GZDoom 3.6.0 and the textures appear as they should in that.

In the 3.7.0 release notes, it also said:

● add support for scaled textures in the software renderer

In the GitHub issue that I linked to, I tried the software renderer and the test textures are very broken in it. So, that seems to be a problem too.

Given all of the above, this feels much more like a bug than me just not getting the mapping/editing right. So, I'll move this thread into the bugs forum just in case anyone is looking in there these days.