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

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

Страницы: 18 9 10 1113 Следующая »
#120
23:54, 3 мая 2018

Роман Шувалов
> Я ничему не научился:
это потому что язык неправильный - пиши на Паскале :D


#121
2:59, 13 мая 2018

Оказывается эта зараза сидела у меня в коде пару лет:
2018-05-13 02_55_46-Great V Engine 2 - Microsoft Visual Studio | Летопись багов
Раскопал, когда попытался посчитать stride вручную, а не "по нормальному".

#122
4:23, 13 мая 2018

Great V.
> Раскопал, когда попытался посчитать stride вручную, а не "по нормальному".
std::array этому человеку!

#123
10:52, 13 мая 2018

Aroch
Не, ну а что бы это там изменило? У меня там и так vector.

#124
12:30, 13 мая 2018

Great V.
не обращай внимания, кто знает тот поймет :)

#125
(Правка: 14:44) 6:48, 14 мая 2018

Рассинхронизация.
Долго не мог понять, каким образом клиентская копия мира по времени убегает вперёд от серверной копии.

После тщательно расписанных логов (логи рулят!)
выяснилось, что игровой тик имеет програмное ограничение - не больше 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 млс.

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

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

#126
(Правка: 16:28) 16:25, 28 июня 2018

Вот такое вот вычисление размера буфера для сигнала:

/**  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 - частота в герцах

#127
17:05, 28 июня 2018

Ghost2
> Искал где-то сутки :)
Если бы сразу написал юнит тест на это, то потратил бы на тест минуты 2 и проблемы бы не было вообще. Ну так, к слову.

#128
17:25, 28 июня 2018

9К720

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

#129
17:33, 28 июня 2018

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

#130
21:34, 19 июля 2018

Рисую (софтово) треугольник.
Барицентрические координаты иногда ползут (не 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];
        }

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

#131
22:50, 19 июля 2018

FordPerfect
Довольно обидно, когда на такую мелочь тратится куча времени...

#132
14:58, 20 июля 2018

Vlad2001_MFS
> Довольно обидно, когда на такую мелочь тратится куча времени...
Мой опыт показывает, что самое странное и необъяснимое поведение вызывают как раз такие тупые опечатки.

#133
(Правка: 15:56) 15:21, 20 июля 2018
for-ы по индексу в таком синтаксисе напрягают вне зависимости от. тупая конструкция.
#134
18:54, 20 июля 2018

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

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

Страницы: 18 9 10 1113 Следующая »
ФлеймФорумПрограммирование