# Why don't most major game engines use gifs for animated textures?

What is better to use Animation Sheets or Gifs? One advantage Gifs have over Animation Sheets is that you don't have to think about frames going too fast or too slow because of your code and updating in proper ticks.

What are the disadvantages to using Gifs and advantages Animation Sheets have over Gifs?

• Then perhaps you should reword your question to something like "Why don't most major game engines use gifs for animated textures?" as they aren't commonly, at least that I know of, for good reasons. I think that'd give you technical points on why they aren't used versus a which is better question, which are not appropriate for SE sites. – Coburn Sep 27 '16 at 14:04
• One advantage Gifs have over Animation Sheets is that you don't have to think about frames going too fast or too slow Why that? On what are you relying to make that assumption? A library? The file format specification? A gif file is still just data, you still need code to interpret it (render it at the correct speed) – hoffmale Sep 28 '16 at 3:37
• What hoffmale said. GIFs aren't magic; their animation still needs to be controlled and executed by some software, including its timing, and in this case, that software is written by you. Honestly I wouldn't expect your Animation Sheet handling code to differ a huge amount from your GIF handling code. – Lightness Races in Orbit Sep 28 '16 at 10:25
• The only difference between your spritesheet and GIF code, is that your GIF code will convert the GIF into a spritesheet and then call the spritesheet code ;) – MickLH Sep 28 '16 at 15:36
• gif doesn't have any advantages. if you want inter-frame compression, then gif is approximately 30 times less efficient than a proper video codec, while also giving worse quality (for photorealistic stuff). – Display Name Sep 28 '16 at 15:50

GIF drawbacks:

• very limited color palette, typically 256 colors with ugly dithering (yes, you can have more than 256 colors in animated GIF, but this is uncommon)
• GPUs don't support GIF compression in hardware (means you will have to unpack them on CPU anyway)
• you only get to pick ONE color for transparency (unless implementing custom processing)
• no random access. All preceding GIF frames need to be read and decompressed to access a frame.
• being compressed. You need dedicated decompression function in code. You can't choose different (better) compression algorithms. (yes, uncompressed GIFs exist too, but this is uncommon)

With custom format all these items get resolved very quickly. You have much more control over image format, quality, transparency, random access and compression (including GPU-supported formats alike DXT). Even better, you can prioritize features you need.

One advantage Gifs have over Animation Sheets is that you don't have to think about frames going too fast or too slow because of your code and updating in proper ticks.

Above statement is misleading. Syncing GIF fps with actual game fps is not much different than syncing custom sprites animation. In both cases you have exactly the same setup - a list of frames, desired framerate and render events. There is no magic powder in GIF - you will have to decompress GIF into spritesheet anyway, which defeats the purpose.

Of course some game engines may hide some of GIF issues behind the curtains, but then, same can be done with spritesheets in a better way.

Said that, there are some few cases where GIFs could kind of work. E.g. HTML/CSS GUIs, but these are quite rare and resource-hungry by themselves.

• I don't understand "one color for transparency." What does it mean to have multiple colors for transparency? Are you talking about varying alpha values like applying a transparency gradient across a texture? – Erik Sep 28 '16 at 21:53
• @Erik exactly that. Common GIF supports up to 256 colors, out of which just 1 can be marked to be transparent. Unlike other formats, where transparency typically has much wider range. – Kromster Sep 29 '16 at 4:16
• @Kromster Actually, resource savvy sites use custom animation mechanism for animated images, such as CSS background-image position animation where the animation is palced on one big image, which is then moved by offsets. – Tomáš Zato - Reinstate Monica Sep 29 '16 at 9:52
• @TomášZato True. Sorry, did I state otherwise? – Kromster Sep 29 '16 at 10:36
• @luk32 this is a drawback because there are much better compression methods than old GIF compression. So you either use suboptimal GIF compression or get to (de)compress twice (note that compressing already compressed data generally yields larger size too). – Kromster Sep 29 '16 at 11:02

In order to use any image file as a texture in a game, there must be a texture created on the GPU and the pixel data in the image file must be loaded to that texture.

GPUs do not support many of the features that image files on CPUs support. They don't support JPG compression, they don't support PNG compression, and with particular reference to GIFs, they don't support auto-animation.

So even if you did use a GIF file, you would still have to write your own animation and timing code anyway. GIF gives you nothing.

• Note that "CPUs" don't support those things, web browsers and operating systems do. – user253751 Sep 27 '16 at 21:33
• What, nobody's written a GPGPU web browser yet? – Camille Goudeseune Sep 28 '16 at 20:52
• @CamilleGoudeseune You laugh. I cry. – 3Dave Sep 29 '16 at 12:49

GIF has a limited color palette. (255) You have to implement parsing and animating the GIF too. So there is not a advancement in time nor in format's technical aspects.

• 256 if you don't need transparency, 255 effective otherwise. – a CVn Sep 28 '16 at 15:17
• @MichaelKjörling It's still 256 with transparency - just one of the colors is designated "transparent." I believe that information is stored in the header. – 3Dave Sep 29 '16 at 12:51
• @DavidLively Hence "effective". The color is still there, but it can't be used as a opaque color. – a CVn Sep 29 '16 at 13:14
• @Kromster yeah. Deleted. I can has good maths. – 3Dave Sep 30 '16 at 14:28