Как статический анализ побуждает разработчика рефакторить код. По мотивам Source SDK / Comments / Habr

выглядит как не баг, а фича(предположение)

  unsigned short abs( unsigned short i )
  {
    return i >= 0 ? i : -i; // <=
  }

  DmeFramerate_t operator*=( int i )
  {
    Assert( abs( m_num * i ) <= USHRT_MAX ); // <=
    m_num *= ( unsigned short )i;
    return *this;
  }

у нас есть 2 интервала, поступает наибольший, его мы эвристически отсекаем если переполнение уводим в - получается приведение числа высшего интервала к низшему тоесть это для допустим анимаций если почитать про компрессинх(вчера читал там тоже о чем-то томже)

https://habr.com/ru/articles/491958/ может как-то с этим связано

современная система скелетки имеет допустим 150 костей, там есть какие-то тонкости хитрые как эти 150 костей закинуть в чуть меньше(память наверное) может суть в этом, а раньше возможно был расчет на память при потери ну допустим 10 кадров из последовательности, ну еще можно и меши пережать на максимум в - сабдивижн, на выходе пережатый меш, ужатые типы данных и потерялось ну 5-10 кадров, зато возможно как-то эвристически подогнано что незаметна потеря кадров, вполне реально мог быть расчет на такой расклад(а ну и плюс вершинная анимация как раз согласована с драконической ужатостью )

Как статический анализ побуждает разработчика рефакторить код. По мотивам Source SDK

Comments 2

Information