Steve5563 wrote:ok i kinda get what your saying and i have no idea what per-texel panning is.
Graf Zahl wrote:
Take a line that is 128 map units long. And take a texture that is 640 pixels wide with a scale factor of 5. Per texel panning means that the offsetsyou need to specify range from 0-640, not 0-128.
To expand further, the practicality of this in GZDoom is that the pixel resolution of the original image (640 wide in Graf's example) is what is being referred to as texels.
So, in Graf's example, the 640 wide graphic has been scaled to 1/5 it's original size, making it effectively a 128 wide texture. The scaled with = 1/5 of 640 = 128. Its texel width is 640, its world units width is 128.
If you were to put that texture on a line in a map and give it an offset of 64, it would behave very differently, depending on whether per-texel or world offsets were being used.
With per-texel offsets, the texture would move by 64 of the pixels of the original graphic's resolution. So, our scaled 128 wide texture would move by 64 original resolution units (which, of course, is 1/10 or the original graphic's width) and so would only appear to move by 1/10 of the scaled width (12.8 world units). This, unfortunately (for historical reasons, as Graf explained), is the default. Of course, with different scaling factors, exactly how far the texture effectively moves will be different for each scaling factor. This is basically the root of the problem that you have experienced.
With world offsets, the scaled texture behaves exactly as you would expect a texture of the scaled size to behave. e.g. our 640 graphic scaled to an effective 128 units wide behaves like a normal 128 wide 1:1 scaled texture. Given an offset of 64 it would move by half its width, even though that would mean 320 pixels from the original graphic.
Generally, using world offsets is far more useful because it means that once your texture is set up, it behaves just like any texture of that effective size - making regular mapping less difficult to wrap your head around and drop-in replacements easy.
To my mind the only real advantage of per-texel offsets is that it allows very fine adjustments of the texture position. To go back to Graf's example, world offsets means that every unit of offset moves the graphic by 64 original resolution pixels. Per-texel offsets mean that every unit of offset moves the texture by 1/5th of a world unit. How often that level of precision is needed, I really don't know.
[quote="Steve5563"]ok i kinda get what your saying and i have no idea what per-texel panning is.[/quote]
[quote="Graf Zahl"]
Take a line that is 128 map units long. And take a texture that is 640 pixels wide with a scale factor of 5. Per texel panning means that the offsetsyou need to specify range from 0-640, not 0-128.[/quote]
To expand further, the practicality of this in GZDoom is that the pixel resolution of the original image (640 wide in Graf's example) is what is being referred to as texels.
So, in Graf's example, the 640 wide graphic has been scaled to 1/5 it's original size, making it effectively a 128 wide texture. The scaled with = 1/5 of 640 = 128. Its texel width is 640, its world units width is 128.
If you were to put that texture on a line in a map and give it an offset of 64, it would behave very differently, depending on whether per-texel or world offsets were being used.
With per-texel offsets, the texture would move by 64 of the pixels of the original graphic's resolution. So, our scaled 128 wide texture would move by 64 original resolution units (which, of course, is 1/10 or the original graphic's width) and so would only appear to move by 1/10 of the scaled width (12.8 world units). This, unfortunately (for historical reasons, as Graf explained), is the default. Of course, with different scaling factors, exactly how far the texture effectively moves will be different for each scaling factor. This is basically the root of the problem that you have experienced.
With world offsets, the scaled texture behaves exactly as you would expect a texture of the scaled size to behave. e.g. our 640 graphic scaled to an effective 128 units wide behaves like a normal 128 wide 1:1 scaled texture. Given an offset of 64 it would move by half its width, even though that would mean 320 pixels from the original graphic.
Generally, using world offsets is far more useful because it means that once your texture is set up, it behaves just like any texture of that effective size - making regular mapping less difficult to wrap your head around and drop-in replacements easy.
To my mind the only real advantage of per-texel offsets is that it allows very fine adjustments of the texture position. To go back to Graf's example, world offsets means that every unit of offset moves the graphic by 64 original resolution pixels. Per-texel offsets mean that every unit of offset moves the texture by 1/5th of a world unit. How often that level of precision is needed, I really don't know.