PrecompInside

CLS PrecompInside 0.3.1

Нет прав для скачивания

ProFrager

Знаток
Проверенный
Пользователь ProFrager разместил новый ресурс:

PrecompInside - CLS-фильтр (библиотека) для FreeArс.

CLS-фильтр (библиотека) для фриарка, предназначенный для распаковки precomp архивов параллельно распаковке lzma (в архивах со сжатием -mprecomp+lzma), что прилично увеличивает общую скорость распаковки на 2хядерных и более системах (где-то в 2 и более раза).

В папке pack находится пример батника и данных для упаковки в .arc архив. Упаковка стандартная - с последовательной обработкой precomp'ом и lzma.
В папке unpack находится пример для распаковки данных с помощью unarc.exe. lzma и precomp...
Узнать больше об этом ресурсе...
 

ProFrager

Знаток
Проверенный
Snoopak96, спасибо, поправил.

Обновил до PrecompInside v0.1.3 - исправил некорректную обратную упаковку png.
 

ProFrager

Знаток
Проверенный
я не понял - как создан CLS-precomp.dll? ведь исходников precomp нет
Исходников то нет, но они и не требуются. Тут в общем то основной составляющей является packjpg_dll.dll - замена оригинальному, которая и выполняет все основные функции по передаче данных между процессами cls фильтра и прекомпа.
Принцип примерно такой: работа прекомпа была изучена в дебагере и на основе анализа сделал библиотеку packjpg_dll.dll, которая патчит все основные функции в таблице импорта precomp.exe в памяти при загрузке (типа fprintf, read, write и т.д.) и перенаправляет их на свои. Далее процессы cls фильтра (unarc.exe, arc.exe или иснталлер инно, не важно) и precomp.exe обмениваются данными через shared memory, синхронизированные сообщениями эвентов. Как-то так. Это все обеспечивает универсальность метода для работы со всеми версиями прекомпа и без нарушения авторских прав Шнайдера.
 
Последнее редактирование:

Snoopak96

Старожил
ProFrager,
Можно добавить в arc.ini -t-j и откинуть packjpg_dll1.dll вообще? в них путаешься)
Сегодня делал полный набор: JPEG, GIF, PNG, PDF и прочие Zlib - вроде как полностью нормально распаковывается, можно как-нибудь скорости добавить, я так понимаю precomp всего одно ядро грузит во время распаковки? И терзает вопрос меня) почему mem=10 - этого достаточно или можно увеличить?
 

ProFrager

Знаток
Проверенный
Можно добавить в arc.ini -t-j и откинуть packjpg_dll1.dll вообще? в них путаешься)
можно)

Сегодня делал полный набор: JPEG, GIF, PNG, PDF и прочие Zlib - вроде как полностью нормально распаковывается
гуд

можно как-нибудь скорости добавить, я так понимаю precomp всего одно ядро грузит во время распаковки?
а тут уж ничего не поделать, алгоритм в прекомпе таков, что только в один поток можно реализовать, тем более учитывая необходимость непрерывности входного и выходного потока для cls фильтра. Разве что 4x4 перед всей цепочкой поставить, но тогда и количество необходимой памяти для распаковки увеличится в разы) Зато распаковка на 4хядерных такчках будет гораздо шустрее. А в основном имхо у юзеров 2хядерные процы, так что для precomp+lzma и заморачиваться не стоит.

И терзает вопрос меня) почему mem=10 - этого достаточно или можно увеличить?
это вообще от балды) да и можно удалить, ничего не изменится. Для распаковки прекомпа все равно будет требоваться 15мб и более оперативки. А на сколько более уже зависит от данных (до 300мб и выше). Но в основном порядка 20мб.
 
Последнее редактирование:

Булат Зиганшин

Developer
Модератор
почему mem=10 - этого достаточно или можно увеличить?
это инфа для FA - сколько этот алгоритм использует памяти, чтоб он мог разобраться, какие алгоритмы можно параллельно запускать. на работе самого precomp это понятно никак не отразится
 

