Макроси 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 Правити
За замовчуванням дорівнює нулю.