Z's Blog

I previously wrote two articles analyzing the implementation of reflection in UE, introducing the basic concepts of reflection in UE and some of the C++ features it relies on. This article will begin analyzing the specific process of UE’s reflection implementation.

The C++ standard does not have reflection features, and the reflection used in UE is a mechanism based on marker syntax and UHT scanning to generate auxiliary code. As David Wheeler famously said, “All problems in computer science can be solved by another level of indirection,” UHT does just that: it analyzes the marked code before actual compilation and generates real C++ code, collecting metadata regarding reflection types for runtime use.

UHT generates a large amount of code. To avoid organizational confusion in this article, I will mainly discuss the actual C++ code generated in generated.h after UHT processes reflection markers like GENERATED_BODY and UFUNCTION.

The code generated by UHT is located in generated.h and gen.cpp. The code in generated.h mostly defines some macros added to declared classes through compiler preprocessing to introduce common members, while the code in gen.cpp represents the specific code generated by UHT to describe class reflection information, maintaining separation of declaration and definition.

In the previous article, the rules and implementation of basic package splitting were introduced. After the basic packaging rules are stabilized, the focus in daily development shifts to asset management, package resource auditing, and analyzing asset sizes and redundancy in the project.

This article introduces resource packaging configuration in UE, commonly used asset management methods, and asset auditing tools in engineering practice. It is also a supplement to the previous article UE4 Hot Update: Splitting Basic Packages in the series on resource management for hot updates.

In previous articles, we introduced the implementation mechanism of UE hot updates and the automation process of hot updates. Recently, we plan to continue writing a few articles to discuss the process and rules of resource package management in UE hot updates.

Of course, different types of projects will have different packaging strategies, and resource management does not have a universal best strategy. This article mainly introduces the engineering practice of splitting the base package in the hot update process, involving the modification of the engine to implement a common splitting method for Android/iOS. We hope to provide some useful ideas for projects in different businesses.

In practical engineering, we abandoned the default package splitting scheme provided by UE and implemented a flexible package splitting scheme based on the HotPatcher framework. For details, see the article: Resource Management: Reshaping UE’s Package Splitting Scheme.

HotPatcher is an open-source version management and resource packaging tool for UE4 hot updates that I developed earlier. It allows for convenient differential analysis between versions and pak packaging. Previous articles have visually introduced this based on manual configuration and packaging within the editor. In actual engineering practice, it’s preferable to automate repetitive operations to avoid manual involvement. I added commandlet support to the plugin earlier, and recently, I have fixed some issues and added many optimizations for commandlet. This article discusses the engineering practice of the automated hot update process based on HotPatcher.

Open source is not just about making the code available; it’s about how to use your code to address real-world needs, continuously iterate and update, and build a community for open source projects. Based on my experiences with open source over the past couple of years, I want to share my views on open source from a developer’s perspective and some thoughts on open source behavior.

In the previous article, the basic concepts of UE’s reflection were introduced. This article begins to explore the specific implementation of UE’s reflection mechanism.

Before introducing UE’s code, some C++ features need to be highlighted. Although UE’s reflection implementation relies heavily on UHT’s code generation, it also requires support from C++ syntax features. Only by understanding these features and their underlying meanings can we better grasp UE’s reflection mechanism.

The C++ features and standards described in this article are based on ISO/IEC 14882:2014, which is the C++14 standard.

Reflection refers to the ability of a program to perform self-inspection at runtime, which is very useful in the editor’s property panel, serialization, GC, and other areas. However, C++ does not support reflection features inherently. UE implements the generation of reflection information through UHT based on the syntax of C++, thereby achieving the goal of runtime reflection.

In previous articles, some content related to UE’s build system and reflection was discussed.

Articles related to UE’s build system:

• Build flow of the Unreal Engine4 project
• UE4 Build System: Target and Module
• Differences and Connections Between UEC++ and Standard C++

Articles on using UE’s reflection mechanism for various tricks:

• UE4: Hook UObject

The implementation of UE’s reflection relies on UHT in the build system to perform code generation. This article provides a basic concept introduction to UE’s reflection, and subsequent articles will thoroughly introduce the implementation mechanisms of reflection in UE.

The 2020 Unreal Open Day was held in the form of online live streaming and technical sub-forums. I was very happy to participate in this year’s UOD event. I recorded a technical video for UOD and also attended the UOD award ceremony live in Shanghai. I am honored and grateful to Epic for awarding me the Outstanding Community Contributor award, which is both recognition and motivation for me. I will strive to produce more technical content to promote the development of the UE community.

This article serves as a simple record, organizing the materials related to UOD and summarizing the videos, presentation PPTs, and relevant materials I participated in, as well as some photos taken on-site during the UOD live broadcast.

When developing Android with UE4, it is sometimes necessary to obtain platform-related information or perform platform-related operations. In such cases, it is essential to add Java code in the codebase and call it from C++. Some requirements also necessitate receiving events from the Java side in the game, requiring handling the Java calling C++ process.

This article mainly involves the following sections:

• Adding Java code to UE projects
• Java function signature rules
• Java calling C++ functions
• C++ calling Java functions

How to utilize UE’s UPL features, Java’s signature rules, and implement JNI calls in UE will be detailed in the article.

Hook is a mechanism that allows you to meet your requirements by intercepting and hooking into certain events. Unlike traditional low-level hooks, this article mainly introduces how to use similar hooking mechanisms in UE to achieve business needs.

Some requirements necessitate the global modification of all objects of a specific class, such as playing a uniform sound effect for a certain type of Button in the UI. If every control needs to listen to its OnClicked and then play the sound, it leads to a lot of redundant operations. So, I want to find a method that can globally listen to the click events of all UButtons and handle them collectively. Alternatively, if I want to control an attribute that is invisible in blueprints, modifying the engine’s code for simple needs seems counterproductive.

These requirements can be achieved through UE’s reflection mechanism. This article provides a simple implementation analysis.