ProFrager

Знаток
Проверенный
PrecompInside v0.1.4
-исправил ошибку, возникающую при частичной распаковке архива (например unarc.exe с опцией -ap)

P.S. спасибо Snoopak96 за багрепорт :)
 

ProFrager

Знаток
Проверенный
PrecompInside v0.1.5
ссылка и изменения в шапке.

P.S. и как всегда спасибо Snoopak96 за багрепорт :)
 

Snoopak96

Старожил
ProFrager,
Можно ли как-нибудь всё таки управлять памятью прекомпа во время распаковки или это не управляемый параметр? спрашиваю по тому что при больших архивах сам понимаешь сколько там памяти нужно и получается, что не возможно совместить с lzma+SrepInside.
Или остаётся как вариант делить по блокам внутри arc`а, но наверно степень сжатия пострадает.... тогда какой размер блока брать по максимуму можно, чтоб память оставалось в пределах 128-256мб?
 

ProFrager

Знаток
Проверенный
разве что temp файл создавать и туда скидывать данные, а иначе никак. В данной цепочке (precomp+srep+lzma) лучше всего активней использовать своп для самого быстрого алгоритма, т.е. для srep'а. Если же в precomp'е сделать подобное, то процесс будет тормозиться обращениями к файлу, т.к. он является самым медленным из цепочки. Оставь для srep'а метров 256 вместо 512, производительность вряд ли изменится. А количество используемой памяти в precomp не зависит от размера данных, а зависит только от того, как были изначально упакованы данные. Если авторы сделают слишком большие блоки данных, то и загрузка игры будет слишком долго длиться, что не приемлемо, поэтому такие архивы редко встречаются (т.е. не часто встречаются малограмотные в плане оптимизации игроделы).

Добавлено через 2 минуты
да и не разделишь солид блоки в арке на определенный нужный тебе размер, ибо там солиды бьются только при пересечении на границах файлов, на сколько я помню. Поэтому если пакуешь 2 файла по 1 гигу, то никак не сделаешь 4 солид блока по 500метров.
 

Snoopak96

Старожил
ProFrager,
Тогда не понимаю как тогда сделать, у меня выходило вот так распределение памяти при распаковке:

256 мб (Законные LZMA) + 256 (Cls-srep) + 400 мб (Cls-precomp) + 60 мб (Хвост который появляется на практике, в теории его не должно быть)

Многовато выходит.
 

ProFrager

Знаток
Проверенный
Да, 400мб - многовато. Это что ты такое пакуешь? Значит придется делать менеджер памяти наподобие как в srep дабы часть данных скидывать на винт. Но с другой стороны я для того и делал cls фильтр, чтобы распаковка precomp'а была без промежуточных файлов. Но в принципе потерь во времени должно быть не много.
 

Winst@n

Старожил
Проверенный
ProFrager,
Может задам странный вопрос. Но все же задам. Можно ли как то объединить все это дело в один поток (precomp + srep = arc).
 

1noObman1

Пользователь
ProFrager, можно ли как-то указать фа чтоб в цепочке precomp+srep+lzma он расжимал, например все файлы .ff, прекомпом, а потом уже их в арк без сжатия и srep+lzma? А то он сначала пакует темп-файл без сжатия и потом на него натравливает прекомп.
 

ProFrager

Знаток
Проверенный
1noObman1, нет,нельзя, чтобы все данные были в одном солид блоке, все алгоритмы должны полностью обработать данные. На скорости распаковки это никак в общем то не повлияет, т.к. в файлах, в которых прекомп ничего не нашел данные будут просто копироваться без каких либо задержек. А вот скорость упаковки конечно сильно будет страдать.
 

1noObman1

Пользователь
ProFrager, эт хорошо, но столкнулся с проблемой. Запаковал данные с цепочкой precomp+srep+lzma и теперь при распаковке выкидывает табличку с ошибкой "Not an srep compressed file". Как быть?


Всё, разобрался. Проблема была в arc.ini.
 
Сверху