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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Добавлено:

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