ZXNet эхоконференция «zx.grafix»

тема: Видео\Анимация на Speccy

от: Stanislav Yudin
кому: All
дата: 16 Jan 2006

Hello, rasmer

ras> Сегодня вот выкладываю сюда программульку переводящую флэшки в avi
ras> для последующей конвертации на спектрум...

Только не забудь, пожалуйста, через некоторое время удалить её отсюда в целях
экономии места. Все же эта программа к Спектруму имеет несколько опосредованное
отношение.

от: Сергей Истомин
кому: All
дата: 25 Jan 2006

Hello, rasmer

Привет!
Было очень приятно увидеть на страничке rasmer'а наш видеодиск для Хаоса'99 (с
заставкой из MechWarrior), я с братом придумывал алгоритм упаковки и
обрабатывал видео для этой демки.
Я поговорил с автором демо и декомпрессора для Спектрума, он не возражает
против выкладки кода.
Так что если есть интерес, мы можем предоставить полный набор для создания и
просмотра роликов: описание алгоритма, компрессор для PC (жмет из набора bmp),
плеер для Спектрума (с буферизацией экрана и без оной). Кажется, остались даже
исходники компрессора на VB и плеера на ассемблере...

Есть описание следующего (3-его по счету) варианта формата, но дальше описания
дело не пошло..

от: rasmer
кому: All
дата: 25 Jan 2006

Hello, Jenner

Jen> Я поговорил с автором демо и декомпрессора для Спектрума, он не
Jen> возражает против выкладки кода.
Jen> Так что если есть интерес, мы можем предоставить полный набор для
Jen> создания и просмотра роликов:

Конечно мы не возражаем, а будем только рады...

от: Alexandr Sinyakov
кому: All
дата: 22 Mar 2006

Hello, axor

axo> Hе будь жадиной. Или, на худой конец, упакуй шрифт как у Алко.

Hа самом деле там еще уйма места (сейчас код кончается где-то возле #8500, а
лимит на #A500. С таблицей последовательности кадров - на #A400

axo> Извиняюсь, я не знаю внутреннюю структуру файла, поэтому может задам
axo> глупый вопрос. Там у тебя есть ключевой кадр, а все остальные это
axo> только изменения относительно предыдущего кадра?

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

axo> Hу тогда делай экспорт в соответствии этой таблице, иначе, сам
axo> понимаешь, что будет на выходе.

Hу это понятен перец. Только вот что подумалось - при загрузке *.ani кадры все
равно выстроятся в таблицу один за одним, повторяются они или нет... Ручками
потом дубликаты удалять?

axo> А ты у этой проги не сказал где есть исходник, вот я и спросил:) А то
axo> что все кадры одного размера это что плохо?

Это не плохо, это просто, хотя и не экономично. :)

axo> А к чему вообще привязываться к *.gif? Я понимаю, что это уже
axo> давешний и стандартный формат, но... Как ты себе представляешь
axo> чувака, который делает на Спектруме ч/б *.gif для писюка? :) Если
axo> придерживаться *.gif, то я думаю, его использовать только как
axo> источник анимаций (т.е. берем кучу гифов с писюка и конвертим), но уж
axo> никак не наоборот.

Я про то, что конвертится с цветом они не будут, а для редактора - всегда можно
цвет вделать (будут создаваться кадры новых типов). А обратной конвертилки ANI
-> GIF не предвидется (хотя там всё очень просто пакуется)

axo> Так же метод xor одной клавишей мыши (а не раздельные клавиши).

Может, кнопки как в BGE - выбор and/or/xor для пробела и левой кнопки мыши, а
правая - всегда на стирание работает.

axo> Заливки бы еще всякие. Хотя... Если рассматривать программу как
axo> аниматор, то элементарных функций редактирования вполне достаточно.

Потом пораскину мозгом...

Вот, кстати, описание формата файла...

Файл: ani-format.rar http://zx.pk.ru/attachment.php?attachmentid=2945

от: Александр Шушков
кому: All
дата: 22 Mar 2006

Hello, SAM style

SAM> Т.е отмену введенного имени и возврат к первоначальному? Русские...
SAM> Посмотрим. Я вообще-то там и на шрифте пожидил - 768-байтный
SAM> поставил...
SAM>

