Handling animations with high FPS and large resolutions
xyz I actually managed to solve it in the meantime with the idea that I mentioned at the end:
I was toying with the idea to just change textures of Sprite2D through some sort of function in a script which I would call at the beginning of animation in AnimationPlayer.
Basically I have a dictionary linking animation name to a directory holding all frames. I load these frames on _ready, and map it in another dictionary to said animation name. Then in AnimationPlayer, I just call the function with the animation name and the desired duration of the animation.
I assume it would be better performance wise to preload these in the future?
Anyway, here's one of the sprites so I don't end up uploading a huge amount 
. 
xyz Could you elaborate what you meant here?
The sprite I sent is one of the frames of the animation I made in Synfig Studio. If you are saying that because of the simplicity of the sprite - its a placeholder, but the final sprite and animation will require a bit more tuning and mixing of frame by frame animation and skeletal animation. Most likely, I will require the morphing feature of Synfig Studio as well.
I think it would look quite messy if I tried to do it through Godot (if its even possible). Either way, it seems like Synfig Studio provides a bit more options for animating than Godot, but I am no expert so please correct me if I am wrong
- Edited
Perfex Also, in your opinion, what are the drawbacks of using this type of animation that I am using?
It will eat up vram quite quickly. Calculate it. One 1024x1024 rgba bitmap is 4 megs. Maybe a bit less if you use vram compression. Multiply that with the total number of frames you plan to have in the game and that's the amount of memory you'll consume on the gpu. This is extremely wasteful especially with so many whitespace pixels that could have been used to store other bitmap data.
This is normally done with every body part being a separate sprite. That would also make collider management and animation much easier.
xyz You have a valid point.
In that case, do you have any suggestions on how to handle a more complex animation that doesn't involve just skeletal animation?
I did some research and came across a Spine to Godot integration - do you think that doing the animation in Spine project and then importing that project into Godot would solve these memory issues?
The problem here is that Spine is quite expensive of course
- Edited
Perfex Depends what you mean by "more complex animation". The main idea here is to minimize the vram consumption by not wasting it on blank pixels, or stuff that repeats or stuff that can be animated via linear transformations (translation, rotation, scaling). Of course, if you want to have non linearly animated parts other than standard skin deformations, like morphing or motion blurring, you obviously need to do it via frame-by-frame animation, but it's best to isolate such parts into smallest possible bitmaps and include them as separately animated sprites into overall multi sprite hierarchy of your character.
- Edited
Perfex Could you elaborate what you meant here?
It's worth a note here that @xyz is suggesting skeletal animation here because this specific example sprite you've provided lends itself well to a skeletal cutout animation. If you were dealing with something like CupHead style sprites & animation the discussion would be very different.
- Edited
Megalomaniak I hinted on plain node hierarchy fk as well. The important thing is to cleverly break the character down into multiple parts and animate them in the most appropriate/economic way, possibly mixing the animation techniques. Even cuphead likely does that. Those long noodle arms are surely not in the same bitmap with the head etc.
xyz @Megalomaniak In that case, I suppose some blend of frame-by-frame animated character parts with skeletal animation in Godot could do the trick in this case.
This was a very helpful discussion I must admit.
Thanks a lot , I will most likely try out the Godots skeletal animation along with the frame-by-frame animation for parts in the end and see how it goes!