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

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

Страницы: 15 6 7 8 9 10 Следующая »
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

Ghost2Постоялецwww28 июня 201816:25#126
Вот такое вот вычисление размера буфера для сигнала:
/**  Get buffer size for given time delta.
 * \param dtime Time delta, us
 * \returns Buffer size in bytes
 */
s64 GetBytesAdvance(s64 dtime) const
{
  s32 bps = GetBytesPerSample();
  return (dtime * rate * bps) / 1000000ll;
}
Искал где-то сутки :)

PS. rate - частота в герцах

Правка: 28 июня 2018 16:28

9К720Участникwww28 июня 201817:05#127
Ghost2
> Искал где-то сутки :)
Если бы сразу написал юнит тест на это, то потратил бы на тест минуты 2 и проблемы бы не было вообще. Ну так, к слову.
Ghost2Постоялецwww28 июня 201817:25#128
9К720

Я бы его написал и он бы чудесно проходил на заданных rate/bps/dtime. Сама ошибка не вполне очевидна.

Ghost2Постоялецwww28 июня 201817:33#129
А вот если бы у меня было требование на этот метод, то я бы такого никогда не написал.
FordPerfectПостоялецwww19 июля 201821:34#130
Рисую (софтово) треугольник.
Барицентрические координаты иногда ползут (не 0 на границе), но только в части случаев.
И иногда рисуется правильно, а иногда выглядит как-то криво, хотя и не совсем очевидно как.

Решил проверить, как я его bounding box считаю (по которому цикл заливки).
Было:

        tri.x_lo=vi[0][0];tri.y_lo=vi[0][1];
        tri.x_hi=vi[0][0];tri.y_hi=vi[0][1];
        for(si32 i=1;i<2;++i)
        {
            if(vi[i][0]<tri.x_lo) tri.x_lo=vi[i][0];
            if(vi[i][1]<tri.y_lo) tri.y_lo=vi[i][1];
            if(vi[i][0]>tri.x_hi) tri.x_hi=vi[i][0];
            if(vi[i][1]>tri.y_hi) tri.y_hi=vi[i][1];
        }

Стало:

        tri.x_lo=vi[0][0];tri.y_lo=vi[0][1];
        tri.x_hi=vi[0][0];tri.y_hi=vi[0][1];
        for(si32 i=1;i<3;++i)
        {
            if(vi[i][0]<tri.x_lo) tri.x_lo=vi[i][0];
            if(vi[i][1]<tri.y_lo) tri.y_lo=vi[i][1];
            if(vi[i][0]>tri.x_hi) tri.x_hi=vi[i][0];
            if(vi[i][1]>tri.y_hi) tri.y_hi=vi[i][1];
        }

Примерно час времени.

Vlad2001_MFSПостоялецwww19 июля 201822:50#131
FordPerfect
Довольно обидно, когда на такую мелочь тратится куча времени...
}:+()___ [Smile]Постоялецwww20 июля 201814:58#132
Vlad2001_MFS
> Довольно обидно, когда на такую мелочь тратится куча времени...
Мой опыт показывает, что самое странное и необъяснимое поведение вызывают как раз такие тупые опечатки.
entrywayПостоялецwww20 июля 201815:21#133
for-ы по индексу в таком синтаксисе напрягают вне зависимости от. тупая конструкция.

Правка: 20 июля 2018 15:56

FordPerfectПостоялецwww20 июля 201818:54#134
}:+()___ [Smile]
> Мой опыт показывает, что самое странное и необъяснимое поведение вызывают как раз такие тупые опечатки.
Близкие впечатления.
Когда сидишь и думаешь, а точно ли правильно доказал все крайние случаи в хитром алгоритме, в результате баг зачастую с логикой собственно алгоритма вообще не связан, а тупая опечатка уровня "читаешь не оттуда".

entryway
Конкретно здесь - его вообще целиком развернуть можно, оно не сильно длиннее будет.

Страницы: 15 6 7 8 9 10 Следующая »

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

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