Хочу сделать красивейшую интру к Saboteur 2 на базе исключительно ее собственной картинки. Для этого необходим хороший упаковщик (желательно -- по выбору для окошка, а не всего экрана).
Вид для печати
Хочу сделать красивейшую интру к Saboteur 2 на базе исключительно ее собственной картинки. Для этого необходим хороший упаковщик (желательно -- по выбору для окошка, а не всего экрана).
накидай спрайты на экраны, а потом пожми их LaserCompact'ом =)
Сэнкс, конечно, но надо пакдепак для окошек. Хотя бы знакоместных.
Попробуй мой плагин к bge для вырезания спрайтов с упаковкой. Нативное сжатие в нем не очень, но файл может содержать несколько спрайтов и хорошо жмется обычными упаковщиками для кода
Спасибо, попробую. А инструкции по вызову этого на экран в пакете с BGE?
http://zxdocs.fatal.ru/formats/B/BIT.zip
Если надо, могу кинуть исходы плагина, там выводилка имеется
ага, вроде понятно все. Только байт разницы -- не меняется, пока маска не укажет? или кроме XOR для получения данных еще что-то надо?..
Нет не меняется. Вот исходник, может придется чтото подправить для оптимизации. Начальный байт данных и разница равны нулю, т.е. одним нулевым байтом кодируется пустое знакоместо. Может быть другое направление распаковки маски (придется заменить RR C на RL C).
;распаковка одного знакоместа
;HL- адрес в памяти
;DE- адрес первой строки знакоместа
DEPACKPLC ;HL->DE
LD C,(HL) ;взяли маску знакоместа
INC HL
EX AF,AF'
XOR A ;начальный байт
LD B,A ;начальная разница
MCO EX AF,AF'
RR C ;выделяем очередной бит
JR NC,OLBB
LD B,(HL) ;новая разница- обновляем
INC HL
OLBB ;выводим данные
XOR B
LD (DE),A
INC D
EX AF,AF'
LD A,D
AND 7
JR NZ,MCO
RET
брр...
запутался теперь что-то
это A, которое кладется в DE, нигде не сохраняется? получается, лучше всего пакуются байты 255-0-255-0, или 130-125-130-125, т.е. негатив-позитив-негатив? Разве такие последовательности часто встречаются? Странно как-то, если на код смотреть. Или я плохо врубился... А он работает?
Да, и входное значение A -- никак не влияет?
Обшибся слегка. Надо перед меткой MCO поставить EX AF,AF' (это я на лету писал). Ну еще можно развернуть цикл и вообще избавиться от этих обменов.
Если исходное изображение является конверсией по floyd-steinberg, то сжатие будет хреновым (равно как и любым другим пакером), а вот если оно по методу threshold или ordered то все замечательно. Плагин к bge (поставляется в комплекте к qhts или скачивается с сайта http://zxdocs.fatal.ru (раздел projects). В нем можно посмотреть сколько будет весить набор изображений в сжатом и расжатом виде. В среднем в 1.5-2 раза получается выигрыш. И это при достаточно высокой скорости распаковки. Ну и плюс итоговые данные хорошо пакуются хрустом.Цитата:
Сообщение от TomCaT
ЗЫ. В videostudio также используется этот метод, он оттуда пришел%))
ну, раз работает, значит правильный алгоритм. Хотя я все равно не понимаю, почему просто XOR дает такой выигрыш... и да ладно. Буду пробовать завтра...
P.S. два EX AF подряд... нельзя ли как-то иначе? Ведь всего только под конец проверить, добрались ли донизу? Надо еще один восьмибитный рег., а в него единицу и RLC ее, тогда и конец определится, и экономия... Может, адрес один в SP положить?
Могу подкинуть ещё пяток способов упаковки, которые используются в AniE наряду с тем, который описал Vitamin. Максимальное сжатие доходит до 64 раз (пустое знакоместо кодируется в 1 бит).
Давайте 8). Только исходники пакдепакеров не по 5 секторов, часом? Потому что все в теме не опубликуешь...
(я вообще-то думал, что есть под это готовые проги... Надо бы написать какой-то сносный жмакер знакоместного окна, со своим сервисом и минимумом параметров -- окно, м.б. выбор метода и файл -- все что надо, в общем... с пом. одного из местных алгоритмов)
процедурины для пакрвки-распаковки одного знакоместа
1.
этим лучше пакуются последовательности одинаковых байтКод:; hl - адрес на экране
; de - куда пакуем
PACK1 push de
inc de
ld bc,#8000
xor a
lab_1 cp (hl)
jr z,lab_2
ld a,(hl)
ld (de),a
inc de
scf
lab_2 rr b
inc h
jr nc,lab_1
ex (sp),hl
ld (hl),b
pop hl
ret
; de - адрес на экране, куда распаковываем
; hl - откуда распаковываем
DEPACK1 ld b,(hl)
inc hl
ld c,8
xor a
depa_1 rr b
jr nc,depa_2
ld a,(hl)
inc hl
depa_2 ld (de),a
inc d
dec c
jr nz,depa_1
ret
Дальше буду оъяснять на пальцах, потому как то, что я накодил под этот вариант не вполне понимаемо даже мной самим, да к тому же объёмно
и в варианте Vitamin'а, и в написаном выше упакованое знакоместо представляет собой следующее: (флаги,[данные])
если знакоместо пустое, оно представлено только одним нулевым байтом. У меня родилась следующая идея - берём 8 знакомест подряд, пакуем их (любым из двух методов) и составляем ещё один флаговый байт (обозначим flag2) - если знакоместо пустое (флаг=0), то мы сбрасываем бит в flag2 и данное знакоместо в поток не выводим (т.о пустое знакоместо у нас стягивается в 1 бит), а если не пустое - устанавливаем бит в flag2 и выдаём упакованое знакоместо в поток целиком.
поток тогда будет выглядеть так:
flag2,([флаги],[данные] - до 8 раз),flag2,...
На этом делается ещё 2 метода упаковки
и ещё один. экспериментальный, в теории жмёт лучше остальных.
берём 4 знакоместа и составляем flag2 таким образом
- если знакоместо пустое, в flag2 пихаем 00 и в поток ничего не идёт
- если знакоместо полное (8 байт #ff), в flag2 ложим 01, в поток - ничего
- ? по идее надо найти ещё одно распространённое знакоместо, которому будет соответствовать 10 в flag2
- иначе пакуем знакоместо (выбраным методом), ложим в flag2 11 и выдаём упакованое знакоместо в поток
Э... сам плохо понял, что сказал, но если что неясно - попробую вспомнить подробнее
Во вложении - прога упаковки ещё одним сумашедшим форматом
1. картинка сканируется на предмет полных знакомест
2. на основе скана создаётся 1й слой (битовый)
3. все продетектеные знакоместа из картинки стираются
4. остальное пакуется одним из двух методов (а потому как пустых знакомест стало больше, а они пакуются лучше всего, то и коэффициент сжатия увеличивается)
Нет, все понял. :) Понял даже лучше, чем механизм у Vitamin. Спасибо большое.
В общем случае, я так понимаю, хорошо составить словарь из 2^n повторяющихся во входном потоке знакомест. Тогда в два прохода (или около) при наличии памяти для подсчетов под словарь, должно сиильно жмакатьтся...
Например, можно так? флаговый байт 1+7 бит. 1 бит указывает на букву алфавита или на чужеродный знак, остальные либо номер буквы (все 0 всегда пустое, 1 -- всегда полное), либо биты повторения последующих байтов чужеродного знака. При этом теряется один бит, для первого или последнего байта -- т.е. он уже не участвует в повторении. Но зато обходимся одним флаговым байтом на знакоместо...
(сам Клайв велел повесить словарь на IX... ;) )
Я попытаюсь написать на этой основе отдельно WiPack -- сжимающий знакоместное окно (спрайт, в общем) -- и WiDepack, требующий номер спрайта в файле, окно внутри спрайта (необяз.) и координаты вывода. Со всем этим интро должно вроде выйти, как задумывалось. Скорость, конечно, какая там еще будет...
Можно модифицировать метод битового потока следующим образом:
0- пустое знакоместо
10- знакоместо сжатое методом zeropack (SAM style)
11- знакоместо сжатое методом bitpack (Vitamin)
декодер, в отличие от кодера, получается достаточно простой.
А еще я писал пакер спрайтов с маской, причем умный- знакоместа со сплошной маской не запоминались вообще. Как раз для гамезов и прочего
интересно. Как вариант -- смесь методов. Но кодер буудет, уююй, наверное.Цитата:
Сообщение от Vitamin
как всегдаЦитата:
Сообщение от Vitamin
тоже интересно. Хоть одним глазком бы... Ну да ладно, не буду жадничать. Возьму что-то из вышеперечиленного.Цитата:
Сообщение от Vitamin
уююй у меня кодер в студии- там один поток данных (маска разделяет знакоместа и смещения) и поток атрибутов (тоже маска разделяет смещения и цвета). как уж я там извращался чтоб упаковать... пришлось через промежуточные буфера крутить, иначе никак.Цитата:
Сообщение от TomCaT
а спрайтовый движок могу подкинуть- я под него тоже плагин к бге писал, на выходе сразу аласмовский файл дает с данными. правда атрибуты не поддерживает (не нужны были)
2 TomCaT: Как вариант - попробовать multsystem2: если есть последовательность экранов. Это "корректировка" laser comlact версии, кажется четвертой для сжатия именно последовательности экранов.
Я в Nocturne такую фишку использовал для сжатия спрайтов персонажей :v2_wink2: Различались пустые знакоместа со сплошной маской (кроме типа в поток ничего не шло), пустые знакоместа с несплошной маской (в поток - тип+маска), непустые знакоместа с пустой маской (тип+изображение), пустые знакоместа с пустой маской (только тип) и все остальные (тип+изображение+маска)Цитата:
Сообщение от Vitamin
У меня хранились вперемежку данные знакомест (+ маска) и смещения от предыдущих знакомест. И все это дело закодировано в маске заголовка. Получалась хорошая оптимизация по скорости вывода- задаем стартовый адрес на экране и он выводит все, играя чисто на смещениях. Все как в той же VS (ты вроде прикручивал плеер, думаю смотрел как там %))