Почему в 2D играх используют раскадровку, а не GIF анимацию?

#разработка_игр #анимация #спрайт

Решил для самообразования создать простенькую 2D игру. Встал вопрос: 
почему люди используют раскадровки, а не готовые GIF? 
    

Ответы

Ответ 1

Недостатки GIF:


очень ограниченная цветовая палитра: обычно это 256 цветов с плохим сглаживанием.
(да, можно использовать и больше 256 цветов, но это очень редкие случаи) 
графические процессоры (GPU) не поддерживают сжатие (компрессию) GIF, а это значит,
что так или иначе её придется распаковывать и при этом уже за счет центрального процессора
(CPU)
для прозрачности вы можете использовать только ОДИН цвет (если только не выполняете
свою индивидуальную обработку)
нет произвольного доступа: для доступа к нужному кадру GIF - необходимо произвести
чтение и декомпрессию предыдущих
вам нужно иметь в коде специальную функцию для декомпрессии. Вы не сможете выбрать
другие (лучшие) алгоритмы сжатия (да, несжатые GIF тоже существуют, но это довольно
редкие случаи)
не поддерживает векторную графику. 


Когда вы работаете со своим форматом, то все вопросы решаются быстро. У вас больше
контроля над форматом изображения, качеством, прозрачности,  произвольным доступом
и сжатием
(включая DXT, которые поддерживают GPU). Кроме того вы можете определить приоритеты
нужных вам функций.

Некоторые думают, что у GIF есть преимущество относительно спрайт-листов, якобы не
нужно переживать, что кадр будет идти слишком быстро или слишком медленно и пытаться
выправить скорость в коде.
Но это не так. Синхронизация частоты кадров GIF анимации и синхронизация с анимацией
спрайт-листов не сильно отличается. 
В обоих случаях придется знать и манипулировать списком кадров, устанавливать желаемую
частоту кадров и работать с событиями рендеринга (отрисовки). GIF - не создаст магии,
для достижения цели
вам в любом случае придется распаковывать GIF в спрайт-лист.

Пожалуй единственное место, где не нужно переживать за кадры - HTML / CSS GUI, но
и они сейчас применяются там довольно редко...ну и ресурсоёмкие они

+

Как я писал в комментарии, более простым языком: есть у тебя GIF-анимация мигалок
на полицейской и пожарной машине. В какой-то момент ты решил, что мигалки слишком быстро
крутятся...Пересобирать GIF? Не вариант. А если опять не понравилось? 

А если  персонаж должен двигаться то быстро, то медленно (например slow mo). А если
персонаж делает серию ударов (комбо), причем остановится может на любой из серии ударов,
а также каждая анимация
у прерванной комбинации своя (пример комбинации: UMK3 ultimate - Liu Kang - 4-ре
удара ногами. Анимация возврата ноги - разная). Вопрос:  нарезать всевозможные комбинации
GIF? 

К тому же, где должен происходить процесс воспроизведения гиф-анимации? В игре происходит
процесс перерисовки сцены. Около 60 раз в секунду (плюс/минус). 
Где именно должна располагаться GIF, чтоб начинать анимацию с того же момента, с
которого была прервана после обновления рендеринга сцены? Или как должна синхронизироваться?
Всё это выливается в большую головную боль.



небольшой переводик с отсебятиной gamedevSE


Ответ 2

Вопрос некорректен. Не существует взаимоисключающих методов "раскадаровка" и "GIF-анимация".
Нет никакого "а не". Это ортогональные понятия. Правильно вопрос поставить так:

Почему в 2D играх не хранят раскадровку в формате GIF?

Когда вы находитесь в игре, вы работаете с битами и байтами графики, которые находятся
в "аппаратном" состоянии. Обычно это либо несжатая графика (вариация ARGB, например),
либо сжатая поддерживаемым аппаратно (то есть видеокартой) алгоритмом (вариация DXT,
например).

Раскадровка — это несколько изображений (обычно кадров анимации), которые могут как
находиться на одной текстуре (одной "плоскости" байтов), так и на нескольких. Расположение
графики на одной текстуре необязательно, но имеет некоторые преимущества, например,
более рациональное впихивание в аппаратно оптимальные размеры текстуры.

GIF — это формат хранения данных на диске. Условно он содержит кадры и задержки между
ними, но вообще-то это мудрёный формат с построчным хранением данных и разнообразными
алгоритмами перехода между кадрами (например, "откатить состояние до предыдущего кадра,
наложить следующий с прозрачностью и другой палитрой"). Этот формат не имеет ничего
общего с тем, как данные отображаются в современных компьютерах на современном железе.

Иногда создаётся впечатление, что GIF "просто работает". Это не так. Внутри программ
находятся компоненты, которые извлекают кадры в аппаратный вид и согласно алгоритмам
выводят их на экран по таймеру.

Когда вы пишете игру, вы всем управляете сами. У вас больше нет разрознённых "анимаций",
у вас есть чёткое состояние каждого объекта вместе со всеми кадрами всех элементов
в каждый отдельный момент времени, в каждый кадр. У вас полный контроль над тем, какой
кадр анимации отображается при начале прыжка после бега.

Теперь по сути: GIF-анимация может использоваться для раскадровки, но это редко делается
из-за ужасающих ограничений формата GIF, которые перечислены в другом ответе.

В современном мире обычно используются форматы, которые хранят графику прямо в аппаратном
виде. Это позволяет делать загрузку очень быстрой, но требует довольно много памяти,
потому что сжатие слабое. Некоторые игры могут идти альтернативным путём, например,
Braid хранит графику в JPEG, причём канал прозрачности в отдельном файле. Если вы хотите
оптимизировать место на диске, поджертвовав временем загрузки, и ваша графика лучше
всего сжимается GIF, причём без потерь, то использование GIF для хранения кадров анимации
может быть рациональным.

Отдельно надо отметить движки на базе HTML. Там GIF действительно работает "из коробки".
Однако даже там продолжают действовать ограничения GIF: как ограничение формата в виде
ограниченной палитры, так и ограничения в контроле над потрохами в виде отсутствия
контроля над текущим кадром и так далее. Даже в HTML использовать GIF имеет смысл в
очень ограниченных случаях: если изображение идеально ложится в ограничения формата,
а точный контроль не нужен. Это случается редко, в сложных играх — никогда.