Интервал таймера зависит от fps

[i.o.]

Psycho Tiger, не переживай ты так, сейчас найду эту тему..))

[BlooDHounD]

результат getTimer зависит от архитектуры процессора. проверенный факт. когда я работал в TZ, у нас при разработки Desteny возникла проблема, которую мы не могли решить. на getTimer подумали в последнею очередь. оказалось, что на всех машинах он давал разную погрешность. где-то отставал, где-то спешил. точно работал только на Денискином ноуте. в итоге мы написали свой getTimer() с блэкджеком и сопутствующими ингредиентами.

Добавлено через 1 минуту
но погрешности getTimer и класса Timer между собой никак не связанны.

[i.o.]

Может я и ошибаюсь, что getTimer() точнее Date.time. Но в общем там постоянно есть погрешность между ними.
Пост номер 3 из этой темы http://www.flasher.ru/forum/showthread.php?t=133807
Просто автор в самом начале жалуется на постоянную разницу в измерениях, используя Date.time.


Ну или вот такой вариант:

 
stage.addEventListener( MouseEvent.CLICK, _onMClick );
 
 
 
function _onMClick( e:MouseEvent ):void
{
	for( var i:int=0; i<2048; i++ )
	{
		trace( getTimer() );
		trace( (new Date()).time );
		trace();
	}
 
}

А вот результат (там где многоточие - убраны повторяющиеся значения):

668
1274565831593

669
1274565831593

....

669
1274565831609

670
1274565831609

....

671
1274565831609

....

672
1274565831609

....

673
1274565831609

....
....

686
1274565831625

Как видно, Date.time показывает полную чушь (в смысле с большой погрешностью), в то время, как getTimer() примерно через одинаковое количество трэйсов увеличивается на единичку

[BlooDHounD]

Date точнее, так как он зависит от системных часов. а getTimer зависит от процессора.

[i.o.]

BlooDHounD, прокомментируйте пост выше (обновлен).
Если вы правы, то приведите подтверждающий пример.

[BlooDHounD]

лично меня не волнует, то что Date обновляет своё значение не мгновенно. главное, что через 5 минут работы приложения, он отстаёт всего на 5 мс, а не 40 сек. а запрашивать время дважды в одной функции я ни разу даже не додумался =)

для тестов скорости точности getTimer хватает. а для релтайм игры его погрешность на длинных дистанциях меня не устраивает.

[i.o.]

Да, на длинных дистанциях Date лучше, без вопросов.
Правда есть один маловероятный ньюанс: пользователь может перевести время или например переход на летнее и обратно...))

[iNils]

BlooDHounD
1. Как вы поняли, что это getTimer?
2. Какая величина погрешности.
3. Эта погрешность накапливается?

[BlooDHounD]

1. случайно. что-то врало и мы не могли понять что. предположили самое невероятное и написали тест, который показывал разницу Date и getTimer. их дельта не уклонима росла со временем.
2. на всех компах была разная
3. да

с тех пор вместо flash.utils.getTimer для синхронизации используется такой такой неказистый код:

package blooddy.utils {
 
	/**
	 * @author					BlooDHounD
	 * @version					1.0
	 * @playerversion			Flash 10
	 * @langversion				3.0
	 */
	public function getTimer():Number {
		return ( new Date() ).getTime() - startTime;
	}
 
}
 
import flash.utils.getTimer;
 
/**
 * @private
 */
internal const startTime:Number = ( new Date() ).getTime() - flash.utils.getTimer()

[iNils]

Написал свой тест. Результат совсем другой. Погрешность есть, колебалась в диапазоне -7..7 мс без нагрузки и с нагрузкой в 1000000 итераций простого цикла. С 10000000 колебания были -14..0 мс. Накопления не обнаружил.