Баг в depacker от hrust1.3?

[Vitamin]

Я б с радостью, но так не выйдет, памяти нет. Но вроде сейчас вот переместил - не наползает, нормально распаковало.

Ну значит надо перемещать трудноупаковываемые данные в начало блоков.

Кстати об этих самых трудноупаковываемых данных. По хорошему, их быть не должно - это либо подгруженные уже упакованные блоки (что есть глюк) или de facto плохо пакующиеся данные (но в этом случае они должны равномерно плохо паковаться, что опять же наводит на мысль о первом случае).
Многократное вложение пакованных блоков друг в друга- крайне часто встречающаяся вещь, к сожалению...

[Shadow Maker]

Ну это хорошо, если ты можешь перенести блоки куда захочешь. А есть такая ситуация, когда уже поздно чего-то переносить, всё уже готово и тут бац - и проблема на этапе сборки финальной версии.

Вот тот блок, который у меня. Это не пакованные данные, тем не менее, всё налазиет, если распаковывать в то же место.

[Vitamin]

Вот тот блок, который у меня. Это не пакованные данные, тем не менее, всё налазиет, если распаковывать в то же место.

Ну, в принципе, даже в сыром виде заметно, что в конце идут более хаотичные и уникальные данные, нежели в начале. И допустимого нахлеста в 6 байт явно не хватит.

[Shadow Maker]

Ну это понятно, что нахлест идёт. Сделал бы кто-нить универсальный 256-байтный депакер для хруста, чтобы тот распаковывал всегда - вот это было бы здорово. А то часто и не поймешь, что вообще-то неправильно распаковалось, пока вдруг баги не полезут.

[Vitamin]

Сделал бы кто-нить универсальный 256-байтный депакер для хруста, чтобы тот распаковывал всегда - вот это было бы здорово.

Это невозможно Даже если просто логически подумать

[psb]

выход из ситуации - добавить в конец пакуемого блока кучу нулей. штук так 50-200.

[moroz1999]

поясню что происходит пожалуй

у мороза данные находятся по адресу 30000
распаковывает он данные на адрес 49152
поэтому распаковщик делает как он считает правильную вещь переносит данные за область распаковки - выше 49152
но данные очень плохо сжаты - распакованные данные наползают на упакованные данные в конце файла - потому глюк
если бы мороз этот блок держал выше - например на #db00 то проблем бы не было
распаковщик ничего бы не копировал

проблема не в распаковщике - проблема в данных в конце файла там видимо лежит блок плохопакующийся

Я, честно говоря, ничего не понял
Как я тогда слабо понимал причину проблемы, так и сейчас, перечитав всё, не понял ничего.

[Shadow Maker]

Это невозможно Даже если просто логически подумать

Нуууууу Хочется.

[NovaStorm]

Если так хочется, то можно подумать о буферизации этих несчастных 6ти байт в регистрах, но 100п овчинка выделки не стоит.

[Vitamin]

Если так хочется, то можно подумать о буферизации этих несчастных 6ти байт в регистрах, но 100п овчинка выделки не стоит.

6 байт нахлеста уже предусмотрены пакером и форматом сжатого блока. Т.е. распаковщик их обычно копирует вместе с собой. ЕМНИП.