fps - когда и сколько

[Akopalipsis]

Хочется спросить у опытных, сколько fps Вы используете и какие есть случаи, на которых Вы выработали
его изменение?
А спросил я это вот по чему - всегда считал, что для анимации 30 кадров, это более чем хорошо.
Но на форуме попались упоминания о 60 и при чём не от одного и того же форумчанина.
А в гугле нашёл, что от 27-37+, в зависимости от самой анимации. Вот я и решил всё разузнать.

[KumoKairo]

Для мобильных приложений хорошим тоном считается ориентироваться на 60 fps - идеальный случай. На самом деле выбирать особо не приходится - эта планка давно определена (насколько я знаю - это предел частоты обновления LCD экрана с включенной V-Sync)

[caseyryan]

Чем больше кадров, тем плавнее анимация.
Откуда взялось 60 кадров? Просто было выявлено, что средняя частота обновления картинки в человеческом глазе, составляет около 55 - 60 раз в секунду. Больше глаз просто не сможет увидеть, поэтому делать больше нет смысла.

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

[dark256]

Присоединяюсь. Ставлю 30.
Но если у вас 60, и на onEnterFrame (к примеру ) висит достаточно тяжелый обработчик событий, а экшена, как такового, не присутствует, то вы будете грузить систему на ровном месте ни для чего....

[Akopalipsis]

Всем Большое Спасибо! Вчера, продолжая эксперименты, немного был удивлён.
Поставил getTimer + Timet и сделал частоту 60fps ( 1000/60 ) и ещё u, pdateAfterEvent в обработчик засунул.
Сначала трейсел, а потом начал в текстовое поле выводить и оказалось, что по истечении шести секунд,
проходило около ста кадров, десять секунд === 240. Это вообще без всего с одним текстфилдом. При ( 1000/30 ), такая же история.
И у меня ещё вопрос - работа твинов, она же на getTimer + Timet построена?

[Dukobpa3]

60 кадров для более-менее нагруженной анимации часто много, начинает лагать, если еще математики много то становится заметно. То же самое на 30 кадров будет ровнее. Так как длина кадра для расчетов больше.
В то же время на 30 кадрах всякие медленные твины типа, плавненького выезжания окошек, становятся заметно пошаговыми и вполне заметными для глаза.
Опытнным путем подобрал себе 40-45 фпс, этим и пользуюсь обычно. И анимации более гладкие получаются, и лагает из-за частоты обновления меньше.
Это касается стандартного ДЛ. В то же время на старлинге, с небольшим кол-вом объектов удавалось добиться под 100+ фпс :)

по истечении шести секунд проходило около ста кадров
updateAfterEvent лучше убрать. Он способен всё повесить. Им надо пользоваться оч аккуратно, и там где вы действительно понимаете зачем это надо.

[Akopalipsis]

Dukobpa3 Спасибо!
updateAfterEvent лучше убрать. Он способен всё повесить. Им надо пользоваться оч аккуратно, и там где вы действительно понимаете зачем это надо.
Смотрите, если у меня есть сто обьектов, которые нужно анимировать, плавное движение, то можно сделать анимацию построенную на времени и контролировать самый верхний уровень раздачи время. У меня получилось уравновесь время, но по замерам кадров у меня не стыковка... Ведь маленькое подёргивание из-за провалов в обновлении экрана. В таких случаях оправданно пользоваться updateAfterEvent?

[Dukobpa3]

В анимациях это вообще не оправдано.

Добавлено через 10 минут
Про анимацию построенную на времени тоже писали.
Анимацию надо строить на энтерфрейме. Но можно мерять время с предыдущего кадра, чтобы иметь возможность подогнать ее.

Например спрайт должен пролететь 100 пкс, за 2 секунды.
Допустим у нас 60 кадров в секунду.
16.67мс на отрисовку одного кадра.
20мс на один пиксель.

