Пятничные факты #271 – Оптимизация жидкости и инспектор стиля GUI

Spread the love

опубликовал kovarex

Game Developers Session 2018

GDS 2018 будет проходить на следующей неделе, с 7 по 8 декабря. В этом году, как и в прошлом году, мы являемся серебряными спонсорами мероприятия, а это означает, что вы увидите брендинг Factorio вокруг мероприятия и в их официальном буклете. Часть подготовки на нашей стороне заключалась в том, чтобы создать хороший графический объект для их использования, который вы можете увидеть ниже:

Изображение представляет собой эстетическую композицию, демонстрирующую дизайн и тему игры и ее элементы (хотя и не обязательно логический смысл), а также содержит первый публичный показ нашего нового официального логотипа Wube Software.

Около половины офисной команды здесь будет присутствовать на мероприятии, поэтому, если вы тоже пойдете, вы можете столкнуться с нами.

Оптимизация жидкостей

Мы решаем изменения жидкости в 3 этапа:

  • Переместить всю логику жидкости в отдельную систему.
  • Объединить прямые секции труб в сегменты.
  • Подстроить логику потока жидкости, которая не будет оптимизацией, а улучшит механику игрового процесса (FFF-260).

Доминик только что закончил этап 1, и он был добавлен в 0,17, поэтому позвольте мне представить, что было изменено, и как это помогает. Подход аналогичен тому, что мы делали с конвейерами (FFF-176).
Одной из основных причин замедления моделирования является то, что каждый объект, обрабатывающий жидкость (труба, сборная машина с жидкостным соединением, нефтеперерабатывающий завод, бур с жидкостным соединением, насос), должен сохраняться как обновляемый, и его обновление нужно называть каждый тик только для обновления потока внутренних труб. Таким образом, буры / сборочные машины вынуждены делать свою логику вместо того, чтобы спать.

С точки зрения оптимизации каждый лишний кусочек данных, который нужно поместить в кеш процессора, подобен лишнему весу, который вам нужно носить с собой. Это замедляет симуляцию.

Труба используется только для вызова внутреннего обновления:

Другая проблема заключается в том, что память в трубе разбросана вокруг случайно. Поэтому мы вырезаем все псевдонимы из сущностей, использующих их, и помещаем их в отдельную систему (мы называем это Fluid Manager). Он хранит псевдоожиженные ячейки следующим образом:

Преимущество наличия данных в непрерывной памяти в основном заключается в том, что когда ЦП копирует данные из памяти в кеш, он делает это в кусках, поэтому при обновлении одной вещи следующий уже находится в кеше. Современные процессоры также являются интеллектуальными, и они могут обнаруживать непрерывный доступ к памяти, поэтому они заранее заблаговременно предварительно загружают последующие жидкостные ячейки.

Но это не так просто, поскольку у fluidbox всегда есть соседи (поскольку поток от одного  к другим), и один из соседей может находиться на другой части непрерывной памяти, из кеша, так что он все еще не идеально.

Следующим шагом было разделить fluidbox на то, что мы называем жидкостной системой. Жидкостная система – это в основном все Fluidbox, которые соединены вместе. Так, например, в этой установке для нефтеперерабатывающего завода имеется 5 жидкостных систем.

Каждая из жидкостных систем теперь представляет собой отдельную непрерывную память о fluidbox. Первым преимуществом этого является то, что он увеличивает вероятность того, что соседи  трубы близки (по памяти) к исходной трубе, данные кэширования, касаясь их для обновления, все еще могут быть там, когда они касаются соседства.

Но второе преимущество еще больше, так как текучие системы теперь независимы, а поток жидкости не мешает чему-либо еще на карте, их обновление может быть полностью распараллелено без каких-либо забот. Поэтому мы просто это сделали.

Окончательный критерий реальной полномасштабной карты, в которой используются трубы для производства материалов и энергии (ядерные реакторы), я смог увидеть в 6,5 раза больше, чем только обновление труб. Ускорение не было настолько большим на менее мудрых компьютерах, поскольку это зависело от процессора, размеров кэша, количества ядер процессора и т. Д., Но все еще было в 3 раза быстрее. Я также ожидаю, что ускорение станет больше с более крупными заводами с более раздельными системами жидкости, а также с будущим процессором с большим количеством ядер.

Доминик проверил каждый шаг с реальной игрой на своем разумном i7-4790k и записал со следующим общим приростом производительности.

Напомним, что это всего лишь этап 1, прежде чем фактически слияние прямых секций трубы в один fluidbox, который должен улучшить ситуацию снова. Даже в системах с большим количеством ветвлений, поскольку даже 2 fluidbox, объединенных в 1, должны помочь. В приведенном выше примере установки НПЗ кажется, что количество fluidbox может быть уменьшено в 4 раза или около того. Это должно сделать сбережения достаточно большими, чтобы оправдать запланированное 2-кратное замедление будущего алгоритма текучей среды, поскольку нам, вероятно, потребуется 2 прохода, чтобы он работал достаточно хорошо. У Dominik будет обновленная информация об алгоритме и выводах предыдущих обсуждений в будущем FFF.

Инспектор стиля GUI

Выполняется реализация нескольких редизайнов GUI, и это делается несколькими членами команды. Внезапно мы поняли, что координирование большего числа людей приносит новые проблемы (сюрприз ^^). Мы начали беспорядок в стилях, поскольку каждый изобретал свои собственные стили для того, чтобы графический интерфейс был таким же, как графические макеты, данные графическим отделом.

После некоторых дискуссий о том, как решить эту проблему, мы поняли, что в основном нам нужен общий язык с графическим отделом, когда речь заходит о именах иерархии стилей. Для этого нам нужно, чтобы каждый мог быстро проверить, какие стили используются там, где и что представляет собой иерархия. По этой причине мы сделали инспектора стиля GUI. Нажав клавишу (Control + F6 по умолчанию), каждый элемент пользовательского интерфейса отобразит всплывающую подсказку с информацией о виджетах и ​​ее стиле, а также выделит виджет. Сначала мы хотели использовать его только внутренне, но мы решили, что если он показывает некоторую информацию для графического интерфейса, созданного сценариями / модами, такими как имя и тип, может быть полезно также, чтобы писатели модов могли быстро проверить, что происходит

Мы даже используем цвета, чтобы помочь нам ориентироваться:

  • Красный: значение было бесполезно переопределено (что происходило много).
  • Зеленый: значение стиля, которое используется
  • Белый: значение стиля, которое не используется, поскольку оно перезаписывается потоком потомков.

Этот инструмент (даже когда его легко добавить) сразу же стал очень полезным, и он уже помог нам устранить некоторые беспорядки и должен повысить эффективность работы, когда речь заходит о дальнейшей реализации GUI. Основная реакция, когда я показала это остальной команде, была: «Почему раньше у нас этого не было?» … Ну, лучше поздно, чем никогда.
Это также означает, что мы показываем довольно много о том, как стиль GUI организован для игроков, поэтому нам нужно быть более осторожным, чтобы сделать его аккуратным, чтобы избежать сообщений об ошибках «странный беспорядок» в стилях.

Как всегда, дайте нам знать, что вы думаете на нашем форуме.


Комментарии: