(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 становится таким рари- тетом, что каждый имеющий её может считать себя Рокфеллером. Хотя вряд ли таковые найдутся... -========================================- * * * * *