Germany
- Thread starter
- #401
I think I found it...
If the last texture is too large only on one axis but does not fit anymore in the current texture then the texture atlas creation algorithm does not ignore it. It would have to create a new packed texture for only one texture and it does not do that one the last one under these circumstances.
A very long time ago I made the following change:
if (bmp.Width > (_maxTextureHeight / 2) || bmp.Height > (_maxTextureWidth / 2))
changed to
if (bmp.Width > (_maxTextureHeight / 2) && bmp.Height > (_maxTextureWidth / 2))
Idea was. If it fits in on either axis we are good to go. Imagine like 1x1024 pixels.
Reverting back to "or" instead of "and" means that if textures size is > 50% of the packed texture limit on either axis it will not get packed in. Under this circumstances the bug in the algorithm implementation does not trigger with your skin. It can still be triggered though.
As said if the last valid texture to be packed cannot be packed in the current atlas-texture we are stuck in an infinite loop.
I could fix the algo. But the Texture Atlas will be removed anyway as it has no benefits speed wise for us. And the power of two limitation only exists on some GPUs that have <= 64MB GPU memory (read AGP cards of the late 90s).
I currently cannot remove the texture atlas as some methods assume that the texture it uses is always packed. This stuff goes back up to the fontengine. Therefore this will be dealt with another time when new texture caching/hadling is introduced. Probably along an upgrade to DX11 for easier coding.
Will fix that one in the next build (already present in GIT, though). But before providing the next build I like to fix the ZapOSD exceptions as well.
If the last texture is too large only on one axis but does not fit anymore in the current texture then the texture atlas creation algorithm does not ignore it. It would have to create a new packed texture for only one texture and it does not do that one the last one under these circumstances.
A very long time ago I made the following change:
if (bmp.Width > (_maxTextureHeight / 2) || bmp.Height > (_maxTextureWidth / 2))
changed to
if (bmp.Width > (_maxTextureHeight / 2) && bmp.Height > (_maxTextureWidth / 2))
Idea was. If it fits in on either axis we are good to go. Imagine like 1x1024 pixels.
Reverting back to "or" instead of "and" means that if textures size is > 50% of the packed texture limit on either axis it will not get packed in. Under this circumstances the bug in the algorithm implementation does not trigger with your skin. It can still be triggered though.
As said if the last valid texture to be packed cannot be packed in the current atlas-texture we are stuck in an infinite loop.
I could fix the algo. But the Texture Atlas will be removed anyway as it has no benefits speed wise for us. And the power of two limitation only exists on some GPUs that have <= 64MB GPU memory (read AGP cards of the late 90s).
I currently cannot remove the texture atlas as some methods assume that the texture it uses is always packed. This stuff goes back up to the fontengine. Therefore this will be dealt with another time when new texture caching/hadling is introduced. Probably along an upgrade to DX11 for easier coding.
Will fix that one in the next build (already present in GIT, though). But before providing the next build I like to fix the ZapOSD exceptions as well.
Last edited:
