Комментарии 3
Спасибо за разбор
Стало интересно в чём проблема запаздывания короновского таймера. Сам код таймера есть на Github, как видно это просто обёртка над enterFrame, из этого следует что максимальная частота таймера равна частоте кадров (fps)
По сути вся проблема описанная в статье заключена в неправильном расчёте времени для следующего триггера:
Если заменить строку local fireTime… на:
И опробовать пример с модифицированной версией библиотеки, то оба таймера из примера будут работать одинаково.
P.S. Пулл реквест в репозиторий сделан, надеюсь в следующей версии короны это будет пофикшено и можно будет без проблем использовать долгие таймеры
Стало интересно в чём проблема запаздывания короновского таймера. Сам код таймера есть на Github, как видно это просто обёртка над enterFrame, из этого следует что максимальная частота таймера равна частоте кадров (fps)
По сути вся проблема описанная в статье заключена в неправильном расчёте времени для следующего триггера:
if iterations > 0 then
entry._iterations = iterations - 1
end
local fireTime = currentTime + entry._delay
entry._time = fireTime
Если заменить строку local fireTime… на:
local fireTime = entry._time + entry._delay
И опробовать пример с модифицированной версией библиотеки, то оба таймера из примера будут работать одинаково.
P.S. Пулл реквест в репозиторий сделан, надеюсь в следующей версии короны это будет пофикшено и можно будет без проблем использовать долгие таймеры
Да, спасибо. Пул реквест принят, в завтрашней версии Corona должно уже быть пофикшено. Забавно что в соседнем репозитории уже так.
Замечательно, что разработчики короны заглядывают на хабр:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Corona SDK точный таймер