goostengine / goost

A general-purpose, extensible and customizable C++ extension for Godot Engine.
https://goostengine.github.io/
MIT License
481 stars 18 forks source link

Implement APNG support in Goost. #193

Open sairam4123 opened 2 years ago

sairam4123 commented 2 years ago

Describe the problem you are having in your project Summary:

Detail:

Describe the feature and how it helps to overcome the problem As I said earlier, this is a XY problem, so there are two choices.

  1. Improve the OGV file rendering on mobiles.
  2. Add APNG Support (I'm going for this one.)

Adding APNG support is best solution to this problem, but you could choose 1 and improve the OGV support for mobiles.

Describe how your proposal will work, with code, pseudo-code, mockups, and/or diagrams I am yet to think about it, but it will work the same way as GIF but a little better.

Is the feature helps to resolve performance-critical tasks? No.

Is the feature exposes existing functionality in Godot? No.

What alternatives have you considered before? Using GIF, but since it's old and doesn't support transparency and other things that I need. I'm looking for APNG as an alternative.

Is there a reason why this should be in Goost and not in Godot? Links to some Godot Proposals: godotengine/godot-proposals#475 godotengine/godot-proposals#3083

Xrayez commented 2 years ago

Nice, thanks for writing this up!

Yeah, I don't mind if APNG support is added.

Implementation-wise, I implemented the GIF loader similarly to static image loader in Godot. If we add APNG support as well, It means that ImageFramesLoader must be moved to core from modules/gif in Goost, so that a new APNG format/loader could be added.

https://github.com/goostengine/goost/blob/eb27535042f8c89f6f81acc192909baabc0e939d/modules/gif/image_frames_loader.h

Due to this, it makes me think that whether it would be reasonable to move modules/gif to core/image/io/gif or something like that. The only problem is that modules/gif will no longer be self-contained, but it's not a big deal, since it's basically the same situation as Godot's core/image.h and various image loaders such as modules/bmp. But given that GIF is a legacy format and APNG will likely not gain as much adoption due to availability of video formats, it makes sense to me to keep modules/gif there (even if the core ImageFramesLoader will be moved to core), and of course implement APNG in modules/apng.

Xrayez commented 2 years ago
  • The GIF was also slow and laggy when run from the debug build.

It may be AnimatedTexture issue in general. I recall complaints that it consumes CPU resources, see issues like godotengine/godot#39758.

sairam4123 commented 2 years ago

I don't seem to have problem in the editor, but I have trouble playing it in the game. It doesn't load before the animation must play and starts to play when the animation is about to end causing tons of headache for me, also if I add a gif to a node, it seems to be have issues like having slow start up and other stuff.

filipworksdev commented 2 years ago

I was looking at this and it might be easier and more worthwhile to implement animated webp support instead. Godot libwebp already has the ability to read animated webp. All you would need to do is add it into load_image function in the webp module and turn it into an AnimatedTexture resource if there are frames in the image. Pretty much the functionality and importing is already there it just needs to be added to one function.