Вид для печати
Собственно сжатие картинки и разжатие
(причём разжатие занимает всего 20 байт)
Код:ORG 7E00H
LD HL,4000H
LD DE,8000H
L4 LD B,00H
LD C,(HL)
L3 INC HL
LD A,H
CP 5BH
JR Z,L5
INC B
LD A,FFH
CP B
JR Z,L6
LD A,(HL)
CP C
JR Z,L3
L6 LD A,B
LD (DE),A
INC DE
LD A,C
LD (DE),A
INC DE
JR L4
L5 LD A,0
LD (DE),A
RET
Собственно критики хочется, мало ли у кого есть советы...Код:ORG 7F00H
LD HL,8000H
LD DE,4000H
L2 LD A,(HL)
CP 0
RET Z
LD B,A
INC HL
LD A,(HL)
INC HL
L1 LD (DE),A
INC DE
DJNZ L1
JR L2
Для начала, заменить cp 0 на and a
Будет плохо паковаться при большом количестве неповторяющихся байт.
Ввести флажок "последовательность из разных/одинаковых байт".
Пример:
06 - 7й бит=0 - 6 разных байт
01
23
45
67
89
AB
85 - 7й бит=1 - 5 одинаковых байт
CD
83 - 7й бит=1 - 3 одинаковых байта
EF
04 - 7й бит=0 - 4 разных байта
55
AA
33
CC
00 - конец
RLE-весьма неэффективная методика. Попробуй хотя бы простейшее словарное сжатие, получишь более существенный эффект.
Огромное спасибо, важное замечание, это я упустил.Цитата:
Сообщение от rajdee
Цитата:
Сообщение от DDp
Собственно RLE был выбран из простоты. Конечно если сначала прогнать MTF потом RLE а потом ещё и Хаффманом закусить то сожмётся лучше, но смысл сжимать картинку из шести килобайт в один если "extractor" будет занимать ещё десять ?Цитата:
Сообщение от Vitamin
Распаковщик Laser Compact'a занимает несколько сотен байт.Цитата:
Сообщение от Vladson
Если логика меня не подводит, то компрессор можно переписать так:
Довольно давно ничего не писал, поэтому не уверен, что будет работать :)Код:ld hl,#4000
ld de,#8000
l4 ld c,1
l1 ld a,h:cp #58:jr z,l2
ld a,(hl):inc hl
cp (hl):jr nz,l3
inc c:jr nz,l1
dec c
l3 ex de,hl
ld (hl),c
inc hl
ld (hl),a
inc hl
ex de,hl
jr l4
l2 xor a:ld (de),a
ret
P.S. Такой алгоритм эффективен только для экранов с линейной адресацией, а для спектрумовского нужно учитывать строение экрана.
Код работает как часы.Цитата:
Сообщение от rajdee
У меня наоборот, пишу часто и мои проги всегда работают, но так как мой код никто почти не видит я не знаю на сколько это правильно с точки зрения как мелочей так и архитектуры в целом. (по этому и прошу критики, как кода так и каких-то подходов)
(На РНР проще, много форумов всегда можно показать код и найти кучу критики и сделать выводы, а на Specy так много не пишут.)
Для начала почитайте http://zx.pk.ru/showthread.php?t=5335
Почему именно RLE? В силу простоты только если? Возьмите Huffman или Lempel-Ziff.
Вообще Lempel-Ziff могут быть очень короткими (как Laser Cpmact) при этом очень эффективными.
Только, так и естьЦитата:
Сообщение от GriV
Большой размер кода будет (по сжатию ему равных пожалуй нету)Цитата:
Сообщение от GriV
Посмотрю.Цитата:
Сообщение от GriV
Из энтропийных алгоритмов арифметический лучше. Но сложнее и медленнее. Сравнивать энтропийные алгоритмы сжатия и словарные (а то еще и комбинированные) категорически некорректно!Цитата:
Сообщение от Vladson
Ну тогда тем более читайте то руководство что я забивал здесь в разделеЦитата:
Сообщение от Vladson
Alone Coder где то (кажется Info Guide) составлял сравнительную таблицу имеющихся энкодеров для ZX - там же есть достаточно материала для понятия азов LZ методик.Цитата:
Сообщение от Vladson
Азы то знаю, просто опыта написания нету.Цитата:
Сообщение от GriV