Реальный fps
 

Это-как бы продолжение этого топика(про быструю отрисовку воды)

Вобщем сейчас я в тупике) Разделил полностью прорисовку и просчёт. Прорисовка на EnterFrame, просчёт на Timer.

в прорисовке fps ставлю достаточно большой(просто как запас, по нему просто оцениваю производительность, потом сделаю меньше), но как и раньше, в самой отрисовке контролирую, чтобы не загружать проц лишними операциями прорисовки. Для этого выбираю реальный fps, например 60, считаю кол-во миллисекунд на кадр(1000/60), ну и пишу
Всё хорошо, но это 60 fps-магическое число, ведь как я понимаю на разных компах картинка реально отображаться может и с большей частотой.
Вот у себя, если ставлю меньше 60 fps, то движение капелек получается рывкообразным.

Короче, как узнать реальную частоту показа(то что видит юзер, и что стоит рисовать)? Можно ли провести тест какой-нибудь или как-нибудь иначе?

Или же есть какое-либо событие, которое возникает в тот момент, когда flash рисует кадр, а не таймеро-подобный EnterFrame?

>>Или же есть какое-либо событие, которое возникает в тот момент, когда flash рисует кадр, а не таймеро-подобный EnterFrame?


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

тебя совсем запутали. onEnterFrame возникает именно тогда, когда flash-рисует кадр. И при большом количестве математики onEnterFrame может возникать 10-15 раз(сколько успевает), при указанных 60fps.

А ты вообще сделал черти-что. Физику ты пересчитываешь onEnterFrame раз. А перерисовываешь по таймеру. А зачем тебе физику пересчитывать 100 раз в секунду? Все дожно быть наоборот.

Фпс пользователя тебя не должны интересовать вообще никак. Это его проблемы, если у него, скажем открыто 100 окошек, и флеш тормозит. Тебя должно волновать, чтобы независимо от тормозов, все пользователи видели одно и тоже, т.е. небыло такого, чтобы у одного юзера, скажем, герой игры, перемещался вдвое быстрее, чем у второго.

Для этого и переносят действия с нестабильного onEnterFrame на таймер. И математику и прорисовку. Чтобы система считалась со стабильной скоростью и отрисовывалась в память, а отрисуется на экран тогда, когда отрисуется.

Фпс не является главным показателем. За ним не надо гнаться. Пересчитывай и перерисовывай всего 5 раз по таймеру - вуаля - 120 фпс.

Главный показатель - плавное движение объектов при незагруженном процессоре.

>>Главный показатель - плавное движение объектов при незагруженном процессоре.
Верно, отсюда fps надо ставить 22-30, при этом проц среднего ЭВМ должен быть загружен меньше чем 90%, ибо когда больше 90% возможны тормоза и как следствие падение fps.

Сейчас у меня физика отдельным таймером. У всех сейчас вода будет двигаться с одинаковой скоростью. Ты возможно не совсем проблему понял.. Если поставить отрисовку на таймер 5 раз в секунду-то вуаля 5 раз в сек. у нас будет рисоваться на экране вода-а то бред. Физику мне надо просчитывать немного быстрее чем рисовать графику, т.е. совершенно отдельно. Она у меня сейчас в таймере и скорость симуляции просто регулируется изменением периода таймера. Перерисовка у меня в enterFrame(можно и в другой таймер сунуть, пофиг по-моему). Отрисовка воды-оч тяжёлая по времени, поэтому мне важно знать, сколько раз flash покажет экран, т.е. сколько раз мне надо для флэша нарисовать, чтобы разгрузить проц для других, более важных вещей(например та же физика, в которой я могу поднять точность, уменьшив dt в верлетовской интеграции и сам таймер).
Наверно я тут бред несу=) но возможно это вызвано тем, что AS я знаю отсилы 3 месяца, а в работе флэша вообще почти не разбирался)

Кстати, я обновил демки. водичка терь чёрная)

Не согласен с мнением, что физика и отрисовка должны быть на разных таймерах. Ибо они как минимум должны быть синхронизиранны во времени и их нестыковка будут видны на экране как рывки и дергания. В физике по моему есть такие шуки как dt или step, или еще чего-то как вам нравится, которые можно и нужно менять, а не таймер. Манипуляции с двумя таймерами больше подойдут для C++, где скорость повыше флеша будет, намного.

dt без изменения таймера будет работать как замедление/ускорение. ну на каждый тик таймера будет получаться движение на v(t)*dt, поэтому уменьшив вдвое dt надо уменьшить вдвое интервал таймера. Кажется бред, но это даст более правильный учёт сил, ибо ускорение - это dt^2

А пока, я разделил рисование и физику на 2 отдельных ветви и считаю это достаточно правильным.

по теме отвечу что...

http://ramshteks.cxcc.ru/2009/06/класс-performance/

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

вроде как там реальный фпс показывается

извиняюсь за оффтоп:
т.е. если энтерфрейм генерит событие независимо от того, выполнились ли связанные с ним действия или нет - то таймер дожидается, когда все вычисления произведутся и только потом запускает отсчет снова?

Нет. Код во флеше всегда выполняется в порядке очереди. Фактически timer такой же нестабильный, как и enterFrame. Просто с таймером у нас больше свободы, чем с fps. Например, теоретически можно сделать обновление экрана чаще, чем указанные в флешке fps, с помощью event.updateAfterEvent().
Надо, кстати проверить это.