Если кратко - удивил. Кратко и отвечу - ну вот будет флажок, мол, опирайся на депакер, и используй выгруженный депакер. И всё. Никаких споров. Хочешь-юзай, опционально же.Цитата:
Сообщение от introspec
Если кратко - удивил. Кратко и отвечу - ну вот будет флажок, мол, опирайся на депакер, и используй выгруженный депакер. И всё. Никаких споров. Хочешь-юзай, опционально же.Цитата:
Сообщение от introspec
Приведу пример чтобы не быть голословным. При сжатии графики для недавней 1к интры мне нужно было упаковать файл в 3072 байта. Размер кода по сравнению с размером графики был вторичен. Самое лучшее сжатие было достигнуто Exomizer (638 байт). Остальные упаковщики сгруппировались где-то в районе 670-690 байт. Но самый компактный распаковщик для Exomizer требует 169 байт, в то время как распаковщик для самого примитивного компрессора в моих тестах (zx7) требовал всего 69 байт. Т.е. увеличение размера распаковщика может запросто нивелировать выигрыш от повышенного коэффициента сжатия, раз уж мы думаем о упаковщиках для сайз-кодинга.
Еще бы конечно хотелось, чтобы он всегда распаковывал то, что наупаковывал. Что упакованные данные не затираются распакованными. Очень помогло бы, а то упаковываешь бывало блок, и все вроде работает на первый взгляд после распаковки, но на самом деле - где-то в середине что-то наехало и не распаковало. Особо актуально для больших блоков, когда места нет.
Ага, в exomizer2, если не ошибаюсь, сообщается, что: "товарищ, тут накладка в 3 байта, имей в виду, я тебя предупреждал".Цитата:
Сообщение от Shadow Maker
Надо давать возможность при распаковке выделять память без наложения, а то сейчас даже не спрашивают.
Краткое описание алгоритма, про который рассказывал Хрумер, в приложении.
када ждать новую версию ?
Не скоро. Там и так много чего перепроверить надо, а еще и LVD несколько лет назад сделал mhmt с алгоритмом OLZH c с форматом хранения MegaLZ, hrum3.5 or hrust1.x format (default is MegaLZ), чем сильно поднял планку, которую тяжело перепрыгнуть. Буду пока laser compact ускорять.
Hrumer, а если просто перевыпустить Hrum 3.х под вин?
у hrum3 и так уже есть порт 1:1 и есть с OLZH.(не мои) А если имеешь ввиду hrust3, то вопросы то те же остаются, там надо протестить как дистанции для длины =2 кодировать (768 байт дистанции, похоже, это чересчур, правильнее 256 или 512, настраиваемо(?) с увеличением len при длине дистанций 256 или 512), убрать явную неоптимальность кодирования дистанций для len>2 (там, кажется, вообще перекрытие кодов идет для дистанций <=512), и там еще куча всего...