Вот мы и считаем. Стандартная наша скорость будет ~3пкс за 4 кадра.
Если с предыдущего кадра прошло больше чем 20мс(вместо 16.67) - значит смело подвигаем на целый пиксель или больше, в зависимости от задержки. Если меньше (что маловероятно) оставляем на том же месте, но сохраняем в буфер "не использованную задержку" чтоб на следующем кадре посчитать всё вместе.

Я скидывал свой менеджер анимаций в какой-то из тем. Там это реализовано есть. Но там покадровая анимация, чтоб можно было с нужно скоростью анимации проигрывать. С твинами будет так же.

Добавлено через 12 минут
а updateAfterEvent - теоретически вызывает отрисовку немедленно, что очевидно, еще более нагружает систему. А нам при отставаниях ее наоборот разгрузить надо. (Могу ошибаться, так как пользовался этой функцией всего один раз).
Да и вцелом не вижу смысла в updateAfterEvent. Оно и так и так в следующем кадре отрисуется, такова уж система работы флеша. И если он понадобился скорее всего проблема в другом месте. Но иногда, например при драг-ен-дропах - это необходимо.

[Akopalipsis]

Анимацию надо строить на энтерфрейме.
Вы меня извините за мою настойчивость, но мне хочется разобраться во всём.
В пример я создал EF с частотой 45 кадров. Когда я решаю сколько кадров выбрать, то руководствуюсь тем, что анимация будет обновляться столько раз, сколько кадров. И вот я вижу, что за десять секунд не хватает 150 кадров и анимация передвижения дергается. Вот почему лучше использовать EF + твины для сглаживания, если можно поставить 1fps, но запустить таймер с частотой обновления 45 раз в секунду, замерять время + его подгонять + updateAfterEvent, который будет вызываться точно 45 раз.
Вот почему такой подход не правильный, а создавать много разных твинов ( ведь обьектов много и двигуются они все с разной скорость ), это хорошо? А с таймером я и без лишней нагрузки ( без твинов ) задавать им разную скорость и уверен что лагов не будет, ведь частота обновления будет именно 45 раз.
package
{
import flash.display.Sprite;
import flash.events.Event;
import flash.events.MouseEvent;
import flash.events.TimerEvent;
import flash.utils.getTimer;
import flash.utils.Timer;

public class Main extends Sprite
{
private var _timer:MyTimer;
private var _lastTime:Number

private var _counterFrame:Number = 0;
private var _counterTime:Number = 0;

private const FRAME_RATE:Number = 60 / 1000;
private const COUNTER_FRAME:Number = 60;
private var _testTime:Number = 0;

private var _render:TimerEvent;
private var _cube:Cube;

public function Main()
{
init();
}
private function init(event:Event=null):void
{
removeEventListener(Event.ADDED_TO_STAGE, init);
stage.addEventListener(MouseEvent.CLICK, stage_clickHandler);

_cube = new Cube();
addChild(_cube);
_timer = new MyTimer(FRAME_RATE);
_render = new TimerEvent(TimerEvent.TIMER);
}

private function stage_clickHandler(event:MouseEvent):void
{
stage.addEventListener(Event.ENTER_FRAME, stage_enterFrameHandler);
_lastTime = getTimer() * 0.001;
}

private function stage_enterFrameHandler(event:Event):void
{
var currentTime:Number = getTimer()* 0.001;
var elapsedTime:Number = (currentTime-_lastTime)
_lastTime = currentTime;
_testTime += elapsedTime;
_counterFrame++;
this.time(elapsedTime)
//this.render(_render);
}
private function time(time:Number):void
{
_counterTime += time;
_cube.x=_counterTime
trace(_counterFrame,_counterTime);
}
private function render(event:TimerEvent):void
{
event.updateAfterEvent();
}
}
}

[Dukobpa3]

Вместо небольших лагов раз в кадр ты хочешь один большой раз в секунду?
Ок.

Добавлено через 1 минуту
Научись сначала стандартными методами пользоваться, а потом уже если не хватит - свои велосипеды.
Но я думаю когда научишься использовать то что есть - и велосипеды будут иначе выглядеть.

[Akopalipsis]

