Флейм
GameDev.ru / Флейм / Форум / Летопись багов (9 стр)

Летопись багов (9 стр)

Страницы: 14 5 6 7 8 9
skalogryzУчастникwww3 мая 201823:54#120
Роман Шувалов
> Я ничему не научился:
это потому что язык неправильный - пиши на Паскале :D
Great V.Постоялецwww13 мая 20182:59#121
Оказывается эта зараза сидела у меня в коде пару лет:
2018-05-13 02_55_46-Great V Engine 2 - Microsoft Visual Studio | Летопись багов
Раскопал, когда попытался посчитать stride вручную, а не "по нормальному".
ArochПостоялецwww13 мая 20184:23#122
Great V.
> Раскопал, когда попытался посчитать stride вручную, а не "по нормальному".
std::array этому человеку!
Great V.Постоялецwww13 мая 201810:52#123
Aroch
Не, ну а что бы это там изменило? У меня там и так vector.
ArochПостоялецwww13 мая 201812:30#124
Great V.
не обращай внимания, кто знает тот поймет :)
skalogryzУчастникwww14 мая 20186:48#125
Рассинхронизация.
Долго не мог понять, каким образом клиентская копия мира по времени убегает вперёд от серверной копии.

После тщательно расписанных логов (логи рулят!)
выяснилось, что игровой тик имеет програмное ограничение - не больше 100 млс.

double GameTick(double deltaMls)
{
   if (deltaMls > MAX_DELTA)  deltaMls = MAX_DELTA;
   ...game..
   return deltaMls;
}
Если он больше, то переданная дельта обрезается до 100 млс, и возвращается 100 млс (чтобы можно было вызвать тик ещё раз, и "догнать" реальное время)

Серверный код на эту особенность забивал (хотя сам тестовый сервер работает насверхмощном Eeepc 701, с Intel Celeron(R) M 900Mhz)
и независимо того, насколько долго код тупил, всегда обрабатывал 100 млс.

А т.к. клиент рисует игру от физического времени, то в итоге происходила рассинхронизация, и клиент уходил далеко вперёд.

Имхо, хороший пример, что нужно разрабатывать и тестировать, на как можно более тормозном и старом железе.

Правка: 14 мая 2018 14:44

Страницы: 14 5 6 7 8 9

/ Форум / Флейм / Программирование

2001—2018 © GameDev.ru — Разработка игр