Во-первых, позвольте мне сказать следующее: это невозможно сделать только с NSTimer, для этого нет встроенной функции (вы можете построить логику вокруг этого, как предлагает ответ от Vadian). НО.
Почему NSTimer — плохая идея
Давайте остановимся и немного подумаем. Для игровых объектов и точного нереста вы никогда не должны использовать NSTimer
в первую очередь. Проблема заключается в реализации NSTimer
(цитируя документы):
Из-за различных источников входных данных, которыми управляет типичный цикл выполнения, эффективное разрешение временного интервала для таймера ограничено порядка 50-100 миллисекунд. Если время срабатывания таймера происходит во время длинного вызова или когда цикл выполнения находится в режиме, который не отслеживает таймер, таймер не срабатывает до тех пор, пока цикл выполнения не проверит таймер в следующий раз. Следовательно, фактическое время потенциального срабатывания таймера может быть значительным периодом времени после запланированного времени срабатывания.
Есть и другие проблемы с NSTimer, но это выходит за рамки этого вопроса.
Решение
Что вы можете сделать вместо этого, вы должны слушать изменение времени дельты при каждом вызове обновления.
let delta = currentPreciseTime - previousPreciseTime
Теперь, когда у вас есть эта дельта, вы можете иметь counter : Double
, и при каждом обновлении вы увеличиваете счетчик на дельту.
let counter : Double
counter += delta
Теперь, когда ваш «таймер» работает правильно, вы можете проверить с помощью простого условия, прошел ли ваш период времени, или сделать с ним все, что хотите:
let SPAWN_OBJECT_AFTER : Double = 5.0
if counter > SPAWN_OBJECT_AFTER {
// Do something on fire event
self.spawn()
// This line effectively restarts timer
counter -= SPAWN_OBJECT_AFTER
}
Вы можете легко создать свой собственный, очень простой класс таймера, чтобы сделать это. Также! Таким образом, вы можете контролировать то, что происходит в вашем вызове обновления, которому принадлежит логика обновления. Таймер ломает эту модель, разрешая выполнение метода за его пределами — это может быть задумано, но обычно это не так).
Я создавал игры, работающие каждый день, и я бы сказал, что это наиболее распространенное решение для периодических событий, поскольку оно экономит больше всего ресурсов при правильном использовании. Очевидно, что подходит не для всего, но определенно соответствует вашим потребностям.
Надеюсь, поможет!
person
Jiri Trecak
schedule
11.08.2015