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

[SMT]

а я не верю, что мерцание должно быть! вот там слева есть статическое изображение. Как его не усредняй по кадрам, он НЕ ДОЛЖНО меняться! Возможная причина мне думается - ошибки при усреднении, при использовании целочисленной арифметики (например). Советую проверить формулы на конкретных значениях, возможно отдельно от задачи

проверял и отдельно. фильтр вообще разрабатывал в Matlab DSP toolbox, примеры считал там без округлений. дело в том, что по-хорошему, после ресамплинга обязательно нужно ставить НЧ-фильтр на частоту среза, равную половине частоты дискретизации, иначе появляются "паразитные частоты" (альясинг). то есть зря я cutoff выключил по умолчанию в ini, надо было предусмотреть что-то среднее между 0-м и 1-м режимом. интересные твои рассуждения насчёт усреднения - ведь каждый новый кадр берёт исходные кадры с другими коэффициентами, иначе не видать плавности - отсюда и разные яркости

Вообще не пойму, почему надо было 4 кадра (да еще до и после)

зачем брать кадры до и после - очевидно, для симметрии. если брать только прошедшие кадры, то получим шлейф типа motion blur вслед за скроллом, а так - контуры отстоят от букв симметрично, inho это выглядит лучше. увы, приходится за это платить дополнительной задержкой, особенно заметной на программах, управляемых от мыши

я же говорил, что достаточно 2х

ради интереса я попробовал поставить интерполяцию по двум кадрам (благо, алгоритм гибкий): скролл плавный, хвостов совсем не видно, но мерцать стал сильнее. причём не только статика, но и сам скролл. на двух кадрах правильный нч-фильтр не сделаешь, как бороться с мерцанием - не знаю. если мысленно продолжить двигаться в сторону уменьшения числа смешиваемых кадров, получим ещё большее мерцание - на 2 кадра спектрума экспонируется один чёрный (если переводить 50hz в 75). такое сильно мерцание перейдёт уже в подёргивание

и продолжаю так и думать

попробуй. может, у тебя лучше получится

[Advertiser]

[Agent Cooper]

Справедливости ради, в обычном 0.28 эта демка смотрится куда приятнее.

[Spectre]

У меня эта версия работает следующим образом:

1) При Refresh=85 или 100 ругается DDERR_UNSUPPORTED (WinXPsp2+Radeon9550), при 0 и 60 плавности нету. Плавный скролл наблюдается только при 75Гц.
2) На больших скроллах немного заметен шлейф, из-за которого смазывается четкость букв.

[SMT]

Справедливости ради, в обычном 0.28 эта демка смотрится куда приятнее.

но ведь скролл дёргается...

[Paul Pavlov]

Хм, у меня тоже вылетает на частоте 100Гц (типа не поддерживается такой режим) WinXpSp2 GF5600. Да и AY звук играется рывками.

[GriV]

надо делать межкадровую интерполяцию, но очень хитрым способом: нужно брать два соседних кадра экрана zx, анализировать когда должен начать поход луч монитора, а затем только рассчитывать кадр. Причём рассчитывать смещение строки или каких то других элементов скролла, чтобы действительно не было рывков.

Пример:

Частота развёртки - 85 Гц
Частота экрана zx - 50 Гц

Тогда пусть между двум кадрам экрана ZX В данной итерации соответствует три кадра монитора (вообще то может оказаться и 1 и 2 и 3 - в зависимости от времени).

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

Тогда в первом кадре (кадры синхронизации) изображение спекка точно равно изображению на мониторе (просто копируются/преобразуются данные 1 в 1).
Во втором кадре монитора строка уже ушла с позиции в 1 пиксель, но ещё не дошла до позиции в 2 пикселя, тогда при приходе новой развёртки
строчка должна находиться в позиции 1,6 пикселя!!!
А при приходе следующего прерывания - в точке 2,2 пикселя!!!
И не должно быть ровных чисел (1 пиксель, 2 пикселя и т.д.) - они будут лишь в точке синхронизации.

[Vladimir Kladov]

чего ж тут хитрого? покомпонентное усреднение 2х или 3х экранов, со своим весом. (x1 * k1 + x2 * k2 + x3 * k3) / (k1 + k2 + k3), причем k1+k2+k3 = const.

[SMT]

Во втором кадре монитора строка уже ушла с позиции в 1 пиксель, но ещё не дошла до позиции в 2 пикселя, тогда при приходе новой развёртки
строчка должна находиться в позиции 1,6 пикселя!!!
А при приходе следующего прерывания - в точке 2,2 пикселя

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

чего ж тут хитрого? покомпонентное усреднение 2х или 3х экранов, со своим весом. (x1 * k1 + x2 * k2 + x3 * k3) / (k1 + k2 + k3), причем k1+k2+k3 = const

k1,k2,k3 не меняются от кадра к кадру?