Ported from https://github.com/godotengine/godot/issues/18269
Describe the project you are working on:
Unrelated
Describe the problem or limitation you are having in your project:
Currently if a developer is going to use 2D animated sprites, they have to go through a semi complicated process for creating and animating it in Godot. The more animations you need to add to your project, the more tedious and prone to error it becomes.
Similarly, if the dev wants to display a sprite with its palette swapped (eg it's a unique version of an enemy so it's yellow instead of purple) they have to either use a shader to shift its entire palette, recolor the sprite in their image editor of choice, or develop a semi-complex shader that dynamically swap palettes. The first option, while fast and easy, gives almost no precise control, the second ends up creating unnecessary asset bloat, and both the last two options are labor intensive and slow.
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Some engines, like MUGEN, have the ability to import GIFs and automatically convert them into animated sprites. This makes creating and adding 2D animations into the engine incredibly easy and fast.
MUGEN also expands on this by allowing the user to edit the indexed palette of sprites to very quickly create palette swapped sprites.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
The biggest issue I see is figuring out the process the user needs to go through to have a GIF be turned into a fully animated Sprite in engine. This can't be done on import because where would the editor put the new nodes? It could save each animation as a new scene with the AnimationPlayer as the root node, but that would be pretty unique behavior to GIFs and APNGs.
The easiest solution I can think of is having the user drag the GIF/APNG into there scene and then create the tree of nodes.
For the palette I can see it being one of two systems. The most user friendly one would be to have a palette resource in the StreamTexture generated on Import that when clicked into they see each paletted color as a clickable square and then they can start editing the palette as they desire, similar to the GIF above.
The second system would be easier but it wouldn't be user friendly and it'd be considerably slower and more cumbersome. The positive is that it wouldn't require much work to make vs the system above. When inside the StreamTexture the user could edit the palette by selecting its number on the index slider and changing it below that.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
No
Is there a reason why this should be core and not an add-on in the asset library?:
It'd massively improve the workflow for adding in animations and creating palette swaps.
The biggest issue I see is figuring out the process the user needs to go through to have a GIF be turned into a fully animated Sprite in engine.
It could be imported as AnimatedTexture.
TBH, I forgot that AnimatedTextures exist. I've never used any in any of my projects yet and setting them up right now looks to be a huge pain.
But yes, if it were set up automatically by importing a GIF/APNG then that would probably be best.
Adding GIF support seems nice but it has some drawbacks.
Perhaps, AnimatedSprite is more suitable in this case.
The idea isn't to support gifs and apngs as formats in engine, but to
support them in the importer to improve the workflow of 2D developers. Be
it turning them into an AnimatedTexture, AnimatedSprite, or even a full
sprite sheet with subsequent animation node tree.
On Sat, Feb 15, 2020, 7:34 AM Meru Patel notifications@github.com wrote:
Adding GIF support seems nice but it has some drawbacks
https://gamedev.stackexchange.com/questions/130580/why-dont-most-major-game-engines-use-gifs-for-animated-textures
.
Perhaps, AnimatedSprite
https://docs.godotengine.org/en/3.1/tutorials/2d/2d_sprite_animation.html
is more suitable in this case.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot-proposals/issues/475?email_source=notifications&email_token=ABBEIS7VG74ZXX7LV6RH6A3RC7VN7A5CNFSM4KVGQ57KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3KU5Y#issuecomment-586590839,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBEIS6VUV4OH4TRBCKTMTLRC7VN7ANCNFSM4KVGQ57A
.
I am not clear what you are trying to say. Do you want one animation per GIF or all animation in ONE GIF? The first one can be implemented with AnimationSprite. The second one is overkill.
I pray for GIF support in godotengine/godot#31831. 🙂
I'm glad this proposal is alive ^_^
If Godot gets the ability to use indexed palettes natively (using gifs, or indexed pngs, or act palette files, or any other straightforward method), I think it would instantly become the best engine for modern pixel art games.
I really look forward to it! :D
See also #1433 and a more underlying #1448 proposals to help this.
If Godot gets the ability to use indexed palettes natively
This is unlikely to be implemented in core, because indexed image support was removed by the lead developer some time ago (in Godot 3.0), under the justification of that modern GPUs don't support indexed images.
I'm developing a module which acts as an extension for Godot which does provide ImageIndexed classes, and even recently ported the GIF loading and import support, see goostengine/goost#8 (big credits to the original author who made this in godotengine/godot#31831). Of course there are a lot more which can be done on the editor side, this only provides core functionality, and I'm not using those features for pixel-art use cases myself to be honest.
The idea isn't to support gifs and apngs as formats in engine, but to support them in the importer to improve the workflow of 2D developers.
If you ask for import features, then this also implies loading support of those image formats as well. On the contrary, the loading part can be implemented alone in the engine, so that you're free to use those animated image loaders to implement your own importers of your liking (AnimatedTexture, SpriteFrames, AnimatedSprite, AnimationPlayer etc.) via editor plugins, which should be quite possible to do via script.
This is why I went for alternative proposal in #1448, so the engine can facilitate those use cases on the core level, but not necessarily implement them.