-
Bug
-
Resolution: Unresolved
-
None
-
Minecraft 1.14.1, 1.16.1, 1.16.2 Pre-release 1, 1.16.4, 1.18, 1.18.1, 22w03a
-
Windows 10 (64 bit) using the internal Java 8 (1.8.0_51)
-
Confirmed
-
Resource Packs, Textures and models
-
Low
-
Platform
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)