Новинки - паповщик экранов Maxsoft Screen Packer v.1.6

<b>Новинки</b> - паповщик экранов Maxsoft Screen Packer v.1.6

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