(c) М.М.A ака UnBEL!EVER/SPEED со./XTM'98
MAXSOFT SCREEN PACKER v1.6
------------------------
(c) MAXSOFT/SPEED COMPANY/XTM'98
"Новая версия этого пургена...", скажете
вы, и будете практически правы. Версия
действительно новая, но даже в эру таких
монстров,как LAZY PACK и LASER COMPACT 4.0
есть место старому доброму MSP.
Подробнейший help по программе вы сможете
получить, ответив "Y" на вопрос,задаваемый
программой сразу после загрузки. Вместе с
help'ом выгрузится тестовая картинка
(собственно рабочий экран MSP) на которой
MAXSOFT предлагает тестировать все новояв-
ленные компрессоры экранов.
Юному пользователю MSP следует уяснить,
что программа имеет 2 принципиально разных
режима упаковки, один из которых делится
ещё на два плюс различные варианты распа-
ковщиков. Короче, можно даже немного поте-
ряться и не понять,зачем всё так запутано.
А весь вопрос в том, с какой целью вы упа-
ковываете картинку, и какова структура
последней.
lin - картинка пакуется линейно, т.е. на
то, что это картинка,компрессор "забивает"
и пакует всё,как обычные данные (без пере-
кодировки). C переменным успехом этим ме-
тодом можно паковать небольшие (до 6912)
куски кода, не являющиеся картинками как
таковыми.
buf - тут к картинке отношение совсем дру-
гое! Она сначала перекодируется из учета
того, что по вертикали повторяемость всега
выше. Только после этого полученный блок
пакуется тем же самым компрессором, что и
в случае lin (вообще, принцип компрессии
данных в MSP един). Для распаковки подоб-
ной картинки в памяти будет создан буфер,
размером 6912 байт, который расположится
точно за самим пакованным блоком.
rtd - полностью аналогичен вышеописанному,
но за счёт увеличения размеров декомпрес-
сора, распаковка картинки сразу происходит
на экран, без создания буфера.
Упакованный одним из вышеописанных спосо-
бов блок может иметь два вида декомпрессо-
ров - стековый ( fast), быстрый и запре-
щающий прерывания или нестековый ( slow),
может работать с разрешёнными прерыва-
ниями, но медленный.
"Так зачем всё это сделано?", спросите
вы... Вот зачем: например,пакуете заставку
от игрушки, дисковую версию которой вы со-
бираетесь сделать. Тут можно смело пользо-
вать buf метод, так как заставка распа-
куется в начале загрузки, когда память
свободна и можно пожертвовать 6912 байт на
буфер. Другое дело, картинка как иллюстра-
ция для электронного журнала! Тут мало то-
го, что buf делать никак нельзя, надо ещё
позаботится, чтобы декомпрессор работал с
включенными прерываниями ( slow+lin.
slow+rtd), иначе музыка будет тормозить!
Ну и наконец, представьте себе такую си-
туацию: вы пакуете картинку, в которой две
трети занимает машинный код, закрытый
атрибутами, а в нижней трети какое-либо
действительно графическое изображение. Тут
линейный алгоритм MSP "сделает" любой дру-
гой компрессор картинок!!!
Ну это бред конечно - паковать картинку,
где две трети занимает машинный код. "A
как MSP ведёт себя на реальных картин-
ках?", спросите вы. Ведёт он себя доста-
точно плохо. Лишь единицы пакуются лучше,
чем в LAZY или LC. Однако в режиме buf
можно получить вполне приличные результа-
ты. А если паковать несколько картинок, а
при распаковке использовать единый де-
компрессор, то можно добиться вполне
преемлимых результатов.
И всё же есть картинки, которые радуют!
Вот,например,задний фон в этом номере ОБЕ-
РОНА, тот, где треугольники нарисованы.
Картинка от самого PARACELS'а, т.е. никто
не скажет, что это "лажа". А MSP пакует её
лучше других - "гляди, Пятачок":
LAZY SCREEN PACKER....................3327
LASER COMPACT v4.0....................3338
MAXSOFT SCREEN PACKER (fast.rtd)......33l4
MAXSOFT SCREEN PACKER (fast.buf)......328S
Небольшое исследование размеров различных
декомпрессоров:
FAST RTD - 277 FAST LIN - 187
SLOW RTD - 295 SLOW LIN - 214
FAST BUF - 218
SLOW BUF - 248
байтов of coz!
Данные цифры показывают, что линейный ал-
горитм самый простой (минимальная длина
декомпрессора), буферизированный послож-
нее, и самый "трудный" rtd ( Макс ничего
не написал в help'e про эту аббревиатуру,
но мне кажется, что это realtime depack).
Кстати,в help'е есть пункт,описывающий от-
личие версий компрессора. Так вот, почти в
каждой версии есть неприметная фраза
"Оптимизированы распаковщики". Хотите по-
нять, что действительно скрывается за
этими двумя словами?
MSP 1.0
fast lin depacker = 225 byte
38 байтов чистой выгоды только на де-
компрессоре! Вот это я называю оптимиза-
цией...
И ещё хотелось бы рассказать об опции
FILL. Те, кто прочитает внимательно help,
наверняка ужаснется - что они с нашей
картинкой сделают после упаковки!!!! На
самом дле FILL был придуман и интегрирован
в компрессор с целью лишний раз не лазить
в ART STUDIO или SCREEN OPTIMIZER. Прузите
вы свеже-сконверченную с РС картинку в
компрессор и вдруг понимаете, что она смо-
трелась-бы лучше не чёрно-белой, а напри-
мер сине-красной. Тут-то FILL вас и выру-
чит - только пользоваться научитесь. А
учитывая возможность использовать код "8"
(как в BASIC'е), эта опция становится
вообще незаменимой.
Вот такие дела! Пусть ваши картинки отныне
"пакуются с миром". Может быть, их лучше
всех "уроет" MSP, а может LC и LAZY РАСК
обойдут на повороте... Не важно, главное,
что никто так эффективно не распакует
картинку, созданную любым компрессором как
это сделает MSP. А какой ещё компрессор
скажет вам, что картинка стала на столько
байт (секторов) меньше? Дизайн, батенька,
и функциональные возможности, понимаешь...
P.S. В таблице с данными о компрессии тес-
товой картинки по непонятным причинам от-
сутствует значение для LCЧ.0. Складывается
впечатление, что MAXSOFT специально не
стал приводить это значение (868 байт),так
как оно на 39 байт меньше лучшего значения
которое принадлежит,естественно,MSP. Оста-
вим это на совести Макса. Однако хочется
сказать, что вся эта гонка за байтами на
самом деле - миф. Вот если кто сделает
компрессор, спакующий тестовую картинку до
размеров трёх секторов... Автору этого чу-
да дейстивительно нужно будет поставить
памятник!
P.P.S. Не спрашивайте меня о том, где вер-
сия MSP1.5. MAXSOFT выпустил её незадолго
до FUNTOP'а, но после того, как я показал
ему LAZY РАСК и LC, он решил сделать не-
большой upgrade. Я ещё не успел
распространить версию 1.5, а у себя её
стёр. Однако МАКС не послушал моих завере-
ний и дал новой версии номер 1.6. Таким
образом,версия 1.5 становится таким рари-
тетом, что каждый имеющий её может считать
себя Рокфеллером. Хотя вряд ли таковые
найдутся...
-========================================-
* * * * *
Other articles:
