RLE сжатие (покритикуйте)

[Vladson]

Собственно сжатие картинки и разжатие
(причём разжатие занимает всего 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
Собственно критики хочется, мало ли у кого есть советы...

[rajdee]

Для начала, заменить cp 0 на and a

[DDp]

Будет плохо паковаться при большом количестве неповторяющихся байт.
Ввести флажок "последовательность из разных/одинаковых байт".

Пример:
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 - конец

[Vitamin]

RLE-весьма неэффективная методика. Попробуй хотя бы простейшее словарное сжатие, получишь более существенный эффект.

[Vladson]

Для начала, заменить cp 0 на and a
Огромное спасибо, важное замечание, это я упустил.


Будет плохо паковаться

RLE-весьма неэффективная методика.
Собственно RLE был выбран из простоты. Конечно если сначала прогнать MTF потом RLE а потом ещё и Хаффманом закусить то сожмётся лучше, но смысл сжимать картинку из шести килобайт в один если "extractor" будет занимать ещё десять ?

[newart]

"extractor" будет занимать ещё десять
Распаковщик Laser Compact'a занимает несколько сотен байт.

[rajdee]

Если логика меня не подводит, то компрессор можно переписать так:

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. Такой алгоритм эффективен только для экранов с линейной адресацией, а для спектрумовского нужно учитывать строение экрана.

[Vladson]

Довольно давно ничего не писал, поэтому не уверен, что будет работать
Код работает как часы.

У меня наоборот, пишу часто и мои проги всегда работают, но так как мой код никто почти не видит я не знаю на сколько это правильно с точки зрения как мелочей так и архитектуры в целом. (по этому и прошу критики, как кода так и каких-то подходов)

(На РНР проще, много форумов всегда можно показать код и найти кучу критики и сделать выводы, а на Specy так много не пишут.)

[GriV]

Для начала почитайте http://zx.pk.ru/showthread.php?t=5335
Почему именно RLE? В силу простоты только если? Возьмите Huffman или Lempel-Ziff.
Вообще Lempel-Ziff могут быть очень короткими (как Laser Cpmact) при этом очень эффективными.

[Vladson]

В силу простоты только если?
Только, так и есть

Huffman
Большой размер кода будет (по сжатию ему равных пожалуй нету)

Вообще Lempel-Ziff могут быть очень короткими
Посмотрю.

[Vitamin]

Большой размер кода будет (по сжатию ему равных пожалуй нету)
Из энтропийных алгоритмов арифметический лучше. Но сложнее и медленнее. Сравнивать энтропийные алгоритмы сжатия и словарные (а то еще и комбинированные) категорически некорректно!

[GriV]

Только, так и есть
Ну тогда тем более читайте то руководство что я забивал здесь в разделе


Посмотрю
Alone Coder где то (кажется Info Guide) составлял сравнительную таблицу имеющихся энкодеров для ZX - там же есть достаточно материала для понятия азов LZ методик.

[Vladson]

для понятия азов LZ методик
Азы то знаю, просто опыта написания нету.