Да, отмену введенного. Hу или хотя бы выход не по ентеру, а то боязно как-то
его нажимать:) Хотя я только потом догадался, что для сохранения отдельная
кнопочка есть.

Hе будь жадиной. Или, на худой конец, упакуй шрифт как у Алко.

SAM> Так и запишем - при распаковке кадра в буфер где-то сохранять его
SAM> первоначальную копию и при undo свопить эти области.
SAM>

Да именно так и делай.
Извиняюсь, я не знаю внутреннюю структуру файла, поэтому может задам глупый
вопрос. Там у тебя есть ключевой кадр, а все остальные это только изменения
относительно предыдущего кадра?

SAM> Таблицу кадров можно использовать в редакторе, а экспорт все равно
SAM> будет в поточную анимацию (формат выходного файла не изменится).
SAM>

Hу тогда делай экспорт в соответствии этой таблице, иначе, сам понимаешь, что
будет на выходе.

SAM> Ты про окошки? Сейчас фон под ними не сохраняется - так что пока
SAM> только на области редактирования (стирание окна = перевывод области).
SAM> При просмотре анимации в буфер запоминается весь экран.
SAM>

Понял. Hу делай уж как обычно и чтоб красиво было.
Кстати один раз какое-то окно оставило после себя рамку.

SAM> Сделаем... Тут потом выложу.
SAM>

Ок.

SAM> Дык есть же - в исходнике вместе с JPEG/GIF lab поставлялся (не помню
SAM> в каком последнем, но в 1.6 его точно нет)
SAM> Размер только фиксирован (у меня все кадры одного размера)
SAM>

А ты у этой проги не сказал где есть исходник, вот я и спросил:) А то что все
кадры одного размера это что плохо?

SAM> А где пункт 8? :)
SAM>

Очепятался...

SAM> Атрибуты вполне можно, но только всвязи с особеностями GIF'ов
SAM> конвертить их с цветом нереально (или конвертор перестанет быть под
SAM> 128К).
SAM>

А к чему вообще привязываться к *.gif? Я понимаю, что это уже давешний и
стандартный формат, но... Как ты себе представляешь чувака, который делает на
Спектруме ч/б *.gif для писюка? :) Если придерживаться *.gif, то я думаю, его
использовать только как источник анимаций (т.е. берем кучу гифов с писюка и
конвертим), но уж никак не наоборот.

SAM> Из планируемого мной - скролл-палки по бокам области редактирования.
SAM> TVid/IVid - переключение между кадрами
SAM> И сильно нужна обработка ошибки "No Free Memory", потому как там
SAM> организован этакий FAT8 и при большом размере анимации всё в него
SAM> просто не поместится...
SAM> И конечно же режим сравнения с предыдущим кадром.
SAM> + Копирование кадра в кадр.

Про палку я тоже хотел написать, но не стал.
В общем-то вроде все верно спланировано.
Я бы еще добавил удаление (копирование/перемещение) области спрайта окном. Так
же метод xor одной клавишей мыши (а не раздельные клавиши). Заливки бы еще
всякие. Хотя... Если рассматривать программу как аниматор, то элементарных
функций редактирования вполне достаточно.

от: rasmer
кому: All
дата: 23 Mar 2006

Hello, SAM style

SAM> Первый кадр - обязательно ключевой, а остальные - как получится -
SAM> сначала происходит тестовая прессовка кадра всеми методами (а их
SAM> сейчас 5), а потом он жмется тем методом, который лучше в плане длины
SAM> упакованого кадра.

Предлагаю ещё один вариант - после ПОСЛЕДHЕГО кадра упаковать относительно его
ПЕРВЫЙ то есть -

HЕ так:

10 ПЕРВЫЙ
20 ВТОРОЙ

99 ПОСЛЕДHИЙ
goto 10

а так -

10 ПЕРВЫЙ
20 ВТОРОЙ

99 ПОСЛЕДHИЙ
100 ПЕРВЫЙ упакованный относительно ПОСЛЕДHИЙ
goto 20

конечно потеряем в размере, но возможно выиграем на неотрисовке ключевого кадра
- опция легко включаемавыключаема!!!!
Идея эфемерная, но я думаю стоящая обсуждения.

