|
Born Dead
#08
19 апреля 1999 |
|
Coding - Компрессия картинок (screen to text).
════════════════════════════════════════════════════════════════
╠╬╣║╞╪╡█████████████╡╪╞║╣╬╠ CODING ╠╬╣║╞╪╡█████████████╡╪╞║╣╬╠
════════════════════════════════════════════════════════════════
(c) UnBEL!EVER^Speed co.^XTM
Этот материал имеет слабое отношение к CODING'у как таковому и
больше направлен на тех, кому дорог каждый сектор дискового
пространства. Если вы действительно готовы часами думать над
тем, как отвоевать еще пару секторов воспользуйтесь следующим
полезным советом.
Итак, представим себе ситуацию, когда пакуемый кодовый блок
содержит внутри обычный экран длинной 6912 байтов. Самым легким
вариантом будет просто упаковка HRUST'ом или HRUM'om. Можно
попробовать скомпресировать экран LASER COMPACT'ом или другой
программой ориентированной на экраны. Это даст определенную
выгоду, но зачастую распаковщик длинной в 100-200 байтов скушает
все ваши достижения. Если экранов больше, чем один, то можно
смело использовать единственный распаковщик, что опять же за
частую не решает проблемы.
Как же все же сэкономить в таком случае сектор? Решение кроется
в корне проблемы; надо картинку паковать с учетом структуры
экрана, но с другой стороны нужно иметь единый декомпрессор на
код и на картинку. Берем картинку находящуюся внутри кодового
блока и перекодируем ее столбцами, примерно так как это делают
прогрессивные упаковщики.
Вот вам вариант программы :
SCREEN TO FONT FONT TO SCREEN
---------------------- ----------------------
SCR_BUF EQU #C000 ....... ... .....
LD DE,SCR_BUF .. ..........
LD L,#00 .. .....
LD C,#20 .. .....
CNV_M3 LD H,#40 .. .....
LD B,#C0 .. .....
CNV_M1 LD A,(HL) LD A,(DE)
LD (DE),A LD (HL),A
INC DE ... ..
INC H ... .
LD A,H .. ...
AND #07 ... ...
JR NZ,CNV_M2 .. .........
LD A,L .. ...
ADD A,#20 ... .....
LD L,A .. ...
JR C,CNV_M2 .. ........
LD A,H .. ...
SUB #08 ... ...
LD H,A .. ...
CNV_M2 DJNZ CNV_M1 .... ......
INC L ... .
DEC C ... .
JR NZ,CNV_M3 .. .........
EX DE,HL
LD HL,#5800 LD DE,#5800
LD BC,#0300 .. ........
LDIR ....
RET ...
Теперь запаковываем полученный блок все теми же HRUST/HRUM и
наслаждаемся экономией. Правда проблемка в том, что надо как то
этот закодированный screen напечатать. Тут вроде как ldir'ом уже
не обойтись... Опять же прийдеться внедрить обратную первой
программу, или же раскодировать screen прямо в памяти. В любом
случае, этот или аналогичный ему декодер займет места гораздо
меньше, чем стандартный LC4.0/5.0 depacker.
Может показаться, что это извращение и не стоит так напрягаться
ради какого то сектора (а иногда и двух!). Но бывают ситуации,
когда этот самый сектор просто необходим как воздух. На последок
замечу, что метод этот успешно был опробован MAXSOFT'ом при
переделке несколких частей к FA, и MMCM'ом на финальной версии
Pro Tracker'а который стал теперь занимать ровно 100 сектров.
Приведеные в этой заметке программы не в коем случае не
являються идеальными и при желании, в зависимости от конкретной
ситуации, их бесспорно можно прооптимизировать как по размерам
так и по времени выполнения.
Другие статьи номера:
Похожие статьи:
В этот день... 23 апреля