Map Texture Scaling versus Scaled Textures

Post by **Enjay** » Wed Apr 09, 2025 5:52 am

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 6 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 6 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 6 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 5 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?