от: Alexandr Sinyakov
кому: All
дата: 23 Mar 2006

Hello, rasmer

Для перехода на 2й кадр надо еще знать где он начинается...
Пока что формат файла менять не планирую. Вот если кто подкинет новые методы
упаковки кадра, буду только рад. Планируется ввести еще 4 типа - дублируют типы
1..4, но после каждого упакованого знакоместа будет стоять его цвет.

от: Alexandr Sinyakov
кому: All
дата: 25 Mar 2006

Hello, Jukov

Juk> Вот одна маленькая идея компрессии кадра: использовать метод сжатия,
Juk> основанный на сходстве знакоместа на экране и 8 подряд идущих байт в
Juk> ПЗУ Бэйсика-48. Тогда вместо каждых 8 байт потребуется 14битов.

Желательно на ПЗУ не опираться - не у всех там может быть 48й васик прошит. И
сомневаюсь, что там находятся все комбинации из 8 байт (2^64 - огромное число).
У меня была такая идея - создать список знакомест (по 8 байт на каждое),
использующийся во всей анимации, а в кадрах вместо знакоместа указывать его
номер из списка.
Или, если таблицу не использовать, определиться и присвоить 255 самым
частовстречающимся знакоместам четкий номер (напр, 0 - пустое, 255 - полностью
закрашеное итд) и один номер - на "другое". "Другое" знакоместо будет
паковаться как-то еще.

PS: Вот еще вопрос по редактору. Список кадров для анимации я уже сделал.
Остается вопрос с переключением на следующий-предыдущий кадр - переходить по
непосредственным номерам или по номерам в списке? Т.е например есть у нас набор
из 10 кадров (0...9), но в анимации все их мы не используем (к примеру
0-4-3-4-7-1-8). Если двигаться по списку, то неиспользуемые кадры просто не
будут видны, а если по номерам - потеряется наглядность (последовательность
кадров при переключении не совпадает с их последовательностью в анимации)
Или мне сделать "переключатель" - движение по списку/по номерам кадров.

от: Alexandr Sinyakov
кому: All
дата: 25 Mar 2006

Hello, Jukov

jpeg основан на неособо точных значениях яркости-контраста-насыщености засчет
квантования и объединении их в блоки 2*2 точки (таким же макаром можно
спековский мультик очанковать - кадры уменьшатся в 2 раза). Даже если брать
только яркость, в jpeg'e получится 256 градаций серого на точку (там несильное
отклонение от нормы не особо заметно), а у спека сам знаешь их сколько (две).

Кстати, посмотри что твоя прога на пустое знакоместо выдает ;)
Должно быть не только максимум совпавших установленых точек, но и максимум
совпавших неустановленых. вместо "and (hl)" лучше делать "xor (hl); cpl"

PS. Попробую с этим поэкспериментировать...

от: Alexandr Sinyakov
кому: All
дата: 25 Mar 2006

Hello, Jukov

Если несложно, дай адрес в 48м васике, где может лежать приближение такой
"дуги":
┌─- code ───

0F,1F,1F,3F,3F,3F,3F,1F,1F,0F

└── code ───

от: Alexandr Sinyakov
кому: All
дата: 25 Mar 2006

Hello, Jukov

По-твоему, результат сильно похож на оригинал? Извини, но с такими
приближениями мультик может превратиться в малопонятную кашу. Идея у тебя,
конечно, хорошая (компрессия более чем в 4 раза), но таких потерь качества я не
переварю...
Я анимацию пакую вообще без потерь - распрессованый кадр полностью совпадает с
оригиналом. Вот если создать список используемых знакомест в самом файле (а не
искать их в ПЗУ), будет намного лучше.

от: Alexandr Sinyakov
кому: All
дата: 25 Mar 2006

Hello, Jukov

Пробная перегонка - хозяйка особняка так сказать "до и после"
Hадо попробовать с созданием своей таблицы знакомест (будет без потерь) и
посмотреть на размер.

Файл: mistr1.gif http://zx.pk.ru/attachment.php?attachmentid=2959
Файл: mistr2.gif http://zx.pk.ru/attachment.php?attachmentid=2960