Эксперименты с Fps
 

Вторую неделю во флеше -- каждый день новое открытие. Решил замерить FPS при програмном рисовании. Получил странный результат. Мерил следующим образом. В начале кадра замеряю время старта через getTimer, и в конце соотв тоже самое. отнимаю, 1000 делю на результат. Получаю, что на глаз явно не такая цифра должна быть...
Схема стандартная -- первый кадр инитит переменные, во втором код, в третьем gotoAndPlay(2). Поместил gotoAndPlay(2) во второй же кадр, фиг с ним с рисованим. Выяснилось, что отыграв второй кадр за, скажем, 38 миллисекунд, он не запускается снова еще 40-60 мс. Если копировать весь код в третий кадр, и оттуда gotoAndPlay(2), то третий запускается через одну мс, а второй снова только через 50 мс. Мде...

вот кусок лога:
...
tStart 4199 - tStop 4227 = 28
tStart 4281 - tStop 4309 = 28
tStart 4310 - tStop 4338 = 28
tStart 4422 - tStop 4450 = 28
tStart 4451 - tStop 4479 = 28
tStart 4526 - tStop 4555 = 29
tStart 4555 - tStop 4583 = 28
...



Простите за сумбурность. Просто поделился наблюдениями. Если кто знает, как бороться с потеряным временем, поделитесь, плс.

поправочка
 

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

Фреймовый код исполняется перед показом кадра. Затем идёт временная задержка, соответствующая выставленному фреймрейту.

Если в коде встречается переход на другой кадр, то сразу после исполнения текущего кода происходит переход, исполняется код в новом кадре, и только после этого показывается графика и происходит задержка по фреймрейту.

В реальности, правда, всё ещё немного сложнее...

Ничче не понимаю
 

А как в реальности? И почему он дает задержки в зависимости от исполненого кода? и при выставленом FPS=120 у меня код исполнялся за 100мс и такую же задерку я ловил. Дурь какая-то. Он же не по два раза все фигачит? Сам объем кода мизерный -- цикл на полторы сотни кривых рандомом.

Отрисовка векторов задачка медленная по определению.
Отрисовка кривой еще более медленная задачка.
Определение пересечения кривых (для того чтобы отрисовать антиалиасинг) сильно медленная задачка. Задачки просто насыщены матрицами, преобразованиями, выдумками разных умных дядьков. Решаем эти задачки 150! раз (здесь !знак факториал) потому как ставятся они последовательно.

Вот тебе и мизерный "цикл на полторы сотни кривых рандомом".

хехехе
 

Да не. Время исполнения кода я замеряю и получаю результат. Но переход между кадрами занимает какое-то время, пропорциональное времени исполнения кода (у меня код ~100ms; переход ~60ms), при этом переход с последнего снова на начало занимает символическую одну миллисекунду.

Фиг с ним. Дальше больше.

Косинус какого угла равен нулю? А вот и нет. Нет таких углов в нашей канцелярии. Лог:



0 1
1 0.999847695156391
2 0.999390827019096
3 0.998629534754574

58 0.529919264233205
59 0.515038074910054
60 0.5
61 0.484809620246337
62 0.469471562785891
63 0.453990499739547

89 0.0174524064372836
90 6.12303176911189e-17
91 -0.0174524064372835
92 -0.034899496702501

118 -0.469471562785891
119 -0.484809620246337
120 -0.5
121 -0.515038074910054
122 -0.529919264233205
123 -0.544639035015027

178 -0.999390827019096
179 -0.999847695156391
180 -1
181 -0.999847695156391
182 -0.999390827019096
183 -0.998629534754574

238 -0.529919264233205
239 -0.515038074910055
240 -0.5
241 -0.484809620246337
242 -0.469471562785891
243 -0.453990499739547

268 -0.0348994967025008
269 -0.0174524064372835
270 -1.83690953073357e-16
271 0.0174524064372831

298 0.46947156278589
299 0.484809620246337
300 0.5
301 0.515038074910054
302 0.529919264233205

357 0.998629534754574
358 0.999390827019096
359 0.999847695156391
360 1



т.е. cos 90 и 270 градусов некоторая мистическая величина, лежащая в грани, тоньше человеческого волоса.

Или я опять не в теме?

патамучто число PI не равно 3.14159265358979
то что ты видишь погрешность от его округления до этой величины.