Войти
ПрограммированиеФорумОбщее

Выбор способа сжатия ресурсов игры (lzma2, lzham, lzmh, lzo, lz4, snappy/yappy и т.д.)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 Следующая »
#0
19:05, 19 июня 2011

Вопрос простой. Что выбрать? :)
И вообще, кто что использует?
Ещё пару-тройку лет назад можно было не заморачиваться и паковать всё deflate-ом в zip по старинке. А счас, я смотрю, такая куча алгоритмов нарисовалась/заопенсурсилась, что аж глаза разбегаются! :)
Ну, юзать zlib в настоящее время, как я понимаю, вообще не вариант. Старый архаичный код deflate, писавшийся ещё для 16-разрядных процессоров, уступает по всем параметрам (скорость сжатия/распаковки, степень сжатия) первому пришедшему в голову Deflate64.

Вообще, требуется найти 3 алгоритма для соответствующих типов данных (ресурсов):
1. Загружаемые по инету ресурсы (в т.ч. патчи для системы обновлений). Тут я выбрал lzma2. Думаю, больше альтернатив особо и нет.
2. Обычные ресурсы (в пак-файлах), загружаемые с диска. Требования: скорость распаковки, не медленнее скорости чтения HDD (т.е. минимум 70 Мб/с, а лучше 100 Мб/с, zlib даёт лишь 40-60 Мб/с, lzma - 10-30, но это ещё от типа данных зависит), т.е. чтобы данные могли на лету при чтении потоково распаковываться без перерывов, скорость компрессии: не принципиально, степень сжатия: не хуже zlib.
Лучший вариант - lzmh (декомпрессия в 4 раза быстрее lzma, в 2 раза быстрее lzham при степени сжатия, сопоставимой с lzma), но, к сожалению, этот алгоритм находится в каком-то подвешенном состоянии (непонятно, что с лицензией, и вообще, какова его стабильность и т.д.). Ещё неплох lzham, но опять же статус alpha смущает, да и скорость распаковки лишь немного превосходит zlib.
3. Ресурсы, загружаемые с диска (тоже из пак-файлов), но кешируемые в оперативной памяти и распаковываемые при необходимости. Требования: очень высокая скорость декомпрессии, скорость компрессии: не принципиально, степень сжатия: не высокая, но желательно на уровне lzo или lz4.
Варианты: lzf, lz4, snappy, yappy. Отдал бы предпочтение последнему, если бы было больше ясности, что там со стабильностью/требованиями алгоритма и, вообще, с развитием проекта (Петька, даёшь opensource-проектик в google.code! :) )


#1
19:22, 19 июня 2011

Если интересует мое мнение, то я выбрал zlib, просто, доступно, и хорошее сжатие ( даже для передачи по сети данных ). Что еще нужно? А новые алгоритмы в мире сжатия придумать трудно, здесь прогресс может идти десятилетиями.

#2
20:16, 19 июня 2011

Принципиально новое конечно придумать трудно, но новых улучшений над известными старыми алгоритмами - полно. Зачем использовать алгоритм 15-летней давности, если есть куча его улучшенных версий, учитывающих современную архитектуру процессоров, а также объединяющие преимущества разных алгоритмов и использующие оригинальные подходы? Причем улучшения "старого" дают в результате увеличение скорости декомпрессии в несколько раз с такой же или даже большей степенью сжатия.
Лучшее - враг хорошего. :)

#3
1:03, 20 июня 2011

Жать вообще не надо. Ассеты надо собирать просто в один большой файл. Ресурсы собирают в один контейнер, чтобы не тормозило чтение кучи мелких файлов. Сжатие, как таковое, нужно только в исключительных случаях.

#4
3:09, 20 июня 2011

asfdfdfd
> Жать вообще не надо
Fail. Данные в пак фале нужно жать независимо, чтобы можно было прочитать ресурс и его расжать.

#5
9:17, 20 июня 2011

1. Можно ещё посмотреть bzip2 (pbzip2). На текстовых данных он жмёт лучше чем lzma, но распаковывает значительно медленнее.

2. Вменяемые конкуренты zlib --- мне неизвестны.

3. Я не уверен в разумности хранения в памяти упакованных данных. Это дублирование дискового кэша операционной системы.

P.S. Упаковка ресурсов в один файл --- это часто правильно.

#6
22:27, 20 июня 2011

