Блог розробників (FFF#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 організований для гравців, тому нам потрібно бути більш обережним, щоб зробити його акуратним, щоб уникнути повідомлень про помилки «дивний безлад» в стилях.

Як завжди, дайте нам знати, що ви думаєте на нашому форумі.


Comments: