-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Animated images have the aspect ratio of their long PNG texture, not their actual aspect ratio as on items #1484
Comments
Yep, confirmed. Any images using atlas sprites need to take the number of frames into account when calculating effective image height. I think the best fix for this will also require an FTB Library update (where atlas sprite icons are created). I couldn't get my dev instance to recognise the test globe image above, but I have tested a fix with the vanilla animated water and lava icons, and confirmed that the aspect ratio was previously wrong and is now correct. |
Returns 1 for most icons, but atlas sprites can have multiple animation frames, and this is important for aspect ratio calculations done in FTBQ FTBTeam/FTB-Mods-Issues#1484
Returns 1 for most icons, but atlas sprites can have multiple animation frames, and this is important for aspect ratio calculations done in FTBQ FTBTeam/FTB-Mods-Issues#1484
Thank you for getting back to me so quickly! I was able to get Quests to recognize the globe image if I just created a test item with it as the texture. I think the best fix is to get rid of the method you use to set the width and height entirely and move them into final fields in your images. Additionally, since the three functions where this bug occurs(ChapterImage#isAspectRatioOff(), ChapterImage#fixupAspectRatio(), and ChapterImage#getAspectRatio()) are only called client-side as far as I can tell (I haven't dug through the code or tested on a dedicated server) it is possible to directly fetch the image metadata from Minecraft's ResourceManager. I touched on that fix before, but in your code right now you already do something very similar to this while discarding the animation metadata. In addition, your current method of using your PixelBuffers reads the entire image into memory just to query it for it's width and height and discards it after. While working with my particularly large image, the dimensions are 800 x 150300, the method of reading the entire file causes a lot of lag. It is generally fine for smaller images, like Minecraft textures, but for animated textures especially it gets bad fast. A future-proof fix for this definitely includes changing how you find that width and height, taking into account animations and Minecraft's many oddities. |
Yeah, reading the entire image isn't ideal, I agree. I'll see what can be done about just grabbing the metadata... (I realised afterward that I couldn't load the test globe due to the way texture atlases have changed in 1.21, where images need to be in specific subdirs of |
This applies to files that aren't animated as well, all PNG files store their height+width in their headers as well. I'm fairly sure that it'd be easy to do but I have no idea how Minecraft handles that, especially in a texture atlas sprite... |
Mod
FTB Quests
Mod version
ftb-quests-forge-2001.4.10
NeoForge / Forge / Fabric version
Forge 1.20.1
Modpack & version
No response
What issue are you having?
This is not a version-specific issue, it is a structural issue with your code. I know because I've fixed it with Mixins in the version released as of yesterday.
The issue is that when you add an image with an animated texture, it looks at not the frame width/frame height as defined in the animation metadata section but the height and width of the entire file. This can be fixed a few ways, either dividing the height/width of the file based on the frame count which could be complicated, or change how the aspect ratio is calculated and attach that animation metadata to the Icon object itself.
The current method leads to width values that are tINY and depend on how many frames there are in the animation.
See attached for said tiny width values.
As a final note, the globe is a 0.02 width, and only a couple frames long. In the attached file is an iteration of the bug with a much longer image(300 frames long). You can see a lesser version of this bug if you add the campfire_fire texture as an image.
Crashlogs
No response
Steps to reproduce
download the png and associated mcmeta file from the github here:
https://github.com/gamma-02/host-pngs-for-bug-report
Add them to your textures so that you can add it as a texture in FTB Quests
Add the texture to a chapter in FTB Quests
Observe how the width value is an absurd 0.02, and almost if not completely invisible.
Anything else to note?
No response
The text was updated successfully, but these errors were encountered: