![]() |
fps - когда и сколько
Хочется спросить у опытных, сколько fps Вы используете и какие есть случаи, на которых Вы выработали
его изменение? А спросил я это вот по чему - всегда считал, что для анимации 30 кадров, это более чем хорошо. Но на форуме попались упоминания о 60 и при чём не от одного и того же форумчанина. А в гугле нашёл, что от 27-37+, в зависимости от самой анимации. Вот я и решил всё разузнать. |
Для мобильных приложений хорошим тоном считается ориентироваться на 60 fps - идеальный случай. На самом деле выбирать особо не приходится - эта планка давно определена (насколько я знаю - это предел частоты обновления LCD экрана с включенной V-Sync)
|
Чем больше кадров, тем плавнее анимация.
Откуда взялось 60 кадров? Просто было выявлено, что средняя частота обновления картинки в человеческом глазе, составляет около 55 - 60 раз в секунду. Больше глаз просто не сможет увидеть, поэтому делать больше нет смысла. Не знаю как на счет хорошего тона, но если приложение тянет 60 кадров в секунду на мобиле, то это явно не плохо. Я обычно ставлю 30 кадров. Вполне достаточно. Не вижу необходимости делать 60. Часто разница даже зрительно будет незаметна. Но какого-то общепринятого стандарта не существует. |
Присоединяюсь. Ставлю 30.
Но если у вас 60, и на onEnterFrame (к примеру ) висит достаточно тяжелый обработчик событий, а экшена, как такового, не присутствует, то вы будете грузить систему на ровном месте ни для чего.... |
Всем Большое Спасибо! Вчера, продолжая эксперименты, немного был удивлён.
Поставил getTimer + Timet и сделал частоту 60fps ( 1000/60 ) и ещё u, pdateAfterEvent в обработчик засунул. Сначала трейсел, а потом начал в текстовое поле выводить и оказалось, что по истечении шести секунд, проходило около ста кадров, десять секунд === 240. Это вообще без всего с одним текстфилдом. При ( 1000/30 ), такая же история. И у меня ещё вопрос - работа твинов, она же на getTimer + Timet построена? |
60 кадров для более-менее нагруженной анимации часто много, начинает лагать, если еще математики много то становится заметно. То же самое на 30 кадров будет ровнее. Так как длина кадра для расчетов больше.
В то же время на 30 кадрах всякие медленные твины типа, плавненького выезжания окошек, становятся заметно пошаговыми и вполне заметными для глаза. Опытнным путем подобрал себе 40-45 фпс, этим и пользуюсь обычно. И анимации более гладкие получаются, и лагает из-за частоты обновления меньше. Это касается стандартного ДЛ. В то же время на старлинге, с небольшим кол-вом объектов удавалось добиться под 100+ фпс :) Цитата:
|
Dukobpa3 Спасибо!
Цитата:
|
В анимациях это вообще не оправдано.
Добавлено через 10 минут Про анимацию построенную на времени тоже писали. Анимацию надо строить на энтерфрейме. Но можно мерять время с предыдущего кадра, чтобы иметь возможность подогнать ее. Например спрайт должен пролететь 100 пкс, за 2 секунды. Допустим у нас 60 кадров в секунду. 16.67мс на отрисовку одного кадра. 20мс на один пиксель. Вот мы и считаем. Стандартная наша скорость будет ~3пкс за 4 кадра. Если с предыдущего кадра прошло больше чем 20мс(вместо 16.67) - значит смело подвигаем на целый пиксель или больше, в зависимости от задержки. Если меньше (что маловероятно) оставляем на том же месте, но сохраняем в буфер "не использованную задержку" чтоб на следующем кадре посчитать всё вместе. Я скидывал свой менеджер анимаций в какой-то из тем. Там это реализовано есть. Но там покадровая анимация, чтоб можно было с нужно скоростью анимации проигрывать. С твинами будет так же. Добавлено через 12 минут а updateAfterEvent - теоретически вызывает отрисовку немедленно, что очевидно, еще более нагружает систему. А нам при отставаниях ее наоборот разгрузить надо. (Могу ошибаться, так как пользовался этой функцией всего один раз). Да и вцелом не вижу смысла в updateAfterEvent. Оно и так и так в следующем кадре отрисуется, такова уж система работы флеша. И если он понадобился скорее всего проблема в другом месте. Но иногда, например при драг-ен-дропах - это необходимо. |
Цитата:
В пример я создал EF с частотой 45 кадров. Когда я решаю сколько кадров выбрать, то руководствуюсь тем, что анимация будет обновляться столько раз, сколько кадров. И вот я вижу, что за десять секунд не хватает 150 кадров и анимация передвижения дергается. Вот почему лучше использовать EF + твины для сглаживания, если можно поставить 1fps, но запустить таймер с частотой обновления 45 раз в секунду, замерять время + его подгонять + updateAfterEvent, который будет вызываться точно 45 раз. Вот почему такой подход не правильный, а создавать много разных твинов ( ведь обьектов много и двигуются они все с разной скорость ), это хорошо? А с таймером я и без лишней нагрузки ( без твинов ) задавать им разную скорость и уверен что лагов не будет, ведь частота обновления будет именно 45 раз. Код AS3:
|
Вместо небольших лагов раз в кадр ты хочешь один большой раз в секунду?
Ок. Добавлено через 1 минуту Научись сначала стандартными методами пользоваться, а потом уже если не хватит - свои велосипеды. Но я думаю когда научишься использовать то что есть - и велосипеды будут иначе выглядеть. |
Dukobpa3 я согласен с Вами. И ещё делая анимацию на время, я естественно заметил, что если запускать её сразу, то происходит скачок, так как время считается с момента запуска плеера. И вот когда я разочаровался в TweenMax, то скачал рекомендуемую Вами изи.
И вот там тоже самое, такой же скачок. Значит они тоже строют её на времени. У макса такой беды нет, у него своя хитрая временная шкала. Вот и получается, что можно подгонять приложение под твины, а можно сделать свою временную шкалу и в большинстве случаев твины не понадобятся. |
Тут какая штука.
Или твины или свой таймлан. Комбинировать надо грамотно. Напрмиер покадровые анимации с заданной скростью я изначально пытался разрулить твинером (изи умеет кадры прокручивать), но есть свои ньюансы, потому пришлось писать свою. Во всех остальных случаях я не заморачиваюсь и использую твины. Ну и я обычно использую разделение следующим образом: Анимации сугубо графики - твины. Анимации по математике - своё. (Т.е. к примеру горизонтальный скроллер у меня был, там мухи летели по некоей траектории. И столкновения считались математикой, а не коллизиями спрайтов. Так вот анимация движения мух - свой велосипед по ентер-фрейму. А всякие махания крылышками и партиклы - твины). |
Цитата:
|
Цитата:
|
Цитата:
|
Я думаю тут из-за частоты мониторов еще 24 воспринимаются как 10-18.
Синхронизация монитора идет вразнобой с синхронизацией по кадрам и получаем слайдшоу. 60 фпс + частота развертки 60 если хоть через один кадр будут совпадать - уже 30, а это лучше чем 15. |
На самом деле если сравнить частоту смены кадров 24 fps и 35 fps, то глаз почувствует разницу. Просто давным давно фильмы принятно снимать с частотой 24 fps, так как это своеобразный "порог", ниже которого анимация воспринимается рывками. То есть тут от противного идут - это не верхний порог, а нижний. Пленку же надо было как-то экономить.
Там еще принцип проектирования немного другой был - пленка моталась с одной бабины на другую, а для обеспечения дискретности кадров (если не закрывать момент смены кадров - будет видно как пленка перематывается) использовали диски с отверстиями. Во время вращения диск непрозрачной частью закрывал поток света проектора, создавая эффект мерцания. |
Ну, а в довесок, припомню что кто-то где-то когда-то говорил, что фреймрейт по православному надо делать нечетным :) и 31 - цифра кошерная :) Чего-то там с математикой было завязано.. не могу найти тред, а самому уж и не сообразить.
|
Мы вон вообще 15-18 фпс анимашки анимируем и ок :D (но глобально всё приложение 45-60 фпс)
|
Цитата:
|
| Часовой пояс GMT +4, время: 22:56. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.