UpdateScene and RenderScene
Иго-гоооо
Сектор номер 2. Вопрос прислал пользователь из Пензы по имени imena. Вопрос: Пытаюсь смастерить каркас для игры... для несуществующей игры. Решил сделать две главные функции - UpdateScene(deltaTime) и RenderScene() В UpdateScene(deltaTime) выполняю все операции связанные с вычислением нового положения объекта(ов), текущий кадр в анимация(1) - анимация(N) и т.д. и т.п. В RenderScene() - выполняю прорисовку всей сцены с учетом тех данных что были получены в UpdateScene() Пихнул все это хозяйство в ENTER_FRAME. А теперь, уважаемые знатоки, внимание вопрос: 1) правильно пихнул(обе функции) или 2) может одну из них пихнуть в EXIT_FRAME? Или может еще куда? Всем заранее спасибо |
Правильно пихнул [x]
Можно одну из них пихнуть в Event.RENDER. Cчет 1:0 в пользу знатоков! |
Добавочный ответ в пользу знатоков.
В место "Event.ENTER_FRAME" советую использовать "TimerEvent.TIMER" с "updateAfterEvent();". Код AS3:
|
Кстати, можно поподробнее - почему рендер сцены лучше вешать на таймер, чем на события кадра?
|
Возможностей больше и производительность выше.
|
Мне тоже интересно. Я не волшебник, я только учусь... и как я понимаю, если мы поставим таймер на 1 секунду, то наш прощет сцены будет ТОЛЬКО раз в секунду?
В общем...вот как у меня было сделано(до того как я создал эту тему) Код AS3:
|
Код AS3:
|
Спасибо.
Я в начале сделал по примеру Мука диспетчер.... сделал интерфейс... но... чет запутался во всех этих ограничениях с объвлением переменных, с доступом... и в конце-концов плюнул... оказЦа зря плюнул Добавлено через 1 час 51 минуту Я тут поэкспериментировал с анимацией... В общем при использование Таймера анимация более 'рваная', не не равномерная, а именно 'рваная', НЕ ВСЕГДА, но все же слишком часто, а при использовании различных значений frameRate и скорости самой анимации ... анимация плавнее или если и скачками, то... мммм.. равномерными скачками Вот кусок кода который разместил в enterFrameListener(frameRate = 30) и в timerListener(таймер на 40 миллисекунд): Код AS3:
Код AS3:
При использовании таймера, событие происходит не точно через каждые 40 миллисекунд... я трейсом вывел значения... там встречаются и 40 миллисекунд и 69 миллисекунд... с учетом кода производим расчеты... когда у нас 40 миллисекунд... все ок... т.к. 0.04*_fps(самой анимации = 30) = 1.2.. т.е. приращение идет на 1 кадр... и все хорошо, НО, когда deltaTime = 66 миллисекундам, тогда 0.069*30 = 2.07, т.е. приращение идет уже на два кадра, а в какой-то момент даже встретилось значение в 6 кадров. При использовании ENTER_FRAME среднее deltaTime = 0.35.. в результате очередных расчетов... получаем 0.033*30 = 0.99, т.е., приращение идет все время на один кадр. В общем... к чему это я все... сижу тут и думаю, какой вариант все же предпочтительнее? И почему у меня с вариантом таймера получается такая фигня? Попробую сейчас сделать 20 анимаций одновременно...и гляну на результаты |
Что то я запутался в ваших цифрах. Сейчас накидаю пример.
|
вечером гляну... а то уже глаза закрываются
|
Только не через таймер. Я предупредил.
З.Ы. Секунда будит [x] |
Цитата:
|
Насколько я понимаю, таймер с updateAfterEvent() заставляет плеер отрисовывать содержимое не только во время, когда начинается кадр, но и в то время, когда срабатывает таймер. Каким образом это может увеличить производительность?
Я еще понимаю, если у нас в приложении нет обычной анимации, а только програмная - ок, ставим фреймрейт в значение "1" и таймер даст нам больше производительности за счет отсутствия всякого функционала кадра типа фаз, вещания разных событий и т.д. То, что возможностей больше - это конечно да, удобненько. Но чтобы заявлять, что рендер нужно вешать исключительно на таймер - нужно привести побольше аргументов. |
Цитата:
|
Да, согласен, сначала код, потом рендер. Ошибся.
|
Цитата:
|
Цитата:
|
Возможно я поспешил с выводами о ENTER_FRAME && TIMER т.к. получилось высказать сугубо личное мнение но и мнение сложилось с огромной пачки советов во время познания тонкостей оптимизации.
В первую очередь "в своё оправдание =)" хочу предложить прочитать главу "Программная анимация" ст.677 из книги К.Мука "AS3 Подробное руководство". Там как раз замечательно описывается в каких случаях и какой метод использовать. Я не отрицал ENTER_FRAME, вероятно я привел пример на TIMER т.к. сам пользуюсь только им. В общем я не использую в своих приложениях ENTER_FRAME, никогда. Все приложения которые я написал работают только на ОДНОМ TIMER-е, для многих думаю это удивительно но факт. Вопрос как можно одновременно использовать кучу анимационных объектов затронув всего один TIMER? Вот тут на помощь приходит знания оптимизации. Которые можно черпнуть из таких книг как "Совершенный код", "300 рецептов AS3", "Оптимизация - советы профессионалов AS3". Своими словами я тут до седины буду расписывать как, что и зачем, по этому порекомендовал книги. Но на своём опыте я убедился в том что на любое приложение достаточно в основном классе зарегистрировать все один раз таких слушателей как: Код AS3:
|
С каких это пор таймер для анимации стал лучше, чем ENTER_FRAME, который, к тому же, "всегда есть уже" хочешь ты того или нет?
|
Интересно, аргументы в пользу ENTER_FRAME(А)? На самом деле, стало интересно, как организуют анимации за счёт ENTER_FRAME(А), чем выигрывает такой подход?
|
Скажите(я пока все еще на перепутье)... я так понимаю, установив timer delay в 40 миллисекунд... мы получаем те же 24 кадра в секунду.. тогда, в чем разница? Я еще не понимаю всех тонкостей.... Просто, я уже приводил тут пример(возможно код написан криво)... но мой Timer(40) не срабатывает строго каждые 40 миллисекунд.. и об этом написано у Мука... , ENTER_FRAME при фпс = 24.... тоже не срабатывает строго каждые 1000/24 = 41.6(6) миллисекунд.... НО, я вставил trace deltaTime в timerListener и enterFrameListener, и получилось что отклонения от среднего при использовании Timer больше чем при ENTER_FRAME, т.е., один раз 44 миллисекунды, другой раз 66 миллисекунд.. , а у ENTER_FRAME ...все значения примерно от 33 до 50 миллисекунд... и поэтому у меня анимация получается дерганная при использовании Timer.
Да, согласен, может я просто неправильный код для случая с Таймером использую... в общем... приведу еще раз... Код AS3:
|
Сколько себя помню все, что нужно было отобразить на экране, делал по ENTER_FRAME.
|
А мне вот уже третюю страницу интересно услышать аргументы в пользу Таймера.
У Мука, конечно, описывается анимация по таймеру, но ты, видимо, довольно давно читал, т.к. единственный весомый довод в пользу таймера, который приводит Мук - это независимость от фпс, в том числе - независимость от фпс родительской флешки, в которую загрузили нашу флешку. Я бы побоялся публично давать советы типа Цитата:
|
Цитата:
|
Не совсем понял - при чем здесь интерфейсы?
|
Цитата:
|
Мое сугубо личное заблуждение, что для отрисовки сцены надо использовать ENTER_FRAME, так как при этом происходит автоматическая перерисовка сцены в любом случае. А для расчетов, которое необходимо делать чаще, брать таймер.
Так мы не перегружаем процессор лишними отрисовками, которые глаз все равно не оценит и избегаем ошибок при расчетах, так как таймер обсчитывает все часто. |
Зачем таймер использовать как замену ENTER_FRAME?
Ведь есть же ENTER_FRAME. После ENTER_FRAME вызывается отрисовка, вызывается всегда (возможно, ничего не делает, но вызывается) сама по себе, не надо вызывать уродский updateAfterEvent() (если вдруг у вас что-то меняется между таймерами - можете получить фпс/2). У меня всё на ENTER_FRAME (есть даже таймеры свои). Таймеры появились, т.к. выяснилось, что в играх время должно быть централизовано. Потому что в играх есть паузы. У таймеров пауз нет. И пауз к тому же не одна разновидность и есть их иерархия %), например есть пауза "рекламка показывается", есть пауза "юзер нажал ескейп и выехала менюха", есть пауза "юзер открыл меню здания на уровне" (при том в 3-й паузе может вызваться 2-я, а в ней 1-я). И это, 24 фпс достаточно для фильма, который снят с реального мира на камеру. При этом у движущихся в камере обьектов автоматически получается размазывание (как и у человеческого глаза) - потому смотрится нормально. В играх же при 24 фпс одна чёткая картинка резко меняется на другую чёткую картинку. Потому разница между 24 и 40 фпс в играх на глаз очень видна и не в пользу 24. |
Часовой пояс GMT +4, время: 17:18. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.