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

Вид для печати

02.04.2005, 20:55
SMT

Вложений: 2

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

вот оно, про что мы недавно обсуждали с Vladimir Kladov тут на форуме!
просьба к Wlodek опубликовать этот текст и ссылку на RAR в фидо:

Код:

специальная версия unreal speccy с необычным видеорежимом: передискретизация видео-потока 50hz в частоту развертки PC-монитора (60,70,75,100,120,... hz). используется независимая высококачественная обработка 320*240*3(цвета) каналов, каждый кадр интерполируется по 4 предыдущим и 4 последующим кадрам. на обработку тратится примерно 30% процессорного времени Celeron-800, обязательно наличие MMX, 32-битного режима с разрешением не менее 320x240. возможно наложение НЧ-фильтров с частотами отсечения 25hz (обычная 50hz-развёртка), 12hz (gigascreen), 8hz (3color) - настраивается в ini опцией [VIDEO]Cutoff известные проблемы: на LCD-мониторах при попытке установить режим 320x240 с частотами выше 60hz включается развёртка 60hz, но система думает, что используется запрошенная частота. это приводит к рассинхронизации с эмулятором и торможению. решение: установить minres=600, в режиме 800x600,1024x768,1280x1024 могут использоваться частоты, отличные от 60hz известные проблемы: используется 8-битная mmx-арифметика; во избежание переполнений сужен динамический диапазон цветовых компонент до #40-#C0 - изображение неконтрастное (но 16-битная арифметика в 1.5 раза медленнее) максимальное качество достигается на CRT-мониторах с частотами 100-120 hz

unre50hz.rar - эмулятор, 7scrolls.rar - часть из insult megademo для проверки плавности скроллера
02.04.2005, 23:07
Almaz

плавно... вот только у меня LCD мерцает как телевизор и изображение какоето светловатое...
03.04.2005, 01:27
PheeL

Плохо. Идея верная, но пока реализована не ахти. У меня всё мерцает (поправка - я пока смотрел на 85 Гц). Есть мнение, что ничего у вас не получится пока вы не сделаете motion blur.
03.04.2005, 02:11
SMT

Almaz: светловатое - написано почему, это глюк такой
Pheel: именно 85 я не проверял, а другие частоты как? motion blur гораздо слабее и как частный случай более общего фильтра (то есть, в принципе, могут быть подобраны коэффициенты, совпадающие с mb, но тут они рассчитываются так, чтобы максимально сохранить частотную информацию)
03.04.2005, 02:21
SMT

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

ps насчёт screen pheelter всё ещё помню, но постоянно забываю попинать друзей по поводу розысков photoshop-8 или самого PheeL'a насчёт конвертации scr-a, который я оставил в разделе "графика"
03.04.2005, 10:32
random

посмотреть не удалось. хотя и у меня 85гц:

---------------------------
unre50hz.exe - Unable To Locate Component
---------------------------
This application has failed to start because MSVCR71.dll was not found. Re-installing the application may fix this problem.
---------------------------
OK
---------------------------
03.04.2005, 12:36
SMT

Цитата:

Сообщение от random

посмотреть не удалось. хотя и у меня 85гц

наверное, у Вас неправильный windows - почему оно советует переинсталлировать приложение, когда инсталлятора не существует :( или оно намекает, что инсталяцию нужно сделать с другим приложением ?...
03.04.2005, 12:37
Vladimir Kladov

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

2Random: поиск по компутеру наверняка найдет нужную dll, хоть в win2K хоть в XP. Если хотя бы что-то на нем устанавливалось кроме самой винды.

правка: да, забыл: я смотрю дома, здесь могу посмотреть только на 75Hz. экран прямо пыхает. Вообще не пойму, почему надо было 4 кадра (да еще до и после), я же говорил, что достаточно 2х, и продолжаю так и думать.
03.04.2005, 12:59
Almaz

повторюсь:
http://downloads.mozdev.org/minimize...ay/msvcr71.dll
03.04.2005, 17:55
SMT

Цитата:

Сообщение от Vladimir Kladov

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

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

Цитата:

Сообщение от Vladimir Kladov

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

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

Цитата:

Сообщение от Vladimir Kladov

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

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

Цитата:

Сообщение от Vladimir Kladov

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

попробуй. может, у тебя лучше получится
03.04.2005, 18:42
Agent Cooper

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

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

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

Цитата:

Сообщение от Agent Cooper

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

но ведь скролл дёргается...
07.04.2005, 20:38
Paul Pavlov

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

На самом деле, чтобы скроллы игрались замечательно

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

Пример:

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

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

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

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

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

Цитата:

Сообщение от GriV

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

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

Цитата:

Сообщение от Vladimir Kladov

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

k1,k2,k3 не меняются от кадра к кадру?
12.04.2005, 18:06
SMT

сегодня проверял на CRT-мониторах. глюк такой-же: в режимах ниже 640x480 как ati, так и nvidia драйвера мудрят с частотой развёртки. обязатально нужно ставить minres=480. по-хорошему, надо делать удвоение разрешения, а то был просто пример реализации технологии. ещё глюк нашёл на AMD - пишет "0 fps" из-за того, что нет emms между mmx и fpu-вычислениями. интелу это без разницы
12.04.2005, 19:48
Vladimir Kladov

Цитата:

Сообщение от SMT

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

не меняется сумма. Я извиняюсь, неужели я непонятно выразился? Просто у меня 2,5 математического образования (технарь, 3курса чистой математики + полный курс прикладной математики в универе), и мне трудно думать в каких-то иных категориях.
12.04.2005, 22:40
elf/2

Цитата:

Сообщение от SMT

ещё глюк нашёл на AMD - пишет "0 fps" из-за того, что нет emms между mmx и fpu-вычислениями. интелу это без разницы

у меня Pentium M (тот который Centrino), на нем тоже 0 fps
13.04.2005, 17:24
GriV

Цитата:

Сообщение от SMT

попробуйте набросать алгоритм (не заботясь пока о ресурсах) имеем набор спековских кадров, хоть в 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 пикселей.
Вот и весь алгоритм.
13.04.2005, 20:24
SMT

не подойдёт. если один конец линии закреплён, а другой движется, все точки линии движутся с разной скоростью. если на экране мячик движется в одну сторону, а текстура на нём - другую (illusion megademo), что тогда... а если плавающее месиво - популярный эффект "плазмы"? программы по морфингу двигают каждый пиксель - это не для реалтайма
13.04.2005, 21:35
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Гц, даже при условии очень хорошей равномерности отображения).
14.04.2005, 18:21
GriV

Цитата:

Сообщение от SMT

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

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

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