asfdfdfd
> Ассеты надо собирать просто в один большой файл.
Это не противоречит сжатию. Я, например, сделал для startup-данных (файлы, которые всегда загружаются при каждом запуске игры) что-то вроде tarball или solid архива, т.е. это логически по-прежнему много маленьких файлов, которые получаются через loadFile в разных местах, но физически они объединены в один непрерывно сжатый пак-файл, который сначала читается-распаковывается в память, а затем, когда все файлы были прогружены и разложены по объектам/текстурам, память, выделенная под этот пак, освобождается целиком.
Во всех остальных паках, файлы сжаты по отдельности.
Вообще, сжатие оправдано всегда (с целью уменьшения времени загрузки ресурсов), вопрос лишь какое. В идеале, для каждого типа ресурсов нужно использовать свои алгоритмы, но на практике таким обычно никто сильно не заморачивается. DDS-текстуры, меши/модельки итак неплохо жмутся алгоритмами сжатия общего назначения.

nbkolchin
> Я не уверен в разумности хранения в памяти упакованных данных. Это дублирование дискового кэша операционной системы.
Дисковый кэш системы Windows - феноменальное УГ, да простят меня товарищи из Microsoft. Из-за по-дурацки реализованного копирования с частыми переходами kernel в user-mode и обратно (один переход в ядро - порядка 5-10 тыс. тактов) скорость чтения полностью закешированного файла не превышает 250 Мб/с, что уже сливает последним SSD.
Лучше читать файлы в обход такого кэша (с FLAG_NO_BUFFERING), и использовать свой файловый кэш, который даст практически мгновенный доступ к закешированным файлам. Единственный серьёзный минус (особенно во время разработки), что повторные запуски приложения будут так же медленны, как и первый.
Впрочем, виндовый кэш не сильно мешает, и читать файлы можно и через него. Но небольшой свой кэш на 64-128 Мб уже даёт ощутимый буст по сравнению с гигабайтным виндовым.

#7
23:17, 20 июня 2011

Расскажи про сжатие чувакам из ААА-тайтлов. 20 ГБ после установки? Фигня! 2 DVD диска на дистриб? Фигня!

#8
11:39, 21 июня 2011

а я взял QuickLZ. Запаковал все ресурсы (20 мегабайт) а скорость загрузки такая же осталась как и при распакованных ресурсах. Очень остался им доволен, т.к. не пришлось ещё вставлять анимированную крутилку. 
Правда, png файлы сжимает так что они на 10 байт больше становятся, зато не видно заголовка для PNG файла при просмотре общего pak файла( т.к. они хранятся в файле поочереди, то по заголовку можно найти начало и конец файла таким образом вырезав графику)
А вот если обычные конфиги xml-овские пакует в два раза, что есть гуд, т.к. опять же открыв pak файл, то читаемого текста не найти, что и хотелось получить в результате. Так что советую попробовать.
В использовании вообще простой, всего 4 функции, запаковать распаковать и узнать размер запакованного и распакованного файла.

#9
12:08, 21 июня 2011
в этом году уже обсуждали тему и где-то есть ссылка на табличку сравнения скорости для разных типов данных - поиск по форуму поможет
#10
20:13, 21 июня 2011

хороший тред.

#11
20:51, 21 июня 2011

ааа-тайтлы вроде s.t.a.l.k.e.r так делают и я так делаю. использую практически в неизмененном виде, только мэйн отломал, убрал запись в файл и обернул в класс.

#12
21:16, 21 июня 2011

evirus
http://altdevblogaday.org/2011/04/22/survey-of-fast-compression-a… ithms-part-1/

Вообще судя по этому бенчмарку, лучше всего подходит snappy, плюс имеется поддержка библиотеки гуглом
А yappy был сделан как драфт к идее, iirc (да простит уж меня IronPeter). Если доделаете его до нормальной библиотеки, то будет просто замечательно

#13
22:28, 21 июня 2011

KpeHDeJIb
> Расскажи про сжатие чувакам из ААА-тайтлов. 20 ГБ после установки? Фигня! 2 DVD
> диска на дистриб? Фигня!

The following algorithms are currently in use by Blizzard games:

    PKZIP (licensed from PKWARE). The first compression algorithm available.[citation needed]
    Huffman tree compression combined with ADPCM 4:1 compression (both introduced in StarCraft). Latter algorithm is lossy and only suitable for raw PCM input data.
    zlib (introduced in Warcraft III).
    bzip2 (introduced in World of Warcraft).
    LZMA (introduced in StarCraft II).

#14
22:43, 21 июня 2011

tav
> корость чтения полностью закешированного файла не превышает 250 Мб/с,

Это не так. Проверил на XP и семёрке. При чтении по 16 килобайт было около 3.5GB/s на warm cache. В Linux --- 5.5Gb/s.

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.