onEnterFrame а что не так
 

Очнь часто виже исходники в которых не используют onEnterFrame там где это очевидно, да и на том форуме был топ что использовать вместо него.
За что его так не любят?

за нагрузку на проц

так вот оно что, ну спасибо.

Шутка?!.......

ну, вообще Dimonius прав. неубиенные события onEnterframe по любэ грузят проц. но тут дело конечно не только в этом

Речь идёт про сравнение с setInterval_ом
у которого действительно по стравн. с Инт_фр.
есть ряд преемуществ, главное из которых -
независимость частоты вызова функции от fps....

Re : за нагрузку на проц)))


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

я сказал в общем виде, все конкретности сведуться к моей фразе. не надо умничать.

а новые процессоры далеко не показатель ца продукта.

2Штрек
>>главное из которых - независимость частоты вызова функции от fps

Точнее, непрямая зависимость есть, и не только от fps, но ее в 99% случаев можно не учитывать.

onEnterFrame - очень нужное событие. Если его не любить (в переносном смысле, конечно))))), а юзать только интервалы, то производительность может очень и очень пострадать. А все ненужные, но существующие onEnterFrame-ы -первый признак плохого кода, но никак не плохого события )

согласен полностью

2 Штрек
не думаю. а что смущает? :confused:

2 D12:
Сжатая_ZIP_Папка рулит, привет, за что у тебя плюсики то опять?

А вообще я люблю onEnterFrame, потому что я тупой и альтернативных путей не знаю!!!

Так все таки если для задачи все равно, что юзать onenterframe или setinterval?

Если ты помимо onenterframe или setinterval не будешь юзать другой сложной анимации или кода, то всё равно! ;)

что пишет хелп:
ИМХО, это значит, что onEnterFrame - функция более низкого уровня.
а вот по поводу загрузки проца (а это, согласитесь, основная проблема) - думаецца мне, что интервал потяжелее будет. хотя надо проверять :rolleyes:

а по-хорошему, я не очень понимаю, как эти 2 функции перескаюцца. ведь там, где нам нужно именно событие на каждый фрейм (например, покадровое проигрывание анимации) - логично использовать onEnterFrame. а там, где нам нужен временной интервал > один кадр - логично использовать setInterval (нежели на onEnterFrame расставлять проверки, счетчики и условия всякие) :cool:

Интервал(ы) удобно использовать тогда, когда необходим точный просчет изменений положения объекта. Например, в играх. Представим такую ситуацию - вылетает пуля, и она, врезавшись в тот или иной предмет, должна исчезнуть. Пуля, понятное дело, летит быстро. Как проверять совпадение и двигать пулю? Вариант 1. Юзать onEnterFrame. В этом случае у нас может возникнуть ситуация, когда смещение пули будет превышать хотя бы 10 пикселов - возможна такая фигня - пулька пролетит "насквозь" объекта, чья толщина менее 10 пикселов. Вариант 2. Юзать интервал (очень быстрый интервал, этак 1-10 миллисекунд) и большой fps. Тогда можно просчитывать совпадения каждые 1-10 миллисекунд и двигать пулю не более чем на пиксел-другой. Но в этом случае более чем два-три таких интервала установить будет нелегко, т.к. проц загружается жестко (при оптимизации других вещей, того же выявления совпадений с помощью раздления экрана на локации).

а можно просто в момент пуска пули просчитать, врежется она во что-то или нет. и когда. но такой вариант мало где подойдет, поскольку всю игру нужно будет строить совсем по другим принципам.

Ну если интервалы от fps не зависят, тогда все понятно.
Всем спасибо.

Ну не совсе так ;)
Только что провел тест на FLASH MX, 2004 под рукой не было, поэтому не могу сказать как он справится моим тестом (кому не лень, повторите на 2004 и скажите результат).

Итак, берем следующих код:
Ставим 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() перед эти кодом не стоит? потому что может быть оно зациклилось? и обьявление функции идет каждый раз и поэтому когда увилеичил фпс то кол-во декларирований увеличилос или я чего то путаю

код

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. Помойму этот баг обсуждался в флешрипере, связанно с округлением.

Статья называлась Волшебная частота.

Но там говорилась, что ошибка накапливается, а не каждый раз возникает. Все таки разница почти в 2 раза (180, а не 100) это много.

И кроме того, это показывает, что есть зависимость setInterval от fps.

Кому надо супер точность, может ввсести поправочный коэффициент, который определяем методом тыка......

и главное зависимость не пропорцианальна от кол-ва фпс. кривенькая функция получилась=(

кстате при интервалах около секунды погрешность не такая уж и большая примерно около 5-20 процентов.

А погрешность на фпс (к примеру 10, 5, ) и интервалом в секунду вообще отсутствует!!!

Атомные часы не получится сделаеть=)

Ка отсутствует? У меня при fps 5, 10, 12 и интервалов 1000мс, выдавалось 1040-1060.

Зависимость есть не прямая.

Колин Мук. 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
она большая?

2iNils

Спасибо, я именно об этом говорил раньше, на первой странице, http://www.flasher.ru/forum/showthre...3&page=1&pp=10

Далее Мук пишет, что указанная таблица не является постоянной, все зависит от след. факторов: от конкретного кода, от конкретного плеера и системных ресурсов (я думаю, что контекст такой у этого Code execution, Player rendering, and available system resources), так что, Штрек, "методом вТыка" не выйдет.

Вот так вот заниматься цитированием.... :p

в мой рюкзак влезает :)

В конечном итоге я протестировал на трех машинах (P3-700, Celeron-2800, P4-2800) и плееры 6-7. Везде одно и тоже.

2gaploid

Перечти правила. Извини. Разговор о книгах теперь приравнивается к софту.

Nirth: и кстати личные сообщения, мыло и прочее не попадают под правила, так что дерзай ;)

2iNils
>> В конечном итоге я протестировал на трех машинах
>> (P3-700, Celeron-2800, P4-2800) и плееры 6-7. Везде одно и тоже.

А вот это уже интереснее. Что одно и то же?

При fps 12-13, вызов происходит примерно через 180 мс.

2iNils
AMD-2500 (1.84GHz) при том же fps средний результат 176.

2Nirth
Ничто не скроется от тебя, о вездесущий ;)

ну 176 из той же степи. а почему так много?

для 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. так что твои совпадения очень странные на трех машинах.