Denis Kolosov
Если проблема выявляется при более лёгких сценариях, разве есть смысл в более сложных?
Вроде как, через Игровой Центр всё доступно "из коробки".
Вы статью-то читали? Там речь о проде шла? При первом запуске из-под отладки полезли краши, затем зависания, затем отвал координат. В чём разница поймать эти вещи под debug-ом или тебе о половине из них тесты скажут?
Индикация всех проблем происходила на этапе отладки, юнит-тесты испытали бы все те же проблемы при старте, что и клиентское приложение. unit-тесты относительно могли бы помочь только с математикой, но те, что есть, на тот момент не помогли.
С аллокатором нет, проблема-то не в каком-то невалидном коде, а в предрассудках компиляторов. Да и с математикой тоже, ведор-либа в unit-тестах не подрубается за ненадобностью. Если загружать в unit-тестах весь бэкграунд, то в лучшем случае тест также бы не прошёл, выплюнул сообщение почему не прошёл, а причин странного округления тесты бы не выявили. Это сейчас , когда проблема известна, можно запилить именно для её выявления unit-тест.
Да, но он у нас под стандарт C++ 0x, не обновляли пока.
В драйверах и модулях ядра хватает связки C+asm. В чём его превосходство перед этой связкой именно в плане производительности? Быстрее них только машинный код, но никак не rust. )
РАЗУМЕЕТСЯ! Причём те же, что и документацию и автоматическую коробку передач!
А, если серьёзно, во всех описанных проблемах они бесполезны.
1) Какая разница, где ты свалишься на разрушении smart_pointer-а, в тесте, или в реальном приложении? Причина от этого яснее не станет. Наоборот, thread safe local static быстрее словишь в реальном приложении, либо в функциональных тестах с применением ботов, считай то же приложение игры.
2) С макросами проблема видна на этапе компиляции, до тестов здесь ещё далеко.
3) Проверка .export-секции финального экзешника тоже тестами не покрыть. Эта проверка реализована в самом клиенте игры. Да, можно было бы написать дополнительные чекеры, которые бы отрабатывали на эпате сборки, но это по-большому счёту бесполезно.
На данный момент складывается ощущение, что rust ничему не замена, а, правда, кому-то было скучно, захотелось приключений. )
Исторически так сложилось. Да, можно было потратить теуву хучу времени, чтобы отрефакторить. Не получить никакого прироста в попугаях и радоваться тому, что из тысячи макросов в проекте стало на один меньше. А зачем?..
Я и имею в виду ваш текущий ПК, а не 10-ти летней давности. Без обновления компилятора ситуация у вас была бы ещё хуже.
Прогрузка объектов в мире может быть не моментальной, это вполне нормально для игр. Что касается настроек- вы не путайте, это совершенно другая оптимизация, исключительно рендера. О ней речи не шло, она только в ближайших планах. Более оптимально сгенерированный машинный код влияет на весь игровой процесс.
Блин, так быстро раскрыли лавочку... Обидно. )))
Да, вы всё правильно помните. Основная нагрузка на одно ядро. Есть фоновые потоки, но реально разгружающих основной поток всего 2 (чуть больше). На данный момент работаем над этим, но работы очень много, так что многопоточный pipeline это наше светлое будущее.
Интересный термин. ) Зачем же так с бедными макросами? Они хорошие, просто пользоваться нужно с умом. ) Про современные стандарты применительно к проекту, который относительно недавно слез с Visual Studio 20210, забавно слышать. ) Но тренд, конечно, на избавление от макросов, они зло, на костёр! )
За это время контента в игру было завезено предостаточно. Вполне возможно, что на вашем текущем ПК ещё года три назад они не завелись бы вообще.
По поводу объектов это интереснее. Пример можете привести?
Правильно догадываетесь. Я немного предвзято отношусь к boost-у, имхо, он не совсем про производительность, но, вполне возможно, я просто не умею его готовить, мы используем eastl::string_view.
Что касается мотивации string_view, то вот банальнейший пример.
Допустим, есть набор функций, принимающий const string &, а в коде много вызовов этих функций с const char *. В таких вызовах мы получаем лишние string constructor/destructor и new/delete. Есть несколько способов решить данную проблему. Например, запилить отдельные реализации для const char *. Вариант не особо интересный и багоопасный. А есть вариант преобразовать этот набор функций в шаблоны, и передавать string_view вместо const char *, т.к. API string и string_view практически идентичен, сами функции исправлять и не нужно, если только c_str() изменить на data(), если есть такое вызовы. Да, придётся пройтись по всему код и заменить вызовы. Процесс не особо увлекательный, но и в этом есть плюс, все неоптимальные вызовы можно будет поправить.