округление тут никак не влияет, разница не накапливается. бывает отставание и на минуту

Т.е. вперед они не убегают, да?

иногда и вперед уходят, но реже

faraday,
Не надо считать время таймером! Так конечно, гарантированно будет расхождение. Изучите листинг приведённого мною класса. Там вообще нет никакого таймера.

Tails, вариант когда считается в гетере я пробовал тоже. таймер тут служит только для создания события, собственно по этому событию время и сверяется с сервером. так что на момент срабатывания оно равно тому которое в вашем примере.
Все обращения к гетеру в игре, происходят только по событию TICK, так что проблема не в этом

Вообще не надо считать текущее время и сохранять его в переменную. Считайте текущее время от фиксированной отметки тогда, когда это нужно. Тут как минимум, не учитываются пикосекунды. Ещё расходы на саму операцию сложения и сохранения накладываются и увеличиваются с каждым тиком.

я пробовал вариант без сохранения с гетером getTime()+timeDiff, результат тот же. А почему расход увеличивается с каждм тиком, если каждый тик оно так же отсчитывает от getTimer(), и разве точность времени не ограничена тут миллисекундами, почему пико?
Вы пробовали сверять время клиента с сервером, раз в несоклько минут и сохранять результат при дельте? я тоже долгое время не подозревал о существовании проблемы, и у меня всегда все работало и работает норм.

Есть такая грабля - Когда производишь цикличные вычисление используя в каждом шаге результат предыдущего вычисления - точность неизбежно падает, из-за не идеальности эвм. Это не только в часах, ещё например, с ротацией дисплей объектов бывает такая проблема.

Используйте мой пример. В нём рассинхронизация если и будет, то только из-за реально не корректной работы getTimer(), ну или если клиент находится в гравитационной яме. (Теорию относительности никто не отменял)

Хм, так а где у меня использование предыдущего результата? берется дельта высчитанная при инициализации, и новое значение getTimer. Я в свое время остановился на том, что проблемма все таки в не идеальности Эвм, в коментах тут разъясняется http://www.flasher.ru/forum/blog.php?b=368

Да, не используешь. Мудрёный у тебя код конечно. Из-за реализации через таймер, в любом случае падает точность часов до частоты срабатывания таймера. А срабатывание таймера может снижаться при переходе приложения в неактивное состояние. Это нужно учесть.

Но сам код выглядит рабочим. Если погрешность постоянно растёт без синхронизации, то, скорее всего, бажит getTimer. Вроде wvxvw ещё говорил, что getTimer в некоторых ос может вернуть и того - отрицательное значение! (При определённых обстоятельствах.)