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+ фпс

Сообщение от Akopalipsis

по истечении шести секунд проходило около ста кадров

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 минуту
Научись сначала стандартными методами пользоваться, а потом уже если не хватит - свои велосипеды.
Но я думаю когда научишься использовать то что есть - и велосипеды будут иначе выглядеть.