Видеостраницы, Как их использовать? Опции

[Shura]

Допустим, у нас есть две видеостраницы, и нужно сделать анимацию нескольких частично накладывающихся друг на друга изображений.
Чё то я понять никак не могу.... Рисуем все изображения на "задней" странице, а потом копируем её в видимую? Так что ли? Но это ж медленно...
Есть ли другой способ?

[volvo]

Рисуем все изображения на "задней" странице, а потом копируем её в видимую? Так что ли? Но это ж медленно...

Да нет, не совсем так... Если "копировать" видеостраницы одну в другую, то смысл в чем? Видеостраницы переключаются ...
Поиском пользовался? Эта тема уже поднималась... Например, здесь: http://forum.pascalnet.ru/index.php?showtopic=2417

[Shura]

А вот ещё проблемка. Если просто рисовать и переключать видеостраницу, то fps напрямую зависит от кол-ва рисуемого. Так как же зафиксировать время между переключениями?

[Shura]

Может вопрос не совсем ясен?

Ну вот, например. У какой-нибудь игры нормальное фпс 60. На нормальном компе бежим от одного дерева к другому за 15 секунд. Но это ж не значит что на слабеньком компе, где 15 фпс, мы будем бежать целую минуту! Т.е. тут какие-то кадры по необходимости отбрасываются. Но и на КРУТЮЩЕМ компе мы не будем "пролетать" это расстояние за секунду. Тут уж некоторые кадры отбрасываются "умышленно". Может это все и совсем не так, но на первый взгляд так и выглядит.

Кто шарит или мысли есть какие - поделитесь!

[Дож]

Все спрайты должны зависеть от реального времени и подстраиваются под него.

...бежим от одного дерева к другому...

Засекаем время, когда персонаж начал бежать от дерева. Когда обновляем положение спрайтов, расчщитываем, где должен быть персонаж, зная во сколько он начал бежать, в какую сторону, с какой скоростью и откуда. Теперь
сохраним новое положение персонажа, направление, скорость и текущее время. И так далее расчитываем до тех пор, пока персонаж не окажется в пункте назначения, в данном случае у второго дерева... ;)

Сообщение отредактировано: Дож - 3.06.2005 12:53

[Shura]

...рассчитываем, где должен быть персонаж...

Получается надо ещё не только "себя" ""рассчитать", но и остальные динам. объекты, так что ли? Значит вывод этих объектов нужно делать в самую последнюю очередь, после всех остальных подсчётов?

[Dark]

так и делается - сначало расчет изменений сцены а потом вывод графики =)

[Archon]

Можно ждать возврата луча перед сменой страниц. Тогда FPS будет зависеть от частоты мерцания монитора. Тему можно разрулить, добиться, чтобы на разных частотах работало одинаково...

[Shura]

Ну а если кадр не успеет отрисоваться до очередного мерцания?.. Один раз придётся ждать одного такта, другой - двух (ну или что-то типа этого). Я в на TP7 так делал - рывками всё двигается...

[Archon]

Ну а если кадр не успеет отрисоваться до очередного мерцания?..

есть косяк.... :yes: , но и современные игры, бывает, тормозят, тогда до второго дерева можно бежать дооолго........(ну, просто дольше, чем должно).

Я в на TP7 так делал - рывками всё двигается...

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

[Дож]

Получается надо ещё не только "себя" ""рассчитать", но и остальные динам. объекты, так что ли? Значит вывод этих объектов нужно делать в самую последнюю очередь, после всех остальных подсчётов?

Shura, здесь рассказывается об этом.

http://dronprogs.mirg.ru/stat/dgtemp.php?s...t_from=&ucat=3&

[Shura]

Ну так он же с Direct3D, OpenGL работает, про софтверную обработку ничего...
Однако, неплохой сайтик. А ты движок его юзал, или игры его скачивал?

[Дож]

Ну так он же с Direct3D, OpenGL работает

И все же идею про разделение расчетов и вырисовки можно использовать и для более примитивной графики. Все что нужно- хороший таймер.

А ты движок его юзал, или игры его скачивал?

Учусь юзать движок.

Добавлено:

Ну так он же с Direct3D, OpenGL работает,

Только с OpenGL. Dron's openGL Engine = DGLEngine