MC-152461Painting Animation Broken for any painting without a 1:1 ratio
This bug affects versions 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file, otherwise, I've attached some GIF images that show the problem and the work around 'fix'.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work without some alterations.
Hopefully this bug gets patched in the next update.
As for the map and images I've attached...
The 'burning_skull.png' is just a control image to show that animations work for an 'a' = 'b' ratio ('1:1') paintings. First, 'graham.png' and 'wanderer.png' represents an 'a' < 'b' ratio ('1:2') where 'graham.png' is the broken animation, while 'wanderer.png' is the 'fixed' file. Next, 'courbet.png' and 'creebet.png' represent an 'a' > 'b' ratio ('2:1') where 'courbet.png' is the broken animation, while 'creebet.png' is the 'fixed' file. Last, 'donkey_kong.png' and 'skeleton.png' represents another 'a' > 'b' ratio ('4:3') where 'donkey_kong.png' is the broken animation, while 'skeleton.png' is the 'fixed' file. (framespeed has been set as to 10 to show the effect)
Environment
Windows 10 (64 bit) using the internal Java 8 (1.8.0_51)
Attachments14
Created Issue:
Painting Animation Broken for any painting without a 1:1 ratio
This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... the reason this is and that I found out is Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.
For a work around until this is fixed, let's say each image has a ratio 'a:b'...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work normal, but anything that isn't '1:1' doesn't work.Hopefully this bug gets patched in the next update.
Environment
Windows 10 (64 bit) using the internal Java 8 version "1.8.0_51".
Attachments8
Animated Painting Bug Demonstration.zip
This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... the reason
thisis and that I found out isMinecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.For a work around until this is fixed, let's say each image has a ratio 'a:b'...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work normal, but anything that isn't '1:1' doesn't work.Hopefully this bug gets patched in the next update.
This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work normal, but anything that isn't '1:1' doesn't work.Hopefully this bug gets patched in the next update.
This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still worknormal, but anything that isn't '1:1' doesn't work.Hopefully this bug gets patched in the next update.
This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work with altering.Hopefully this bug gets patched in the next update.
This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work with altering.Hopefully this bug gets patched in the next update.
As for the map and images I've attached...
The 'burning_skull.png' is just a control image to show that animations work for 'a' = 'b' ratio ('1:1') paintings. First, 'graham.png' and 'wanderer.png' represent 'a' < 'b' ratio ('1:2') where 'graham.png' is the broken animation, while 'wanderer.png' is the 'fixed' file. Next, 'courbet.png' and 'creebet.png' represent 'a' > 'b' ratio ('2:1')** where 'courbet.png' is the broken animation, while 'creebet.png' is the 'fixed' file. Last, 'donkey_kong.png' and 'skeleton.png' represent another 'a' > 'b' ratio ('4:3')** where 'donkey_kong.png' is the broken animation, while 'skeleton.png' is the 'fixed' file.
This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work with altering.Hopefully this bug gets patched in the next update.
As for the map and images I've attached...
The 'burning_skull.png' is just a control image to show that animations work for 'a' = 'b' ratio ('1:1') paintings. First, 'graham.png' and 'wanderer.png' represent'a' < 'b' ratio ('1:2') where 'graham.png' is the broken animation, while 'wanderer.png' is the 'fixed' file. Next, 'courbet.png' and 'creebet.png' represent 'a' > 'b' ratio ('2:1')**where 'courbet.png' is the broken animation, while 'creebet.png' is the 'fixed' file. Last, 'donkey_kong.png' and 'skeleton.png' represent another 'a' > 'b' ratio ('4:3')**where 'donkey_kong.png' is the broken animation, while 'skeleton.png' is the 'fixed' file.This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work with altering.Hopefully this bug gets patched in the next update.
As for the map and images I've attached...
The 'burning_skull.png' is just a control image to show that animations work for an 'a' = 'b' ratio ('1:1') paintings. First, 'graham.png' and 'wanderer.png' represents an 'a' < 'b' ratio ('1:2') where 'graham.png' is the broken animation, while 'wanderer.png' is the 'fixed' file. Next, 'courbet.png' and 'creebet.png' represent an 'a' > 'b' ratio ('2:1') where 'courbet.png' is the broken animation, while 'creebet.png' is the 'fixed' file. Last, 'donkey_kong.png' and 'skeleton.png' represents another 'a' > 'b' ratio ('4:3') where 'donkey_kong.png' is the broken animation, while 'skeleton.png' is the 'fixed' file.
This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work with altering.Hopefully this bug gets patched in the next update.
As for the map and images I've attached...
The 'burning_skull.png' is just a control image to show that animations work for an 'a' = 'b' ratio ('1:1') paintings. First, 'graham.png' and 'wanderer.png' represents an 'a' < 'b' ratio ('1:2') where 'graham.png' is the broken animation, while 'wanderer.png' is the 'fixed' file. Next, 'courbet.png' and 'creebet.png' represent an 'a' > 'b' ratio ('2:1') where 'courbet.png' is the broken animation, while 'creebet.png' is the 'fixed' file. Last, 'donkey_kong.png' and 'skeleton.png' represents another 'a' > 'b' ratio ('4:3') where 'donkey_kong.png' is the broken animation, while 'skeleton.png' is the 'fixed' file.This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work with altering.Hopefully this bug gets patched in the next update.
As for the map and images I've attached...
The 'burning_skull.png' is just a control image to show that animations work for an 'a' = 'b' ratio ('1:1') paintings. First, 'graham.png' and 'wanderer.png' represents an 'a' < 'b' ratio ('1:2') where 'graham.png' is the broken animation, while 'wanderer.png' is the 'fixed' file. Next, 'courbet.png' and 'creebet.png' represent an 'a' > 'b' ratio ('2:1') where 'courbet.png' is the broken animation, while 'creebet.png' is the 'fixed' file. Last, 'donkey_kong.png' and 'skeleton.png' represents another 'a' > 'b' ratio ('4:3') where 'donkey_kong.png' is the broken animation, while 'skeleton.png' is the 'fixed' file.
This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work with altering.Hopefully this bug gets patched in the next update.
As for the map and images I've attached...
The 'burning_skull.png' is just a control image to show that animations work for an 'a' = 'b' ratio ('1:1') paintings. First, 'graham.png' and 'wanderer.png' represents an 'a' < 'b' ratio ('1:2') where 'graham.png' is the broken animation, while 'wanderer.png' is the 'fixed' file. Next, 'courbet.png' and 'creebet.png' represent an 'a' > 'b' ratio ('2:1') where 'courbet.png' is the broken animation, while 'creebet.png' is the 'fixed' file. Last, 'donkey_kong.png' and 'skeleton.png' represents another 'a' > 'b' ratio ('4:3') where 'donkey_kong.png' is the broken animation, while 'skeleton.png' is the 'fixed' file.This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work with altering.Hopefully this bug gets patched in the next update.
As for the map and images I've attached...
The 'burning_skull.png' is just a control image to show that animations work for an 'a' = 'b' ratio ('1:1') paintings. First, 'graham.png' and 'wanderer.png' represents an 'a' < 'b' ratio ('1:2') where 'graham.png' is the broken animation, while 'wanderer.png' is the 'fixed' file. Next, 'courbet.png' and 'creebet.png' represent an 'a' > 'b' ratio ('2:1') where 'courbet.png' is the broken animation, while 'creebet.png' is the 'fixed' file. Last, 'donkey_kong.png' and 'skeleton.png' represents another 'a' > 'b' ratio ('4:3') where 'donkey_kong.png' is the broken animation, while 'skeleton.png' is the 'fixed' file. (framespeed has been set as to 10 to show the effect)
This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work withaltering.Hopefully this bug gets patched in the next update.
As for the map and images I've attached...
The 'burning_skull.png' is just a control image to show that animations work for an 'a' = 'b' ratio ('1:1') paintings. First, 'graham.png' and 'wanderer.png' represents an 'a' < 'b' ratio ('1:2') where 'graham.png' is the broken animation, while 'wanderer.png' is the 'fixed' file. Next, 'courbet.png' and 'creebet.png' represent an 'a' > 'b' ratio ('2:1') where 'courbet.png' is the broken animation, while 'creebet.png' is the 'fixed' file. Last, 'donkey_kong.png' and 'skeleton.png' represents another 'a' > 'b' ratio ('4:3') where 'donkey_kong.png' is the broken animation, while 'skeleton.png' is the 'fixed' file. (framespeed has been set as to 10 to show the effect)This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work without some alterations.Hopefully this bug gets patched in the next update.
As for the map and images I've attached...
The 'burning_skull.png' is just a control image to show that animations work for an 'a' = 'b' ratio ('1:1') paintings. First, 'graham.png' and 'wanderer.png' represents an 'a' < 'b' ratio ('1:2') where 'graham.png' is the broken animation, while 'wanderer.png' is the 'fixed' file. Next, 'courbet.png' and 'creebet.png' represent an 'a' > 'b' ratio ('2:1') where 'courbet.png' is the broken animation, while 'creebet.png' is the 'fixed' file. Last, 'donkey_kong.png' and 'skeleton.png' represents another 'a' > 'b' ratio ('4:3') where 'donkey_kong.png' is the broken animation, while 'skeleton.png' is the 'fixed' file. (framespeed has been set as to 10 to show the effect)
This bug is currently for all versions of 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file, otherwise, I've attached some GIF images that show the problem and the work around 'fix'.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work without some alterations.Hopefully this bug gets patched in the next update.
As for the map and images I've attached...
The 'burning_skull.png' is just a control image to show that animations work for an 'a' = 'b' ratio ('1:1') paintings. First, 'graham.png' and 'wanderer.png' represents an 'a' < 'b' ratio ('1:2') where 'graham.png' is the broken animation, while 'wanderer.png' is the 'fixed' file. Next, 'courbet.png' and 'creebet.png' represent an 'a' > 'b' ratio ('2:1') where 'courbet.png' is the broken animation, while 'creebet.png' is the 'fixed' file. Last, 'donkey_kong.png' and 'skeleton.png' represents another 'a' > 'b' ratio ('4:3') where 'donkey_kong.png' is the broken animation, while 'skeleton.png' is the 'fixed' file. (framespeed has been set as to 10 to show the effect)
This bug
is currently for allversionsof1.14 and above.Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file, otherwise, I've attached some GIF images that show the problem and the work around 'fix'.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work without some alterations.Hopefully this bug gets patched in the next update.
As for the map and images I've attached...
The 'burning_skull.png' is just a control image to show that animations work for an 'a' = 'b' ratio ('1:1') paintings. First, 'graham.png' and 'wanderer.png' represents an 'a' < 'b' ratio ('1:2') where 'graham.png' is the broken animation, while 'wanderer.png' is the 'fixed' file. Next, 'courbet.png' and 'creebet.png' represent an 'a' > 'b' ratio ('2:1') where 'courbet.png' is the broken animation, while 'creebet.png' is the 'fixed' file. Last, 'donkey_kong.png' and 'skeleton.png' represents another 'a' > 'b' ratio ('4:3') where 'donkey_kong.png' is the broken animation, while 'skeleton.png' is the 'fixed' file. (framespeed has been set as to 10 to show the effect)This bug affects versions 1.14 and above.
Whenever trying to make any animation for paintings with a ratio that isn't '1:1', the animation either won't work or is stretched... I found out the reason is because Minecraft still thinks the size of each frame needs to be in a '1:1' ratio. To see this bug in action, I've attached the world and resource pack that demonstrates this bug, and the files that I changed to show how it fails, and how to "fix" it. The file named "Animation Painting Bug Demonstration.zip" contains the resourcepack and and the world file, otherwise, I've attached some GIF images that show the problem and the work around 'fix'.
For a work around until this is fixed, let's say each image has a ratio 'a:b' where 'a' is width and 'b' is height...
When 'a' is smaller than 'b', you can do the following
So in order to get an image such as a '1:2' painting to animate properly in game, it needs to be resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to stretch the x-axis), let's call this NEW_X
- Stretch the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
However... for images where 'a' is larger than 'b', things get tricky
So in order to get an image such as a '4:3' painting to animate properly in game, it needs to be first stretched then resized as follows.
- Note how many frames you made for the painting, and note the size of the y-axis in pixels
- Take the size of the y-axis in pixels divided by the number of frames (this gives you the size you need to shrink the x-axis), let's call this PROTO_X
- Since we are sizing down... quality would be lost, so we need to size up by 'a' first. So, stretch the entire animation image by multiplying 'a'.
- Now that the image is sized up, we need to get the size that we need to size down to, which is just PROTO_X multiplied by 'a', let's call this NEW_X
- Shrink the x-axis of the animation image to the NEW_X size of pixels, keeping the y-axis the same
Now that image should animate and look right instead of stretched.
Now, you may ask, why does this work?
What's going on is we are changing the ratio for each frame to be '1:1' instead of whatever 'a:b' ratio it was. The graphics engine still thinks all animations for paintings require a '1:1' ratio, which is why normal square paintings still work, but anything that isn't '1:1' doesn't work without some alterations.Hopefully this bug gets patched in the next update.
As for the map and images I've attached...
The 'burning_skull.png' is just a control image to show that animations work for an 'a' = 'b' ratio ('1:1') paintings. First, 'graham.png' and 'wanderer.png' represents an 'a' < 'b' ratio ('1:2') where 'graham.png' is the broken animation, while 'wanderer.png' is the 'fixed' file. Next, 'courbet.png' and 'creebet.png' represent an 'a' > 'b' ratio ('2:1') where 'courbet.png' is the broken animation, while 'creebet.png' is the 'fixed' file. Last, 'donkey_kong.png' and 'skeleton.png' represents another 'a' > 'b' ratio ('4:3') where 'donkey_kong.png' is the broken animation, while 'skeleton.png' is the 'fixed' file. (framespeed has been set as to 10 to show the effect)
Windows 10 (64 bit) using the internal Java 8
version "1.8.0_51".Windows 10 (64 bit) using the internal Java 8 (1.8.0_51)
relates to
relates to
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
![[Mojang] Moesh](../../../data/avatars/users/10122.svg){kind=small}
[Mojang] Moesh[Mojang] Moesh
Low
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
Issue still persists in 1.14.3-pre3
Hi there!
Is this still an issue in the latest snapshot or release? If so, please update the affected versions or comment on this ticket.
Tried out 1.16.1, and the texture animation bug with paintings still exists.
And now tried the latest snapshot, but it too has the bug still.
The minecraft gamepedia says width and height have to be defined as a ratio, but I found that's not true. It just needs to be the same aspect ratio as the default painting.
Example from fighters { "animation": {"frametime": 3, "width": 498, "height": 249}}