Реальный 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().
Надо, кстати проверить это.

Вы о чем?..
ENTER_FRAME будет вызываться каждый раз, когда флеш-плееру НАДО отрисовать кадр. Сказали - он рассылает событие, но экран не обновляет. После него прямо перед обновлением экрана идет событие RENDER.
И зачем перекладывать "с нестабильного (???) ENTER_FRAME" на "стабильный Timer" ?
В 1 случае вся игра затормозит из за падения фпс, во 2 случае - фп скорее повеситься, а если и не повеситься - то на экране у юзера будет черти что.
Единственное, что может быть в реалтайм мморпг сие рывки будут правильнее общих тормозов всего и вся, но если у автора появился этот вопрос - он не мморпг делать собрался.

Затем перекладывать на таймер, что это дает более высокое и стабильное обновление экрана!
Вот в этой http://www.8bitrocket.com/newsdispla...newspage=10248 статье, по-моему все замечательно раскрыто.

Psycho Tiger, бред.
ENTER_FRAME - вызывается когда происходит вхождение в новый кадр. то есть предыдущий отрисован.
RENDER - рассылается, на сколько я помню, если вызывать Stage#invalidate()
причём тут мморпг я вообще молчу.

Примерно это я имел ввиду. Кадр отрисован, и идет вхождение в новый кадр - тогда и вызывается.
RENDER надо заставить рассылаться вручную - это другой вопрос, если нужно поймать событие, когда уже всё готово к отрисовке, но отрисовка ещё не пошла - его мы и ловим.
Просмотрел бегло статью. Самый веский аргумент - потеря фпс в IE. Давно ещё тесты проводил, это не относиться к "тормозам" - как самый быстрый тест - увеличиваем фпс вдвое и смотрим - если бы с ENTER_FRAME были реально тормоза - фп готов был бы повеситься, а нет, все идет нормально. Как учесть - вполне, но все же отказываться от ENTER_FRAME я пока не собираюсь - слишком сомнительны условия.

Да, про реалтайм мморпг, что я хотел сказать:
если фпс вдруг падает, то ENTER_FRAME реже рассылается в единицу времени. Если он реже рассылается, значит идет меньше пересчетов, но игровые константы не меняются, то есть попросту говоря в игре как бы замедляется время. В обычной синглплеер игре это не очень критично, если на старых машинах в критичные моменты упадет 10 фпс.
Если игра онлайновая, то придав какому нибудь обьекту "а ля" бомба, падающая сверху позицию и ускорение - она полетит вниз, и при столкновении с землей она взорвется. При подобном падении фпс эта бомба взорвется до соприкосновения с землей, что вызовет негодования у игрока. В случае с таймером - игра пойдет менее плавно, рывками, но бомба упадет именно в срок. Так понятней, что я имел ввиду?

Если фпс ниже заданного, ваше "стабильное" событие таймера вообще может не вызываться.

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

Psycho Tiger, у Вас каша в голове. зачем заставлять рассылаться RENDER? чем он будет от ENTER_FRAME отличаться? Вы отличаете тормоза от ограничения ФПС? сколько ММОРПГ Вы написали? Вы когда-нить слышали про формулу зависимости от времени? Вы вообще понимаете как таймер в АС3 работает?

Яски, ну хоть у Вас здравые мысли в голове.

прозвучал вопрос о событии "прямо" перед отрисовкой. Я сказал, что это не ENTER_FRAME, а RENDER.
Если ФПС ниже положенного, это тормоза.
0.
Бывало.
Существуют мысли, что как более стабильный и удобный setInterval

Да, у Яски хорошая идея.

ну так это неправда. а моём понимании, это когда проц не справляется с задачей. а как setInterval работает Вы понимаете?

В AS3 добавлено новое событие Event.RENDER (flash.events.Event.RENDER), которое рассылается после enterFrame, но перед тем, как экран флеш-плеера обновится. (пруфлинк)
Что то ещё произойдет после RENDER`а, но перед отрисовкой? Буду рад, если скажешь, что именно и где я не прав.

Если проц не справляется с задачей - это вызывает тормоза. Смысл-то один. Или "тормоза" используется здесь не в плане что всё работает медленнее, чем должно, а это какой-то новый термин?
Через определенные промежутки времени вызывает функцию/метод. Timer рассылает событие. Нет, я не прав?

везде прав, кроме места применения. рендер будет вызываться ровно столько раз сколько и enter_frame, собственно, тогда нафига он тут нужен?
оно работает не совсем медленнее. просто искусственно занижен ФПС. проблема решается тем, что все расчёты делаются не в зависимости от количества кадров, а от времени, которое прошло. неправы в двойне. во-первых никакого события setInterval не рассылает, а во вторых, совсем не через определенные.

не ошиблись ?

извиняюсь, что встреваю. Всегда плотно слежу за подобными диалогами. Ибо в них рождается истина :quiet:

Да ошибка)
А вы чё тут грызётесь то так?

switcher!, ну тогда единожды :) прошу прощения.

Герыч, хм как бы вы совсем накосячили с FPS. У меня ваши примеры показывают от 170 - 1900FPS, хотя реально там до 72 :).

реально там 60 кадров в секунду обновление. Сейчас всё переделал) Но в голове немного не укладывается всё это всё равно)

я тебе еще один способ блобы рисовать нашел
http://www.lecrabe.net/blog/?post/20...3-bezier-blobs

Оч нереалистично рисует! у меня лучше намного

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

как правило, всегда есть что-то, что достаточно легко можно оптимизировать таким способом. например синусы-косинусы можно предварительно загнать в таблицу и извлекать оттуда. Я проверял - это работает примерно в 5раз быстрей, чем Math.sin()
ну и тд.
Очень часто в таблицу можно вообще загнать готовый результат, чтобы не считать его в риалтайме.

В программах компьтерной симуляции всё делается через substep, которых больше чем кадров на заданное количество(обычно постоянное).
Просто на каждом шаге считать физику, а отрисовывать только на каком-либо кратном кадре.
Вроде данный вариант не рассматривался, но не знаю приемлим ли он в силу реалтайма и всех проблем с EnterFrame и interval(если таковые реальны, а не результат недознания)