профессионалам Direct3D и другому выводу графики
Сам писать не буду, но могу дать два совета:
1) Наиболее красиво хрень будет смотреться на CRT мониторе если сдвигать на один пиксель с частотой развёртки (с VSYNC, естественно). Фишка в том, что человеческий глаз на самом деле развёртку замечательно видит, хоть и не сообщает об этом наверх непосредственно. Поэтому если ему показывать так движущуюся хрень, то он верит, что ему на самом деле показывают непрерывно движущуюся хрень через быстро-быстро двигающееся узенькое окошко, и всё отлично (при этом, кстати, кажется, что она наклонена на один пиксель). А если, скажем, сдвигать на два пикселя каждый второй кадр, или даже на один, но тоже раз в два кадра, то он понимает, что его обманывают, и видит мерзостно размытую картинку. Как он реагирует на сдвиг на два пикселя за кадр, или на LCD-монитор — не знаю, не проверял, но подозреваю, что тоже плохо. Так что если собираетесь ффтыкать в картинку долго и упорно, имейте в виду.
2) Если сделать правильно, то никаких проблем со скоростью быть не должно. Правильно — это 1280 вертикальных полосок, текстурированных одномерными текстурами, на каждом шаге присылается новая одномерная текстура и они все перерисовываются. Это более чем подъёмно на любом не очень старом компе.
Если делать неправильно, например присылая на каждом шаге новую текстурку 1280х1024 (а реально — 2048х1024, потому что не степени двойки мало какая видеокарта держит то это по 8 метров на кадр, то есть 480 мегабайт в секунду на 60Гц, что уже как-то довольно дофига.
Вот так!
1) Наиболее красиво хрень будет смотреться на CRT мониторе если сдвигать на один пиксель с частотой развёртки (с VSYNC, естественно). Фишка в том, что человеческий глаз на самом деле развёртку замечательно видит, хоть и не сообщает об этом наверх непосредственно. Поэтому если ему показывать так движущуюся хрень, то он верит, что ему на самом деле показывают непрерывно движущуюся хрень через быстро-быстро двигающееся узенькое окошко, и всё отлично (при этом, кстати, кажется, что она наклонена на один пиксель). А если, скажем, сдвигать на два пикселя каждый второй кадр, или даже на один, но тоже раз в два кадра, то он понимает, что его обманывают, и видит мерзостно размытую картинку. Как он реагирует на сдвиг на два пикселя за кадр, или на LCD-монитор — не знаю, не проверял, но подозреваю, что тоже плохо. Так что если собираетесь ффтыкать в картинку долго и упорно, имейте в виду.
2) Если сделать правильно, то никаких проблем со скоростью быть не должно. Правильно — это 1280 вертикальных полосок, текстурированных одномерными текстурами, на каждом шаге присылается новая одномерная текстура и они все перерисовываются. Это более чем подъёмно на любом не очень старом компе.
Если делать неправильно, например присылая на каждом шаге новую текстурку 1280х1024 (а реально — 2048х1024, потому что не степени двойки мало какая видеокарта держит то это по 8 метров на кадр, то есть 480 мегабайт в секунду на 60Гц, что уже как-то довольно дофига.
Вот так!
Как он реагирует на сдвиг на два пикселя за кадр, или на LCD-монитор — не знаю, не проверял, но подозреваю, что тоже плохоскорее хорошо, чем плохо.
т.к. в фильмах все движется довольно быстро(уж точно больше, чем на один пиксель но это никого не расстраивает.
ps
кстати 99% населения отдельные пиксели все-таки не видят, поэтому вообще не понятно почему считается, что 1 пиксель как-то сильно отличается от нескольких.
кстати 99% населения отдельные пиксели все-таки не видят, поэтому вообще не понятно почему считается, что 1 пиксель как-то сильно отличается от нескольких.зато остальные 1% уже натренировались на глаз артефакты кодирования fullhd определять.
т.к. в фильмах все движется довольно быстро(уж точно больше, чем на один пиксель но это никого не расстраивает.Ха, нет!
Если ты возьмёшь любой фильм и поставишь его на стоп-кадр в каком-нибудь напряжённом моменте, то увидишь, что там уже есть размытость. Так что в результате конечно получается не очень хорошо, но глаза обманываются и не напрягаются.
А когда ты выводишь абсолютно чёткие картинки, но "неправильно", возникает не очень приятное ощущение. Именно близость к идеалу, но неидеальность напрягает. Ну, в тех же компьютерных играх — там картинки чёткие, но большие сдвиги (когда поворачиваешься, например поэтому глаз (точнее всё-таки зрительная кора) как бы забивает на попытки сличить соседние изображения попиксельно и чувствует себя отлично. А когда у неё все возможности это сделать есть, но результат получается фиговый, то, ну, результат получается фиговый =)
PS: доказывать это словами бессмысленно, то, что я здесь пишу — это объяснение реального эффекта, если ты проверишь, то увидишь, что так всё и есть, но убедить тебя в том, что так должно быть, я, естественно, не могу.
спасибо за полезную информацию, тем не менее возникает вопрос, в реальной задаче у меня приходит 4 линии в кадр (если быть более точным то 4 линии каждые 16мс соотв отрисовка конечной программы будет вестись по 4 линии, мне кажется что DarkGrey правильно говорит, и соседние кадры сдвинутые на 1 или 2 пикселя отличаться не будут, иначе как делать "правильную картинку"? каждый нечетный кадр размывать чем-то вроде FSAA?
иначе как делать "правильную картинку"?ИМХО, чтобы сделать плавную картинку, сдвигать надо не на целые числа. (Глаз вполне можно обмануть, если на целый пиксель будет сдвигаться каждый третий кадр, например. Или, в случае когда прорисовка медленнее поступающих данных, если каждый кадр будет сдвигаться на 2-3-2-3-2-... пикселей.) Кроме того, в DirectX пиксель определяется не целыми числами (для попадания в пиксель целое число надо изменять на 0.5). FPS надо выжимать по максимуму, а сдвиг картинки делать в реальном времени. Стандартная практика в играх: рисуем, смотрим время, вычисляем новое смещение в зависимости от текущего времени (смещение может быть не целым числом). Это позволит плавно отображать данные, независимо от скорости отрисовки и скорости прокрутки.
А сколько линий в секунду-то?
Ну если так, то да, наверное размывать. Только FSAA дорогой, лучше ручками как-нибудь нахалявку — типа выводить не однопиксельные линии, а двух- или даже трёх-пиксельные прямоугольнички с полупрозрачным краем.
Ну если так, то да, наверное размывать. Только FSAA дорогой, лучше ручками как-нибудь нахалявку — типа выводить не однопиксельные линии, а двух- или даже трёх-пиксельные прямоугольнички с полупрозрачным краем.
в реальной задаче приходит 120 линий в секунду.
в реальной задаче приходит 120 линий в секунду.Сделай, как в играх. Я написал выше. И не надо ничего размывать.
Сделай, как в играх. Я написал выше. И не надо ничего размывать.да размытие это уже второй вопрос.
мне бы это просто надо сделать
Оставить комментарий
pupsik77
есть 2 задачи:первая: есть картинка (скажем в формате PNG/BMP) размером 2560 х 1024 пиксела (ширина 2560 необходимо часть ее отобразить на полный экран 1280х1024, а длаьше начать двигать скажем влево (по 1, 2 или 4 столбца при выходе на конец картинки начать делать это сначала. Т.е. показывать циклически.
теперь подзадачи:
1. сдвигать с максимальной скоростью рендеринга и считать ФПС со включенным и выключенным Wait-for-VSync
2. сдвигать со скоростью 1/2/4 столбца с заданной фиксированной скоростью 25/30/60 сдвигов в секунду (для каждой ширины столбца)
задача вторая - то же самое, НО вместо картинки рэндомные данные, т.е. новый столбец (1/2/4) генрится в рилтайме, чтобы время генерации столбца не было критичным можно использовать любую функцию изменения данных хоть rand, хоть просто ++, важно понять скорость рендеринга.
за пример я готов заплатить некоторое кол-во денег.
собственно интересует самый быстрый способ отображения в количественном измерении.
Кому интересно сделать такую задачу?