версия ёмулятора для просмотра демовых скроллов

[GriV]

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

Да знаю, что не просто, но фактически, имея указанную схему (просто motion blur) такого качества изображения, как на оригинальному спекке (я именно про бегущую строку) получить никак не получится.
Либо будет на экране размазня либо будут рывки при проигрывании.
Кстати, как дополнительный вариант можно рассматривать (это кажется в X129 было) привязку к частоте кадров, но тогда плывёт частота всего остального - процессора, AY/YM и т.д.

Не помню где, в какой-то программе (кажется 3DMorph называлась, уверенности в названии нет) был релизован переход от одной картинки к другой, причём создавалсь AVIшка где был плавный переход именно таким образом.
Т.е. чисто технически такое осуществить можно. Насчёт алгоритма конечно сложности есть.
Там для программы нужно было вручную строить точки трансформации (вообще то не так сложно их строить автоматически для нашей задачи) и потом указывалось каким образом трансформируется объект, путём перемещаения точек на соседней картинке в заданное положение.

Так подумав, можно привести типовые элементы, на которых видно что демы дёргаются:
1) Бегущие линейно части экрана (строчки, картинки и т.д.)
2) Меняющиеся цвета (здесь попроще, можно использовать тот же motion blur)

Бегущие части экрана чисто технически достаточно просто "вычислить" - как правило это прямоугольник (или несколько прямоугольников), которые за одно прерывание перемещаются на 1,2 и т.д. пикселей.

Если представить картинку, заменив пиксель байтом (включенный пиксель - 255, выключенный - ноль) и сравнивать картинки последовательным наложением(1 картинка - исходная, 2ая - к которой движемся, смещается в одну из сторон на N пикселей), то при определённом наложении по XOR появится пустой прямоугольник (та часть, которая в обоих картинках одинакова - часть бегущей строки, движущийся автомобиль, бегущий по экрану человечек, и т.п.).
Дополнительно выделенную область можно поддвергать критериям проверки на то, что всё-таки это нормальное движущееся по экрану изображение, а не просто сменилась картинка.
Предполагаемое смещение от 1го кадра к 2му - от 1 до 16 пикселей.
Вот и весь алгоритм.

[SMT]

не подойдёт. если один конец линии закреплён, а другой движется, все точки линии движутся с разной скоростью. если на экране мячик движется в одну сторону, а текстура на нём - другую (illusion megademo), что тогда... а если плавающее месиво - популярный эффект "плазмы"? программы по морфингу двигают каждый пиксель - это не для реалтайма

[Vladimir Kladov]

если масштаб 1:1, то ничего не надо - просто усреднение с весом. Для масштаба 1:2, 1:3, 1:4 можно применить следующий алгоритм. Есть 3 последовательных экрана Э1, Э2, Э3. В тех точках экрана, где ничего не меняется, вопросов как поступать - понятно, что нет. Это случай 111 и 000. Для точек, где что-то меняется, можно попробовать применить что-то вроде hqm-фильтра, но во времени. Берем матрицу 3х3 точки вокруг каждой точки, которая менялась, и отслеживаем ее изменение за последние 3 кадра. Итого на входе 27-разрядное значение, получается матрица решений в виде таблицы на 2**27 входов (128 млн.) Это много, но можно отдельно брать 4 матрицы 2х2. Т.е. для исходной матрицы
ABC
DEF
GHI
рассматривать 4 матрицы
AB BC DE EF
DE EF GH HI
Тогда получается 4 решения по 4 таблицам разрядности 12, т.е. каждая на 4096 входов. Теперь берем финальную таблицу, которая по 4 полученным решениям определяет, что конкретно делать с центральной точкой E.
В итоге можно решить (собственно, для чего весь сыр-бор), в какую сторону двигается данная конкретная точка. Например:

Э1 Э2 Э3
111 110 100
110 100 000
100 001 011

в данном случае центральная точка "движется" вместе с окружающими ее точками влево. Это значит, что при увеличении ее в 2, 3 или 4 раза левые части ее образа оставлям полностью закрашенными, и только самую правую точку в образе точку заполняем смешиванием по формуле (в формуле надо учесть, что наример для масштаба 2 уже 50% точки закрашено).

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

[GriV]

не подойдёт. если один конец линии закреплён, а другой движется, все точки линии движутся с разной скоростью. если на экране мячик движется в одну сторону, а текстура на нём - другую (illusion megademo), что тогда... а если плавающее месиво - популярный эффект "плазмы"? программы по морфингу двигают каждый пиксель - это не для реалтайма

1. Как правило только на движущихся прямоугольниках заметна "дрыганность" движения. На прочих объектах (например, поворачивающийся вокруг начальной точки луч) такая "дрыганность" менее заметна, потому что происходит сложное движение объекта.
2. Я тут подумал, что если брать такой алгоритм вплоть до полосок в 1 пиксель (т.е. движущийся луч будет состоять из таких полосок), тогда даже ошибки алгоритма (когда он принял изменение объекта за его движение) не будут портить картинку.

[SMT]

а всё-таки прав был Кладов... если пофиксить все ошибки, мерцать будеть намного меньше (но всё равно полностью от мерцания не избавится)