Просмотр полной версии : версия ёмулятора для просмотра демовых скроллов
вот оно, про что мы недавно обсуждали с 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 для проверки плавности скроллера
плавно... вот только у меня LCD мерцает как телевизор и изображение какоето светловатое...
Плохо. Идея верная, но пока реализована не ахти. У меня всё мерцает (поправка - я пока смотрел на 85 Гц). Есть мнение, что ничего у вас не получится пока вы не сделаете motion blur.
Almaz: светловатое - написано почему, это глюк такой
Pheel: именно 85 я не проверял, а другие частоты как? motion blur гораздо слабее и как частный случай более общего фильтра (то есть, в принципе, могут быть подобраны коэффициенты, совпадающие с mb, но тут они рассчитываются так, чтобы максимально сохранить частотную информацию)
кстати, "мерцание как телевизор" - это так и должно быть, можно сказать, это фича (после того, как насмотрюсь в пц-монитор, при переводе взгляда на телевизор мерцание заметно невооружённым глазом). кому не нравится - можно поиграться опцией cutoff
ps насчёт screen pheelter всё ещё помню, но постоянно забываю попинать друзей по поводу розысков photoshop-8 или самого PheeL'a насчёт конвертации scr-a, который я оставил в разделе "графика"
посмотреть не удалось. хотя и у меня 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
---------------------------
посмотреть не удалось. хотя и у меня 85гцнаверное, у Вас неправильный windows - почему оно советует переинсталлировать приложение, когда инсталлятора не существует :( или оно намекает, что инсталяцию нужно сделать с другим приложением ?...
Vladimir Kladov
03.04.2005, 12:37
а я не верю, что мерцание должно быть! вот там слева есть статическое изображение. Как его не усредняй по кадрам, он НЕ ДОЛЖНО меняться! Возможная причина мне думается - ошибки при усреднении, при использовании целочисленной арифметики (например). Советую проверить формулы на конкретных значениях, возможно отдельно от задачи.
2Random: поиск по компутеру наверняка найдет нужную dll, хоть в win2K хоть в XP. Если хотя бы что-то на нем устанавливалось кроме самой винды.
правка: да, забыл: я смотрю дома, здесь могу посмотреть только на 75Hz. экран прямо пыхает. Вообще не пойму, почему надо было 4 кадра (да еще до и после), я же говорил, что достаточно 2х, и продолжаю так и думать.
повторюсь:
http://downloads.mozdev.org/minimizetotray/minimizetotray/msvcr71.dll
а я не верю, что мерцание должно быть! вот там слева есть статическое изображение. Как его не усредняй по кадрам, он НЕ ДОЛЖНО меняться! Возможная причина мне думается - ошибки при усреднении, при использовании целочисленной арифметики (например). Советую проверить формулы на конкретных значениях, возможно отдельно от задачипроверял и отдельно. фильтр вообще разрабатывал в Matlab DSP toolbox, примеры считал там без округлений. дело в том, что по-хорошему, после ресамплинга обязательно нужно ставить НЧ-фильтр на частоту среза, равную половине частоты дискретизации, иначе появляются "паразитные частоты" (альясинг). то есть зря я cutoff выключил по умолчанию в ini, надо было предусмотреть что-то среднее между 0-м и 1-м режимом. интересные твои рассуждения насчёт усреднения - ведь каждый новый кадр берёт исходные кадры с другими коэффициентами, иначе не видать плавности - отсюда и разные яркости
Вообще не пойму, почему надо было 4 кадра (да еще до и после)зачем брать кадры до и после - очевидно, для симметрии. если брать только прошедшие кадры, то получим шлейф типа motion blur вслед за скроллом, а так - контуры отстоят от букв симметрично, inho это выглядит лучше. увы, приходится за это платить дополнительной задержкой, особенно заметной на программах, управляемых от мыши
я же говорил, что достаточно 2хради интереса я попробовал поставить интерполяцию по двум кадрам (благо, алгоритм гибкий): скролл плавный, хвостов совсем не видно, но мерцать стал сильнее. причём не только статика, но и сам скролл. на двух кадрах правильный нч-фильтр не сделаешь, как бороться с мерцанием - не знаю. если мысленно продолжить двигаться в сторону уменьшения числа смешиваемых кадров, получим ещё большее мерцание - на 2 кадра спектрума экспонируется один чёрный (если переводить 50hz в 75). такое сильно мерцание перейдёт уже в подёргивание
и продолжаю так и думатьпопробуй. может, у тебя лучше получится
Agent Cooper
03.04.2005, 18:42
Справедливости ради, в обычном 0.28 эта демка смотрится куда приятнее.
У меня эта версия работает следующим образом:
1) При Refresh=85 или 100 ругается DDERR_UNSUPPORTED (WinXPsp2+Radeon9550), при 0 и 60 плавности нету. Плавный скролл наблюдается только при 75Гц.
2) На больших скроллах немного заметен шлейф, из-за которого смазывается четкость букв.
Справедливости ради, в обычном 0.28 эта демка смотрится куда приятнее.но ведь скролл дёргается...
Paul Pavlov
07.04.2005, 20:38
Хм, у меня тоже вылетает на частоте 100Гц (типа не поддерживается такой режим) WinXpSp2 GF5600. Да и AY звук играется рывками.
надо делать межкадровую интерполяцию, но очень хитрым способом: нужно брать два соседних кадра экрана zx, анализировать когда должен начать поход луч монитора, а затем только рассчитывать кадр. Причём рассчитывать смещение строки или каких то других элементов скролла, чтобы действительно не было рывков.
Пример:
Частота развёртки - 85 Гц
Частота экрана zx - 50 Гц
Тогда пусть между двум кадрам экрана ZX В данной итерации соответствует три кадра монитора (вообще то может оказаться и 1 и 2 и 3 - в зависимости от времени).
Пусть бежит бегущая строка, в первом кадре экрана zx она находится на позиции с смещением 1 пиксель относительно бордюра, во втором кадре - со смещением 2 пикселя относительно бордюра.
Тогда в первом кадре (кадры синхронизации) изображение спекка точно равно изображению на мониторе (просто копируются/преобразуются данные 1 в 1).
Во втором кадре монитора строка уже ушла с позиции в 1 пиксель, но ещё не дошла до позиции в 2 пикселя, тогда при приходе новой развёртки
строчка должна находиться в позиции 1,6 пикселя!!!
А при приходе следующего прерывания - в точке 2,2 пикселя!!!
И не должно быть ровных чисел (1 пиксель, 2 пикселя и т.д.) - они будут лишь в точке синхронизации.
Vladimir Kladov
11.04.2005, 18:29
чего ж тут хитрого? покомпонентное усреднение 2х или 3х экранов, со своим весом. (x1 * k1 + x2 * k2 + x3 * k3) / (k1 + k2 + k3), причем k1+k2+k3 = const.
Во втором кадре монитора строка уже ушла с позиции в 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 не меняются от кадра к кадру?
сегодня проверял на CRT-мониторах. глюк такой-же: в режимах ниже 640x480 как ati, так и nvidia драйвера мудрят с частотой развёртки. обязатально нужно ставить minres=480. по-хорошему, надо делать удвоение разрешения, а то был просто пример реализации технологии. ещё глюк нашёл на AMD - пишет "0 fps" из-за того, что нет emms между mmx и fpu-вычислениями. интелу это без разницы
Vladimir Kladov
12.04.2005, 19:48
k1,k2,k3 не меняются от кадра к кадру?
не меняется сумма. Я извиняюсь, неужели я непонятно выразился? Просто у меня 2,5 математического образования (технарь, 3курса чистой математики + полный курс прикладной математики в универе), и мне трудно думать в каких-то иных категориях.
ещё глюк нашёл на AMD - пишет "0 fps" из-за того, что нет emms между mmx и fpu-вычислениями. интелу это без разницы
у меня Pentium M (тот который Centrino), на нем тоже 0 fps
попробуйте набросать алгоритм (не заботясь пока о ресурсах) имеем набор спековских кадров, хоть в 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 пикселей.
Вот и весь алгоритм.
не подойдёт. если один конец линии закреплён, а другой движется, все точки линии движутся с разной скоростью. если на экране мячик движется в одну сторону, а текстура на нём - другую (illusion megademo), что тогда... а если плавающее месиво - популярный эффект "плазмы"? программы по морфингу двигают каждый пиксель - это не для реалтайма
Vladimir Kladov
13.04.2005, 21:35
если масштаб 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Гц, даже при условии очень хорошей равномерности отображения).
не подойдёт. если один конец линии закреплён, а другой движется, все точки линии движутся с разной скоростью. если на экране мячик движется в одну сторону, а текстура на нём - другую (illusion megademo), что тогда... а если плавающее месиво - популярный эффект "плазмы"? программы по морфингу двигают каждый пиксель - это не для реалтайма
1. Как правило только на движущихся прямоугольниках заметна "дрыганность" движения. На прочих объектах (например, поворачивающийся вокруг начальной точки луч) такая "дрыганность" менее заметна, потому что происходит сложное движение объекта.
2. Я тут подумал, что если брать такой алгоритм вплоть до полосок в 1 пиксель (т.е. движущийся луч будет состоять из таких полосок), тогда даже ошибки алгоритма (когда он принял изменение объекта за его движение) не будут портить картинку.
а всё-таки прав был Кладов... если пофиксить все ошибки, мерцать будеть намного меньше (но всё равно полностью от мерцания не избавится)
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot