I am developing a game in C using SDL2 and my problem is that the game is FullHD and has long (180 frames) character animations that generate very big spritesheets. I have a spritesheet that is 7326x7250px that I must break down into sixteen 2048x2048px ones so I can play it on tablets (their maximum texture size is, on a lower bound, 2048x2048).
With this problem in mind I ended up wondering if it would be better to store the animations in video files and load every decoded frame into the GPU. I know of the overhead of decoding the video frame and of the overhead of switching textures on the GPU (with the sixteen 2048x2048 textures I was able to store them in a single texture array, retaining the GPU state during the animation). Has anyone tried this and succeeded?
Using video files in this way would sacrifice simplicity, performance, image quality, and surprisingly memory (you'd need to stream a portion of the video, convert it into a bitmap, then upload that bitmap to the graphics card).
Pretty much the only gain would be a smaller filesize, which I don't think is worth any of those penalties alone, let alone all of them together. You'd still have the same texture limitation, (perhaps the SDL2 api hides this implementation detail when using video, but it's still a limit all the same)
I wouldn't worry about switching textures too much because as an animation, you'd only be potentially switching textures once per frame (and considering you'd be switching textures mid-frame to draw other objects anyway, this wouldn't affect performance at all) That is, unless you have multiple characters using the same sprite sheet in different animation states, but even then it'd be easier to group them together based on texture to reduce switching.