ожидаемо, что дизеринг делает кадры разными. удивился что даже физически одинаковые кадры - png'шки - первый раз дизерит по одному, второй раз уже по другому. второй момент, возвращаясь к Грендайзеру - это видимо сканировалось с пленок, и там плавает изображение пиксель туда пиксель сюда, то есть это как бы визуально один и тот-же кадр, но из-за этой тряски система будет думать что это разные кадры. так что с автоматической системой определения одинаковых кадров - швах
значит остается ручной метод. я конечно попытаюсь сделать организацию процесса чтобы хоть как-то удобно было, но боюсь будет хоть как-то, без слова "удобно". замысел в том, чтобы на первом этапе создавать отдельные сцены из кадров фильма. по одному кадру пока-что пихать туда сюда по сценам:
сейчас получается все 350 кадров фильма рожают одну и ту-же палитру для всех 350 кадров. и на попытке конвертануть интро Дюны получился полный швах
ибо такая система по весу цветов пикселей (то есть по количеству пикселей какого-то цвета делается вывод какой цвет сохранить, а какой выкинуть) взяла и выкинула самые вкусные цвета - красный и синий. и запилило мне ролик в основном в желтых тонах, ибо песка в том видео было тьма. а вот если разбить ролик на сцены, то можно создавать палитры отдельно для каждой сцены. все равно у меня палитра в коде (вроде бы) загружается каждый кадр. так почему бы это не использовать? осталось только сделать менеджмет кадров, чтобы их было удобно пихать туда сюда. это один момент.
второй момент - я попытался сделать каждому кадру свою отдельную паузу, а не глобально delay 11 и мы в дамках. нафига? опять таки возвращаясь к теме одинаковых кадров - нахрена козе боян? ведь можно их выкинуть. оставить только первый из одинаковых, просто втулить ему паузу *количествовыкинутыхкадров и всё
вот думаю мышкой крестики на кадрах ставить, чтобы система понимала что их надо пропустить. тем самым мы выиграем немного места в роме.
третье - некоторые кадры имеют затемнение. так почему бы это не обыграть изменением палитры, не загружая тайловый сет? уж палитра то займет куда меньше места, чем тайловый сет. то есть то-же интро Дюны - там вначале вествуд и вирджин загораются и затухают. вот чтобы не грузить кадры этого затухания - можно палитрой вводить и выводить изображение. то есть физически тайловая карта и тайловый сет загружен и не дергается, а только палитра каждый кадр в 11 delay меняется от темной к светлой, а потом назад. то есть надо подумать над созданием некоторых фейковых кадров. здесь сложнее, ибо надо будет лезть в сам асм, то есть чтобы система понимала, что несмотря как бы что новый кадр уже наступил, но не производить загрузку, а загружать только палитру, ждать delay, проверять следующий кадр нормальный он или фейковый, если фейковый, загружать следующую палитру, ждать... и так далее.
четвертое - тайловая карта. сейчас она вся рисуется от 0:0 до нижнего правого края изображения на кадре. то есть куча нулей зазря гоняется туда сюда. неплохо было бы это оптимизировать, и загружать не всю тайловую карту 64х28 или сколько-то там, а прям как есть 120х80, то есть 15х10 тайлов. но это опять таки изменение в асм коде нужны, там где загрузки тайловой карты.
пятое - можно выкидывать повторяющиеся тайлы из тайловых сетов. шанс, особенно после дизеринга, что система найдет повторяющиеся - такой себе, но чуток все-таки выигрыша места в роме это даст.
шестое - самое маловероятное - оптимизация кадров и загрузка частично. как с тем-же императором. когда он трындит на видео, то весь кадр по сути статичный, и шевелится только рот и глаза. вот зачем для этих кадров грузить весь кадр, когда можно только кусочек в центре. вот такой подход сэкономил бы прилично места, но автоматику для такого будет сделать сложновато, не говоря уже опять-таки что нужно будет в код асма лезть и там мудрить процедуры по вписке нужных конкретных точечных данных в тайловую карту. в принципе я даже видел готовое решение - в старом GIF аниматоре. он делает оптимизацию джифки, основываясь на предыдущем кадре. вот нечто подобное нужно придумать и мне.
