Вот именно. Не православно это. От лукавого. И ради чего? Ради 0,8%?
В век многогигагерцовых 64-разрядных многоядерных монстров с кэшем в десятки мегабайт и с оперативой в десятки гигабайт неужели нельзя достигнуть прироста сжатия хотя бы в 10%? Пусть этот монстр пошерудит своими ядрами и найдет оптимальный словарь, оптимальные алгоритмы или что там. Дак ведь нет: 0,8% и всё.
___________
наступил на ещё одни грабли, адрес размещения сжатого блока надо вычислять самостоятельно.
hrust в этом плане более интеллектуальный, он сам переместит сжатые данные до верхней границы.
при его использовании hl=de / source=destination вполне обычный момент.
exomizer при таком раскладе просто запорет данные
goodboy, hrust не идеален. Он тоже может при "hl=de / source=destination" запороть распаковку. Наступал на такие грабли.
Your life is REAL. Change it UNREAL!
такую ситуацию легко создать если в сжимаемом блоке уже есть сжатые данные
Так, вроде, никто не думает, просто самый удобный с достаточно отличным коэффициентом сжатия
Чтобы предотвратить такое, я, как правило, отодвигаю на сектор-другой адрес сжатого блока от адреса распаковываемого.
Ну и еще известная болячка Хруста, это когда данные идут до самого конца сжимаемого блока, он может квадратами покрыться. А вот если в конце ряд нулей, такого не бывает...
П.С. Ну и вообще, выпилить может отсюда весь треп о пакерах и засунуть его в другую тему?
Ave ZX!
изначально созданный для с64,
но позже был написан депакер для z80
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)