Макроси UE4, Unreal Engine 4 вікі, FANDOM powered by Wikia

Макроси перевірок та протоколювання

check Правити

Якщо значенняexprпомилкове, ці макроси викликають видачу повідомлення в балку і аварійне завершення програми (з будь-якими нюансами, пов'язаними з налагодженням і т.п.).

Макроси checkf/checkfSlow відрізняються від простих check/checkSlow видачею зазначеного повідомлення з параметрами.

Якщо двигун зібраний без контролю, ці макроси ніяких дій не виконують (на відміну від макросів групи verify).

Макроси, що закінчуються на Slow, виконують свої функції при певному символі DO_GUARD_SLOW (визначений тільки для налагоджувальних збірок движка), а макроси без Slow - при певному символі DO_CHECK (визначений як у збірках налагодження, так і в збірках для розробки гри, але не визначений в релізних зборках). За діями вони є повністю ідентичними.

UE_CLOG Правити

ЯкщоConditionпомилково, у лог видається задане повідомлення. При цьому, якщоVerbosityвказує на фатальну помилку, виконання програми завершується.

Схоже, що можлива компіляція без підтримки ліг, проте обробка фатальних повідомлень все одно виконуватиметься.

UE_LOG Правити

У лог видається задане повідомлення. При цьому, якщоVerbosityвказує на фатальну помилку, виконання програми завершується.

Схоже, що можлива компіляція без підтримки ліг, проте обробка фатальних повідомлень все одно виконуватиметься.

verify

Якщо значенняexprпомилкове, ці макроси викликають видачу повідомлення в балку і аварійне завершення програми (з будь-якими нюансами, пов'язаними з налагодженням і т.п.).

Макроси verifyf/verifyfSlow відрізняються від простих verify/verifySlow видачею зазначеного повідомлення із параметрами.

Якщо двигунзібраний без контролю, ці макроси не викликають видачі інформації та завершення програми, проте, на відміну від макросів групи check), значення виразуexprобчислюється завжди.

Макроси, що закінчуються на Slow, виконують свої функції при певному символі DO_GUARD_SLOW (тобто тільки у налагоджувальних складаннях), а макроси без Slow - при певному символі DO_CHECK (у налагоджувальних складаннях і складання для розробки гри). За діями вони є повністю ідентичними.

Макроси збору статистики

DEFINE_STAT Правити

Визначає глобальну змінну з ім'ям StatPtr_Stat, яка використовується для безпечного збору будь-якої статистики. Параметр Stat задає ім'я статистичної інформації, що збирається. Наприклад, ім'я STAT_ConstructObject використовується для обліку часу, витрачається створення об'єктів.

SCOPE_CYCLE_COUNTER Правити

Цей макрос використовується для підрахунку часу роботи деякого фрагмента коду, як правило окремої функції. Він розміщується на самому початку блоку коду (відразу після «Stat задає ім'я статистичної інформації, що збирається. Наприклад, ім'я STAT_ConstructObject використовується для обліку часу, що витрачається на створення об'єктів; воно використовується у внутрішній функції StaticConstructObject_Internal, яка опосередковано викликається, наприклад, шаблонної функції NewObject.

Технічно цей макрос створює локальну змінну, конструктор і деструктор якої відповідно засікають час початку і кінця життя змінної, тобто. початку та кінця виконання коду блоку, в якому макрос розташований. Цей час додається до відповідної глобальної змінної збору статистики, десь визначеної за допомогою макросу DEFINE_STAT.

Макроси модульності

IMPLEMENT_APPLICATION Правити

IMPLEMENT_DEBUGGAME Правити

IMPLEMENT_FOREIGN_ENGINE_DIR Правити

IMPLEMENT_GAME_MODULE Правити

Цей макрос повинен використовуватися замість звичайного IMPLEMENT_MODULE у модулях, що містять код гри, а не власне движка.

Технічно цей макрос викликає макрос IMPLEMENT_MODULE, не генеруючи власного коду.

IMPLEMENT_MODULE Правити

Цей макрос призначений, щоб сповістити двигун загалом про існування деякого модуля та його головного класу та забезпечити його ініціалізацію. Він повинен включатися в кожен модуль, що потенційно збирається в незалежну DLL, проте він працює і для монолітного складання.

У разі монолітного складання даний макрос забезпечує ініціалізацію модуля (технічно є частиною exe-файлу) та його реєстрацію в движку, створюючи статичну змінну за допомогою шаблонного класу FStaticallyLinkedModuleRegistrant. Оскільки змінна є статичною, виклик відповідного конструктора здійснюється компілятором автоматично на початок виконання основного коду програми (WinMain тощо.). Цим же макросом визначається функція ініціалізації модуля, що не виконує ніяких реальних дій.

У випадку модульної збірки макрос IMPLEMENT_MODULE генерує стандартну функцію ініціалізації незалежного модуля InitializeModule, єдиним завданням якої є динамічне створення (за допомогою оператора new) екземпляра головного класу модуля і повернення покажчика на нього викликаної програмі (коду движка, що відповідає за завантаження). Крім того, викликається макрос PER_MODULE_BOILERPLATE, що забезпечує перевизначення операторів динамічного виділення та звільнення пам'яті для даного модуля (у випадку з монолітним складанням цей макрос не викликається,оскільки він повинен викликатися лише один раз для файлу, що виконується).

Незалежно від виду складання макросу IMPLEMENT_MODULE викликає макрос PER_MODULE_BOILERPLATE_ANYLINK. У поточній версії движка останній не генерує жодного коду, проте при необхідності він може бути визначений автором конкретної програми.

IMPLEMENT_PRIMARY_GAME_MODULE Правити

PER_MODULE_BOILERPLATE Правити

Основну частину тіла макросу становлять визначення глобальних змінних, що використовуються для налагодження:

  • GFNameTableForDebuggerVisualizers
  • GFNameTableForDebuggerVisualizers_MT
  • GSerialNumberBlocksForDebugVisualizers
  • GObjectArrayForDebugVisualizers
  • GFNameDebuggerVisualizersIsUE3

Крім цих змінних, виконується перевизначення операторів виділення та звільнення пам'яті за допомогою макросу REPLACEMENT_OPERATOR_NEW_AND_DELETE.

Як правило, цей макрос не використовується прямо; замість нього у модулі викликається макрос IMPLEMENT_MODULE. Однак у монолітній збірці він повинен викликатись явно, але тільки один раз.

PER_MODULE_BOILERPLATE_ANYLINK

Цей макрос повинен зустрічатися один раз у будь-якому модулі незалежно від того, який збирається двигун - модульний (що складається з exe-файлу та групи dll-файлів) або монолітний (тільки exe-файл). Якщо його не визначено, у файлі ModuleBoilerplate.h він визначається як порожній.

Як правило, потреби прямого використання цього макросу немає: він включається в модуль в макросі IMPLEMENT_MODULE.

REPLACEMENT_OPERATOR_NEW_AND_DELETE Правити

Цей макрос включається один раз у будь-який незалежний (створюваний окремий dll-файл) модуль і перевизначає оператори new, new[], delete і delete[]. Таке перевизначення необхідне,щоб усі компоненти гри використовували одні й самі низькорівневі підпрограми виділення і звільнення пам'яті, реалізовані у класі FMemory.

Як правило, використовувати цей макрос явно не потрібно: він включається до складу модуля за допомогою макросу PER_MODULE_BOILERPLATE, а останній, у свою чергу, - макросом IMPLEMENT_MODULE.

Макроси управління умовною трансляцією

Значна частина цих макросів визначається через командний рядок та/або формується у файлі Build.h.

Управління налагоджувальними засобами

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

UE_BUILD_DEBUG Правити

Максимальний рівень налагоджувальних засобів: збірка призначена для налагодження коду двигуна.

UE_BUILD_DEVELOPMENT Правити

У код включаються всі налагоджувальні засоби, крім найповільніших: складання призначене для розробки гри.

UE_BUILD_SHIPPING Правити

Налагоджувальні засоби в код не включаються: складання призначене для кінцевих користувачів.

UE_BUILD_SHIPPING_EDITOR Правити

Схоже, цей символ застарів. За промовчанням його використання призведе до помилки компіляції.

UE_BUILD_TEST Правити

У код включається невеликий набір налагоджувальних засобів: складання призначене для тестування створеної гри.

Управління видами створюваної програми

UE_EDITOR Правити

UE_GAME Правити

UE_SERVER Правити

дорівнює одиниці, якщо виконується складання коду для виділеного сервера, і нулю, якщо збирається код клієнта або монолітноїігри (що не використовує клієнт-серверну модель).

Управління включеними можливостями

HACK_HEADER_GENERATOR Правити

дорівнює одиниці, якщо необхідно генерувати деяку додаткову інформацію для UHT (Unreal Header Tool).

IS_MONOLITHIC Правити

дорівнює одиниці, якщо створюється монолітна збірка (весь код включається в єдиний exe-файл, а не розбитий на кілька dll-файлів).

IS_PROGRAM

дорівнює одиниці, якщо створюється програма (компілятор шейдерів, файл-сервер і т.п.), а не гра або навколоігрове додаток.

UE_BUILD_MINIMAL Правити

дорівнює одиниці, якщо потрібно включати лише мінімально необхідний обсяг функціоналу.

WITH_AUTOMATION_WORKER Правити

дорівнює одиниці, якщо включається функціональність Automation Worker. За умовчанням вона включається для налагоджувальної або розробної складання (обидва макроси UE_BUILD_SHIPPING і UE_BUILD_TEST рівні нулю) за умови, що не генерується додаткова інформація для UHT (макрос HACK_HEADER_GENERATOR дорівнює нулю).

WITH_EDITOR

WITH_ENGINE Правити

дорівнює одиниці, якщо в програму включається код движка.

WITH_HOT_RELOAD Правити

дорівнює одиниці, якщо включається підтримка «гарячої» перезавантаження модулів. За замовчуванням це так для будь-яких модульних збірок, крім релізної версії (макроси IS_MONOLITHIC та UE_BUILD_SHIPPING дорівнюють нулю).

WITH_HOT_RELOAD_CTORS Правити

дорівнює одиниці, якщо використовуються спеціальні порожні конструктори, призначені для «гарячої» перезавантаження модулів.

В даний час завжди дорівнює одиниці.

WITH_PLUGIN_SUPPORT Правити

дорівнює одиниці, якщо включається підтримка плагінів.

WITH_UNREAL_DEVELOPER_TOOLS Правити

дорівнює одиниці, якщо до програми включається код засобів розробки.

Управління перевірками

ALLOW_DEBUG_FILES Правити

Якщо дорівнює одиниці, із програми, що збирається, виявляється можливим зберігати налагоджувальні файли - скріншоти, результати профілювання і т.п.

CHECK_PUREVIRTUALS

дорівнює одиниці, якщо необхідно перевіряти, чи дійсно реалізовані методи, оголошені абстрактними («чисті віртуальні функції» в термінології Сі++) у базових класах. За замовчуванням дорівнює нулю.

DO_CHECK Правити

DO_GUARD_SLOW Правити

Якщо дорівнює одиниці, код включаються перевірки, що здійснюються макросами checkSlow, checkfSlow і verifySlow.

дорівнює одиниці тільки у налагоджувальних зборках (макрос UE_BUILD_DEBUG дорівнює одиниці).

LOOKING_FOR_PERF_ISSUES Правити

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

За замовчуванням цей макрос дорівнює нулю.

NO_LOGGING Правити

Якщо одиниці, протокол і виведення текстових повідомлень вимкнено.

STATS Правити

Якщо дорівнює одиниці, код включається збір статистики.

UE_BLUEPRINT_EVENTGRAPH_FASTCALLS

Коли одиниці дорівнює, для графів подій без параметрів у блупринтах використовується швидкий виклик.

USE_CHECKS_IN_SHIPPING Правити

дорівнює одиниці, якщо в релізному складання повинні бути присутніми перевірки. За замовчуванням дорівнює нулю.

USE_CIRCULAR_DEPENDENCY_LOAD_DEFERRING Правити

USE_DEFERRED_DEPENDENCY_CHECK_VERIFICATION_TESTS Відправити

USE_LOGGING_IN_SHIPPING Правити

дорівнює одиниці,якщо у релізному складання повинен використовуватися висновок протоколу. За замовчуванням дорівнює нулю.

USE_NETWORK_PROFILER Правити

Коли дорівнює одиниці, включаються засоби профілювання продуктивності підсистеми мережної.

Значення цього макросу збігається із значенням макросу STATS.

USE_NULL_RHI Правити

За замовчуванням дорівнює нулю.

USE_UBER_GRAPH_PERSISTENT_FRAME Правити