Why do they use storyboard in 2D games instead of GIF animation?

Disadvantages of gif :

• very limited color palette: usually 256 colors with poor anti-aliasing. (Yes, you can use more than 256 colors , but these are very rare cases)
• GPUs do not support GIF compression (compression), which means that one way or another it will have to be unpacked and at the same time due to the central processor (CPU)
• for transparency, you can use only ONE color (unless you are doing your individual processing)
• no random access: to access the desired GIF frame - it is necessary to read and decompress the previous ones
• You need to have a special function in the code for decompression. You cannot select other (best) compression algorithms (yes, uncompressed GIFs also exist , but these are quite rare cases)
• does not support vector graphics.

When you work with your format, all issues are resolved quickly. You have more control over image format, quality, transparency, random access and compression (including DXT, which support GPUs). In addition, you can prioritize the functions you need.

Some people think that GIF has an advantage over sprite lists, supposedly you don’t need to worry that the frame will go too fast or too slow and try to correct the speed in the code. But it is not. Synchronization frame rate GIF animation and synchronization with animation sprite sheets is not much different. In both cases, you will have to know and manipulate the list of frames, set the desired frame rate and work with rendering events (rendering). GIF - will not create magic, to achieve the goal, in any case, you will have to unpack the GIF in the sprite list.

Perhaps the only place where you don’t need to worry about frames is the HTML / CSS GUI , but they are now used there quite rarely ... well, they are resource-intensive.

+

As I wrote in the commentary, in a simpler language: you have a GIF- animation flashing lights on the police and fire truck. At some point, you decided that flashers are spinning too fast ... Reassemble a GIF ? Not an option. And if you did not like it again?

And if the character must move quickly, then slowly (for example, slow mo). And if a character makes a series of blows (combo), and he can stop at any of the series of blows, as well as each animation of his interrupted combination is his own (example of a combination: UMK3 ultimate - Liu Kang - 4 kicks. The animation of the return of the leg is different). Question: cut all sorts of combinations GIF ?

In addition, where should the process of playing hyphal animation take place? The game is a process of redrawing the scene. About 60 times per second (plus / minus). Where exactly should the GIF be located to start the animation from the same moment it was interrupted after updating the scene rendering? Or how should it sync? All this translates into a big headache.

_{gamedevSE small translation}

This question is incorrect. There are no mutually exclusive "storyboard" and "GIF-animation" methods. There is no "not." These are orthogonal concepts. Correctly put the question like this:

Why don't they keep storyboard in GIF format in 2D games?

When you are in a game, you work with bits and bytes of graphics that are in a “hardware” state. This is usually either uncompressed graphics (variation ARGB, for example), or compressed with a supported hardware (that is, video card) algorithm (variation DXT, for example).

A storyboard is several images (usually animation frames) that can be either on the same texture (one "plane" of bytes) or on several. Placing graphics on a single texture is optional, but it has some advantages, for example, more rational slips into the hardware-optimal texture dimensions.

GIF is a format for storing data on a disk. Conventionally, it contains frames and delays between them, but in general this is a tricky format with line-by-line data storage and various transition algorithms between frames (for example, "roll back the state to the previous frame, impose the next one with transparency and a different palette"). This format has nothing to do with how the data is displayed in modern computers on modern hardware.

Sometimes it seems that the GIF "just works." This is not true. Inside the programs there are components that extract frames into a hardware view and, according to the algorithms, display them on the screen by timer.

When you write a game, you manage everything yourself. You no longer have separate "animations", you have a clear state of each object, along with all the frames of all the elements at every single point in time, at every frame. You have complete control over which frame of the animation is displayed at the beginning of the jump after the run.

Now in essence: GIF animations can be used for storyboards, but this is rarely done due to the horrific limitations of the GIF format , which are listed in another answer.

In today's world, formats that store graphics directly in hardware are commonly used. This allows the download to be very fast, but it requires a lot of memory, because compression is weak. Some games can go alternatively, for example, Braid stores graphics in JPEG, with the transparency channel in a separate file. If you want to optimize disk space by sacrificing download time, and your graphics are best compressed with GIF, and without loss, then using GIF to store animation frames can be rational .

Separately, it should be noted engines based on HTML . There GIF really works out of the box. However, even there GIF restrictions continue to operate: as a format restriction in the form of a limited palette, and restrictions in the control of offal in the form of lack of control over the current frame, and so on. Even in HTML, using GIF makes sense in very limited cases: if the image fits perfectly with the format restrictions, but precise control is not needed. This happens rarely, in difficult games - never.