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

[axor]

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

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

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

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

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

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

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

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

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

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

Ок.

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

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

А где пункт 8?

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

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

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

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

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

[SAM style]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[rasmer]

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

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

НЕ так:

10 ПЕРВЫЙ
20 ВТОРОЙ
...............
...............
99 ПОСЛЕДНИЙ
goto 10

а так -

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


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

[SAM style]

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

[rasmer]

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

Свяжись с Vitamin, или посмотри исходы его видеостудии...

[Jukov]

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

[Advertiser]

[SAM style]

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

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

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

[Jukov]

Конечно в ПЗУ нет всех комбинаций, да и в 16К их быть не может. Но приблизительные комбинации легко можно найти. Вообще я не знаю Спектрумов, у которых бы не было 48-го Бэйсика. Т.к. без него 99,9% программ даже нельзя будет запустить.

[SAM style]

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

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

[Jukov]

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

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

Да пожайлуста. Вот процедура, которая ищет 8 байт в ПЗУ по образцу. В верхней строчке выводится адрес первого из восьми байтов, которые наиболее соответствуют образцу (по количеству включенных битов и общему количеству включенных битов). Чуть ниже изображается образец, ещё ниже то, что нашли. Запускать лучше на 10-кратной скорости.