Просмотр полной версии : onEnterFrame а что не так
50%LameRa
16.06.2005, 12:53
Очнь часто виже исходники в которых не используют onEnterFrame там где это очевидно, да и на том форуме был топ что использовать вместо него.
За что его так не любят?
Dimonius
16.06.2005, 12:56
за нагрузку на проц
50%LameRa
16.06.2005, 19:09
так вот оно что, ну спасибо.
за нагрузку на проц
Шутка?!.......
ну, вообще Dimonius прав. неубиенные события onEnterframe по любэ грузят проц. но тут дело конечно не только в этом
Речь идёт про сравнение с setInterval_ом
у которого действительно по стравн. с Инт_фр.
есть ряд преемуществ, главное из которых -
независимость частоты вызова функции от fps....
Re : за нагрузку на проц)))
Ну да конечно особенно на новых моделях процессоров )))
хоть триста флешек нурана запускай , а он зараза даже не греется )))) :D
Dimonius
17.06.2005, 03:25
я сказал в общем виде, все конкретности сведуться к моей фразе. не надо умничать.
а новые процессоры далеко не показатель ца продукта.
Captain Crocus
17.06.2005, 10:57
2Штрек
>>главное из которых - независимость частоты вызова функции от fps
Точнее, непрямая зависимость есть, и не только от fps, но ее в 99% случаев можно не учитывать.
artfla$her
17.06.2005, 19:34
onEnterFrame - очень нужное событие. Если его не любить (в переносном смысле, конечно))))), а юзать только интервалы, то производительность может очень и очень пострадать. А все ненужные, но существующие onEnterFrame-ы -первый признак плохого кода, но никак не плохого события )
netstuff
17.06.2005, 19:51
2 Штрек
Шутка?!.......
не думаю. а что смущает? :confused:
2 D12:
Сжатая_ZIP_Папка рулит, привет, за что у тебя плюсики то опять?
А вообще я люблю onEnterFrame, потому что я тупой и альтернативных путей не знаю!!!
50%LameRa
17.06.2005, 21:01
Так все таки если для задачи все равно, что юзать onenterframe или setinterval?
Так все таки если для задачи все равно, что юзать onenterframe или setinterval?
Если ты помимо onenterframe или setinterval не будешь юзать другой сложной анимации или кода, то всё равно! ;)
netstuff
17.06.2005, 21:12
что пишет хелп:
If interval is less than the SWF file’s frame rate (for example, 10 frames per second [fps] is equal to 100 milliseconds), the interval function is called as close to interval as possible.
----------- (постарайусь перевести с листа ;) )----------------
Если интервал меньше чем ФПС клипа (например, 10ФПС = 100 милисекундам), то функция интервала принимает наиболее близкое значение.
ИМХО, это значит, что onEnterFrame - функция более низкого уровня.
а вот по поводу загрузки проца (а это, согласитесь, основная проблема) - думаецца мне, что интервал потяжелее будет. хотя надо проверять :rolleyes:
а по-хорошему, я не очень понимаю, как эти 2 функции перескаюцца. ведь там, где нам нужно именно событие на каждый фрейм (например, покадровое проигрывание анимации) - логично использовать onEnterFrame. а там, где нам нужен временной интервал > один кадр - логично использовать setInterval (нежели на onEnterFrame расставлять проверки, счетчики и условия всякие) :cool:
artfla$her
18.06.2005, 17:07
Интервал(ы) удобно использовать тогда, когда необходим точный просчет изменений положения объекта. Например, в играх. Представим такую ситуацию - вылетает пуля, и она, врезавшись в тот или иной предмет, должна исчезнуть. Пуля, понятное дело, летит быстро. Как проверять совпадение и двигать пулю? Вариант 1. Юзать onEnterFrame. В этом случае у нас может возникнуть ситуация, когда смещение пули будет превышать хотя бы 10 пикселов - возможна такая фигня - пулька пролетит "насквозь" объекта, чья толщина менее 10 пикселов. Вариант 2. Юзать интервал (очень быстрый интервал, этак 1-10 миллисекунд) и большой fps. Тогда можно просчитывать совпадения каждые 1-10 миллисекунд и двигать пулю не более чем на пиксел-другой. Но в этом случае более чем два-три таких интервала установить будет нелегко, т.к. проц загружается жестко (при оптимизации других вещей, того же выявления совпадений с помощью раздления экрана на локации).
а можно просто в момент пуска пули просчитать, врежется она во что-то или нет. и когда. но такой вариант мало где подойдет, поскольку всю игру нужно будет строить совсем по другим принципам.
50%LameRa
18.06.2005, 22:00
Ну если интервалы от fps не зависят, тогда все понятно.
Всем спасибо.
Ну если интервалы от fps не зависят, тогда все понятно.
Всем спасибо.
Ну не совсе так ;)
Только что провел тест на FLASH MX, 2004 под рукой не было, поэтому не могу сказать как он справится моим тестом (кому не лень, повторите на 2004 и скажите результат).
Итак, берем следующих код:
u = function () {
cx++;
if (cx == 20) {
clearInterval (id);
for (i = 1; i < arrayID.length; i++) {
trace (arrayID[i] - arrayID[i - 1]);
}
}
arrayID[arrayID.length] = getTimer ();
};
cx = 0;
arrayID = new Array ();
id = setInterval (u, 100);
Ставим fps = 5
Результат:138,102,100,102,118,100,100,100,100,100,100,100,100,100,100,100,100,100
в начале завал, но потом все верно
fps=6
108,109,113,112,111,113,112,111,113,112,113,111,111,113,112,111,113,112
погрешность в 11-12%, не очень хорошо
fps=7
109,107,111,112,112,112,112,112,112,112,112,112,111,113,112,111,113,112
тоже самое
а теперь поставте fps 11 или 12
164,172,175,177,176,176,176,176,176,176,176,176,178,174,176,176,176,176
?????
погоди. а у тебя stop() перед эти кодом не стоит? потому что может быть оно зациклилось? и обьявление функции идет каждый раз и поэтому когда увилеичил фпс то кол-во декларирований увеличилос или я чего то путаю
artfla$her
20.06.2005, 15:18
код
var prevtime : Number = getTimer();
_root.onEnterFrame = function()
{
trace(getTimer() - prevtime);
prevtime = getTimer();
};
тоже не всегда выдает стабильный результат. Правда, тут погрешность не такая, но наводит на размышления (например, фпс = 15, трейс =
47, 68, 70, 66, 66, 66, 72, 67, 71, 66)
код пришлось чуть чуть подправить для AS2
cx=0
u = function () {
_root.cx++;
if (_root.cx == 20) {
clearInterval (id);
for (i = 1; i < arrayID.length; i++) {
trace (arrayID[i] - arrayID[i - 1]);
}
}
arrayID[arrayID.length] = getTimer ();
};
arrayID = new Array ();
id = setInterval (u, 100);
результаты и правда чет рознятся
На 20 фпсах
105,100,101,106,104,104,101,104,101,104,101,104,101,104,100,101,104,101
на 5 фпс
101,120,120,119,101,120,120,119,101,120,120,119,100,100,101,120,119,101
На 11 фпс
180,180,180,180,180,180,180,180,180,181,188,180,180,180,180,180,180,180
Заметил что самые точные интервалы при фпс кратные 60. Помойму этот баг обсуждался в флешрипере, связанно с округлением.
Статья называлась Волшебная частота (http://flash-ripper.com/archives/2004_12.htm).
Но там говорилась, что ошибка накапливается, а не каждый раз возникает. Все таки разница почти в 2 раза (180, а не 100) это много.
И кроме того, это показывает, что есть зависимость setInterval от fps.
И кроме того, это показывает, что есть зависимость setInterval от fps.
Кому надо супер точность, может ввсести поправочный коэффициент, который определяем методом тыка......
И кроме того, это показывает, что есть зависимость setInterval от fps.
и главное зависимость не пропорцианальна от кол-ва фпс. кривенькая функция получилась=(
кстате при интервалах около секунды погрешность не такая уж и большая примерно около 5-20 процентов.
А погрешность на фпс (к примеру 10, 5, ) и интервалом в секунду вообще отсутствует!!!
Атомные часы не получится сделаеть=)
Ка отсутствует? У меня при fps 5, 10, 12 и интервалов 1000мс, выдавалось 1040-1060.
Captain Crocus
20.06.2005, 16:09
Зависимость есть не прямая.
Колин Мук. ActionScript for Flash MX: The Definitive Guide, 2nd Edition
When an interval is set to run less often than the duration of a tick of the frame rate, it will execute on the frame after the interval time has expired. For example, given an interval set to 400 ms and a frame rate of 10 fps (1 frame per 100 ms), Table 18-16 shows the frames on which the interval should execute.
Frame number | Total time (milliseconds) | Interval executed?
000 | 0 | no
001 | 100 | no
002 | 200 | no
003 | 300 | no
004 | 400 | yes
005 | 500 | no
006 | 600 | no
007 | 700 | no
008 | 800 | yes
009 | 900 | no
010 | 1000 | no
However, whether an interval runs more or less often than the frame rate of a movie, interval times are by no means guaranteed. In an actual test movie, the intervals in Table 18-16 may execute at frames 5 and 9, or even at frames 4 and 9. Code execution, Player rendering, and available system resources can all affect the actual timing of intervals. Where time is an important factor in an application (for example, in a game), functions should be written to account for variance in interval times.
Русского издания под рукой не было
Перевод (у меня был под рукой):
Если интервал задан так, что промежуток между его выполнениями больше, чем промежуток между тактами частоты смены кадров, то он будет выполняться в том кадре, который появится по истечении времени интервала. Так, если задан интервал длительностью 400 мс и частота смены кадров состовляет 10 с-1 (1 кадр каждые 100 мс), то таблице можно узнать, в каких кадрах будет выполняться интервал.
кадр|мс| выполнен интервал?
000 | 0 | no
001 | 100 | no
002 | 200 | no
003 | 300 | no
004 | 400 | yes
005 | 500 | no
006 | 600 | no
007 | 700 | no
008 | 800 | yes
009 | 900 | no
010 | 1000 | no
Но ка бы не выполнялся интервал по сравнению со сменой кадров фильма - чаще или реже, временные промежутки интервала не могут быть гарантированы...
Но это не отвечает на вопрос почему при fps 12-13 такие большие искажения.
а не мог бы скинуть эту книгу на gaploid@yandex.ru
она большая?
Captain Crocus
20.06.2005, 16:35
2iNils
Спасибо, я именно об этом говорил раньше, на первой странице, http://www.flasher.ru/forum/showthread.php?t=65663&page=1&pp=10
Далее Мук пишет, что указанная таблица не является постоянной, все зависит от след. факторов: от конкретного кода, от конкретного плеера и системных ресурсов (я думаю, что контекст такой у этого Code execution, Player rendering, and available system resources), так что, Штрек, "методом вТыка" не выйдет.
а не мог бы скинуть эту книгу на gaploid@yandex.ru
она большая?
Вот так вот заниматься цитированием.... :p
В конечном итоге я протестировал на трех машинах (P3-700, Celeron-2800, P4-2800) и плееры 6-7. Везде одно и тоже.
Captain Crocus
20.06.2005, 17:04
2gaploid
Перечти правила. Извини. Разговор о книгах теперь приравнивается к софту.
Nirth: и кстати личные сообщения, мыло и прочее не попадают под правила, так что дерзай ;)
Captain Crocus
20.06.2005, 17:06
2iNils
>> В конечном итоге я протестировал на трех машинах
>> (P3-700, Celeron-2800, P4-2800) и плееры 6-7. Везде одно и тоже.
А вот это уже интереснее. Что одно и то же?
А вот это уже интереснее. Что одно и то же?
При fps 12-13, вызов происходит примерно через 180 мс.
Captain Crocus
20.06.2005, 17:21
2iNils
AMD-2500 (1.84GHz) при том же fps средний результат 176.
2Nirth
Ничто не скроется от тебя, о вездесущий ;)
ну 176 из той же степи. а почему так много?
Captain Crocus
20.06.2005, 17:41
для 13-ти
155 154 154 154 154 154 153 155 154 153 155 154 154 154 154 154 153 155
для 12-ти
173 177 176 176 171 173 175 177 176 176 175 177 176 176 175 176 177 176
а еще выбивало на 184. так что твои совпадения очень странные на трех машинах.
ну я же не с точностью до 1 считаю. одно дело когда диапазон 100-130, а другое когда 160-180.
50%LameRa
21.06.2005, 15:52
Ну вот, три дня назад ушел в полной уверенности что все понял, а теперь и понял что я до этого ничего не понял :).
Итак, что мы имеем на данный момент:
1. onEnterFrame нагружает процессор и результат его работы находится в прямой зависимости от fps(а его погрешность при fps=15 мне вообще не понятна :confused: ).
2. Интервалы юзаем когда просчитать что либо надо очень быстро, по крайней мере быстрее чем это что-то отобразиться(та же пуля).
В этом случае(если я правельно понял) результат работы интервалов от fps не зависит, фунция просто вызывается чаще чем меняются кадры.
3. Если частота вызова интервалов больше чем частота смены кадров, то по Муку интервальная функция будет вызвана в том кадре "который появится по истечении времени интервала" это собственно и обястняет погрешности интервалов. Например при fps 11 и интервалом 100 когда трейситься вот это
180,180,180,180,180,180,180,180,180,181,188,180,18 0,180,180,180,180,180
кадры меняются каждые 90,9090...мс а функция вызывается каждые 100мс и выполняется, к сожалению, не при наиболее близком значении а 90,9090..(второй кадр) а в следующем т.е. через 2*90,9090...=180 что мы и видим то же происходит и с последующими кадрами.
Т.е. результат работы при интервалах больших чем частота смены кадров зависит от fps.
Поправьте, если в чем ошибся.
Captain Crocus
21.06.2005, 16:08
2 50%LameRa
Запусти еще загрузку, например Фотошопа, и посмотри какими рванными станут интервалы при всех fps. От процессора еще, от процессора, от загрузки его.
2:50%LameRa
Судя по твоей логике в пункте 3, получается что при фпс=1 (1000мс между фреймами), сет интервал с значением 100, должен вызываться только при входе во второй кадр, то есть через 1000мс.
Captain Crocus
21.06.2005, 17:27
2iNils
50%LameRa писал "результат работы при интервалах БОЛЬШИХ чем частота смены кадров", а не меньше.
Может хватит, парится? Не только фпс влияет, это раз, и синхронизация происходит при установлении головки воспроизведения на кадр, даже если должен сработать сетИнтервал, но ты уже на кадре, пусть только войдя, будешь ждать следующего кадра. Тоже самое в Библии описано, почти как у Мука.
2Captain Crocus : С какой стати флеш когда частота вызова интервалов больше чем частота смены кадров, будет ждать когда наступит следующий кадр, а в обратном случае не будет?
Captain Crocus
21.06.2005, 18:41
да, я тоже чего-то перемудрил
Captain Crocus
22.06.2005, 10:43
2iNils
Опять разночтение получилось, говорили "результате работы при ИНТЕРВАЛАХ БОЛЬШИХ чем частота смены кадров", а ты говоришь о "ЧАСТОТЕ вызова интервалов БОЛЬШЕ, чем частота смены кадров".
В любом случае происходит подсчет кратности: сколько фреймов укладывается в один интервал и сколько интервалов укладывается в один фрейм, при первом случае и втором соответственно. И точно посчитать все это невозможно. Потому как частота смены фреймов также величина непостоянная, зависящая от многих факторов.
Если бы был известен механизм синхронизации между фреймрейтом и сетИнтервалом, то, наверное, можно было бы хитро все подладить. Хотя это тоже не факт, т.к. функции заложенные в сетИнтервал являются кодом, а исполнение кода влияет на фреймрейт, а фреймрейт в свою очередь влияет на сетИнтервал.
ты хочешь этим сказать, что все это чистой воды шаманство? :d
Captain Crocus
22.06.2005, 11:51
пока закрыта реализация плеера, то да. мы же не можем предположить приоритеты выполнения процессов. или давай запасемся банками кофе, блоками сигарет и... будем проводить эксперементы. ;)
я не курю и кофе не пью :)
Captain Crocus
22.06.2005, 13:31
счастливчик. я вот тоже, сейчас докурю и брошу.
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.