Пользователь ProFrager разместил новый ресурс:
PrecompInside - CLS-фильтр (библиотека) для FreeArс.
PrecompInside - CLS-фильтр (библиотека) для FreeArс.
Узнать больше об этом ресурсе...
-
Уважаемые гости и пользователи форума.
Администрация настоятельно рекомендует не регистрировать несколько аккаунтов для одного пользователя. При выявлении наличия мультиаккаунтов будут заблокированы все учетные записи данного пользователя.
Аккаунты, зарегистрированные на временную почту, будут также заблокированы.
CLS PrecompInside 0.3.1
- Автор темы 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 - этого достаточно или можно увеличить?
Можно добавить в arc.ini -t-j и откинуть packjpg_dll1.dll вообще? в них путаешься)
Сегодня делал полный набор: JPEG, GIF, PNG, PDF и прочие Zlib - вроде как полностью нормально распаковывается, можно как-нибудь скорости добавить, я так понимаю precomp всего одно ядро грузит во время распаковки? И терзает вопрос меня) почему mem=10 - этого достаточно или можно увеличить?
можно)
гуд
а тут уж ничего не поделать, алгоритм в прекомпе таков, что только в один поток можно реализовать, тем более учитывая необходимость непрерывности входного и выходного потока для cls фильтра. Разве что 4x4 перед всей цепочкой поставить, но тогда и количество необходимой памяти для распаковки увеличится в разы) Зато распаковка на 4хядерных такчках будет гораздо шустрее. А в основном имхо у юзеров 2хядерные процы, так что для precomp+lzma и заморачиваться не стоит.
это вообще от балды) да и можно удалить, ничего не изменится. Для распаковки прекомпа все равно будет требоваться 15мб и более оперативки. А на сколько более уже зависит от данных (до 300мб и выше). Но в основном порядка 20мб.
Последнее редактирование:
это инфа для FA - сколько этот алгоритм использует памяти, чтоб он мог разобраться, какие алгоритмы можно параллельно запускать. на работе самого precomp это понятно никак не отразится
Snoopak96
Старожил
ProFrager,
Можно ли как-нибудь всё таки управлять памятью прекомпа во время распаковки или это не управляемый параметр? спрашиваю по тому что при больших архивах сам понимаешь сколько там памяти нужно и получается, что не возможно совместить с lzma+SrepInside.
Или остаётся как вариант делить по блокам внутри arc`а, но наверно степень сжатия пострадает.... тогда какой размер блока брать по максимуму можно, чтоб память оставалось в пределах 128-256мб?
Можно ли как-нибудь всё таки управлять памятью прекомпа во время распаковки или это не управляемый параметр? спрашиваю по тому что при больших архивах сам понимаешь сколько там памяти нужно и получается, что не возможно совместить с lzma+SrepInside.
Или остаётся как вариант делить по блокам внутри arc`а, но наверно степень сжатия пострадает.... тогда какой размер блока брать по максимуму можно, чтоб память оставалось в пределах 128-256мб?
разве что temp файл создавать и туда скидывать данные, а иначе никак. В данной цепочке (precomp+srep+lzma) лучше всего активней использовать своп для самого быстрого алгоритма, т.е. для srep'а. Если же в precomp'е сделать подобное, то процесс будет тормозиться обращениями к файлу, т.к. он является самым медленным из цепочки. Оставь для srep'а метров 256 вместо 512, производительность вряд ли изменится. А количество используемой памяти в precomp не зависит от размера данных, а зависит только от того, как были изначально упакованы данные. Если авторы сделают слишком большие блоки данных, то и загрузка игры будет слишком долго длиться, что не приемлемо, поэтому такие архивы редко встречаются (т.е. не часто встречаются малограмотные в плане оптимизации игроделы).
Добавлено через 2 минуты
да и не разделишь солид блоки в арке на определенный нужный тебе размер, ибо там солиды бьются только при пересечении на границах файлов, на сколько я помню. Поэтому если пакуешь 2 файла по 1 гигу, то никак не сделаешь 4 солид блока по 500метров.
Добавлено через 2 минуты
да и не разделишь солид блоки в арке на определенный нужный тебе размер, ибо там солиды бьются только при пересечении на границах файлов, на сколько я помню. Поэтому если пакуешь 2 файла по 1 гигу, то никак не сделаешь 4 солид блока по 500метров.
Да, 400мб - многовато. Это что ты такое пакуешь? Значит придется делать менеджер памяти наподобие как в srep дабы часть данных скидывать на винт. Но с другой стороны я для того и делал cls фильтр, чтобы распаковка precomp'а была без промежуточных файлов. Но в принципе потерь во времени должно быть не много.
1noObman1, нет,нельзя, чтобы все данные были в одном солид блоке, все алгоритмы должны полностью обработать данные. На скорости распаковки это никак в общем то не повлияет, т.к. в файлах, в которых прекомп ничего не нашел данные будут просто копироваться без каких либо задержек. А вот скорость упаковки конечно сильно будет страдать.