Dukobpa3 я согласен с Вами. И ещё делая анимацию на время, я естественно заметил, что если запускать её сразу, то происходит скачок, так как время считается с момента запуска плеера. И вот когда я разочаровался в TweenMax, то скачал рекомендуемую Вами изи.
И вот там тоже самое, такой же скачок. Значит они тоже строют её на времени. У макса такой беды нет, у него своя хитрая временная шкала. Вот и получается, что можно подгонять приложение под твины, а можно сделать свою временную шкалу и в большинстве случаев твины не понадобятся.

[Dukobpa3]

Тут какая штука.
Или твины или свой таймлан.
Комбинировать надо грамотно.
Напрмиер покадровые анимации с заданной скростью я изначально пытался разрулить твинером (изи умеет кадры прокручивать), но есть свои ньюансы, потому пришлось писать свою.
Во всех остальных случаях я не заморачиваюсь и использую твины.

Ну и я обычно использую разделение следующим образом:
Анимации сугубо графики - твины.
Анимации по математике - своё. (Т.е. к примеру горизонтальный скроллер у меня был, там мухи летели по некоей траектории. И столкновения считались математикой, а не коллизиями спрайтов. Так вот анимация движения мух - свой велосипед по ентер-фрейму. А всякие махания крылышками и партиклы - твины).

[Psycho Tiger]

Просто было выявлено, что средняя частота обновления картинки в человеческом глазе, составляет около 55 - 60 раз в секунду.
Вот кстати любопытный момент: всё детство мне рассказывали про 24. Чему верить? :D

[Akopalipsis]

Вот кстати любопытный момент: всё детство мне рассказывали про 24. Чему верить?
я тоже первым делом пошёл в гуглы и .. и там 24 :) Не когда не слышал о 60.

[caseyryan]

Вот кстати любопытный момент: всё детство мне рассказывали про 24. Чему верить? :D

Поясню. Тут ты от части прав. Средняя частота от 10 до 24 кадров в секунду, но человек может воспринять и больше, при достаточной концентрации внимания. Было научно доказано, что человек не может воспринять более 60 кадров в секунду. Но 60 еще может, при определенных условиях. Поэтому делать больше 60 в приложении вообще нет смысла. Не воспримется глазом при любых условиях

[Dukobpa3]

Я думаю тут из-за частоты мониторов еще 24 воспринимаются как 10-18.
Синхронизация монитора идет вразнобой с синхронизацией по кадрам и получаем слайдшоу.
60 фпс + частота развертки 60 если хоть через один кадр будут совпадать - уже 30, а это лучше чем 15.

[KumoKairo]

На самом деле если сравнить частоту смены кадров 24 fps и 35 fps, то глаз почувствует разницу. Просто давным давно фильмы принятно снимать с частотой 24 fps, так как это своеобразный "порог", ниже которого анимация воспринимается рывками. То есть тут от противного идут - это не верхний порог, а нижний. Пленку же надо было как-то экономить.

Там еще принцип проектирования немного другой был - пленка моталась с одной бабины на другую, а для обеспечения дискретности кадров (если не закрывать момент смены кадров - будет видно как пленка перематывается) использовали диски с отверстиями. Во время вращения диск непрозрачной частью закрывал поток света проектора, создавая эффект мерцания.

[alexcon314]

Ну, а в довесок, припомню что кто-то где-то когда-то говорил, что фреймрейт по православному надо делать нечетным :) и 31 - цифра кошерная :) Чего-то там с математикой было завязано.. не могу найти тред, а самому уж и не сообразить.

[Dukobpa3]

Мы вон вообще 15-18 фпс анимашки анимируем и ок :D (но глобально всё приложение 45-60 фпс)

[mooncar]

Я думаю тут из-за частоты мониторов еще 24 воспринимаются как 10-18.
Синхронизация монитора идет вразнобой с синхронизацией по кадрам и получаем слайдшоу.
60 фпс + частота развертки 60 если хоть через один кадр будут совпадать - уже 30, а это лучше чем 15.
Похоже на правду, по крайней мере логика есть.