Engine processing method, device, medium, and program product

Abstract

The embodiments of the present specification provide an engine processing method, device, medium and program product, wherein the method comprises: receiving an access instruction sent by a target platform, and deploying a kernel module and a target application module of a target engine on the target platform, wherein the target application module is an application module corresponding to the target platform among a plurality of application modules of the target engine; creating at least one application component through the target application module deployed on the target platform; initializing the application component and an engine function, and controlling the target platform to display an engine interface of the target engine. By deploying the kernel module and the target application module on the target platform, the engine can be accessed to the target platform, so that the engine can provide support for the target platform; by creating the application component, initializing the application component and the engine function, and completing engine starting, project development based on the target platform can be implemented in the running environment of the target platform, and the product developed can also have compatibility for the target platform.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of software development technology, and in particular to an engine processing method, device, medium, and program product. Background Technology

[0002] With the continuous advancement of technology, electronic devices have developed rapidly, enriching people's lives. Because different electronic devices employ different operating systems and other core technologies, several isolated software ecosystems have emerged, primarily including Windows-based software ecosystems, iOS-based software ecosystems, HarmonyOS-based software ecosystems, Android-based software ecosystems, and so on.

[0003] As a development tool for games and audio / video applications, an engine needs to be compatible with different operating systems and application platforms to simplify the multi-platform development process, reduce development and maintenance costs, and ensure stable operation of programs on various platforms. Therefore, the multi-platform compatibility of an engine is particularly important. However, currently, the compatibility of engines is limited, making it difficult to support more platforms, especially newly released ones, which significantly hinders project development. Summary of the Invention

[0004] In view of the above, embodiments of this specification provide an engine processing method. One or more embodiments of this specification also relate to a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0005] According to a first aspect of the embodiments of this specification, an engine processing method is provided, comprising:

[0006] Receive the access command sent by the target platform, and deploy the kernel module and target application module of the target engine on the target platform. The target application module is the application module corresponding to the target platform among the multiple application modules of the target engine.

[0007] By deploying a target application module on a target platform, at least one application component is created, wherein the application component is used to implement the engine functions of the target engine on the target platform;

[0008] Initialize application components and engine functions, and control the target platform to display the target engine's interface.

[0009] According to a second aspect of the embodiments of this specification, a computing device is provided, comprising:

[0010] Memory and processor;

[0011] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the above-described engine processing method.

[0012] According to a third aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions that, when executed by a processor, implement the steps of the engine processing method described above.

[0013] According to a fourth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the engine processing method described above.

[0014] One embodiment of this specification implements receiving an access command sent by a target platform, deploying the kernel module and target application module of the target engine on the target platform, wherein the target application module is the application module corresponding to the target platform among multiple application modules of the target engine; creating at least one application component through the target application module deployed on the target platform, wherein the application component is used to implement the engine function of the target engine on the target platform; initializing the application component and engine function, and controlling the target platform to display the engine interface of the target engine.

[0015] Thus, by receiving the access command sent by the target platform, the kernel module and application module of the target engine are deployed on the target platform, enabling the target engine to access the target platform and provide support for it. By deploying the application module on the target platform, at least one application component is created, allowing the target engine to be started after access is completed. By initializing the application component and engine functions, the target platform is controlled to display the engine interface of the target engine, thereby initializing the engine and completing the startup process of the target engine on the target platform. This allows project development based on the target engine to be carried out in the development environment provided by the target platform, and the developed product can run stably on the target platform with good platform compatibility. Attached Figure Description

[0016] Figure 1 This is an engine architecture diagram of a target engine provided in one embodiment of this specification;

[0017] Figure 2 This is a flowchart illustrating an engine processing method provided in one embodiment of this specification;

[0018] Figure 3 This is an engine architecture diagram of a self-developed engine provided in one embodiment of this specification;

[0019] Figure 4This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0020] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0021] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0022] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0023] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0024] This specification provides an engine processing method, and also relates to a computing device, a computer-readable storage medium, and a computer program product, which are described in detail in the following embodiments.

[0025] See Figure 1 , Figure 1This diagram illustrates an engine architecture diagram of a target engine according to an embodiment of this specification. Specifically, the target engine comprises two main components: an application side and an engine side. The application side includes various application modules, each containing corresponding application code and a debugger. The application modules are encapsulated based on their respective application platforms. The application code is written in a system language supported by the application platform and is used to implement the relevant functions of the engine. The debugger is provided by the application platform corresponding to each application module. When the program runs on the application platform, the debugger can perform performance diagnostics and data collection, thereby enabling automated testing across multiple devices and operating systems. This ensures that the application runs stably on different devices and operating systems and promptly detects performance bottlenecks and platform compatibility issues.

[0026] The engine includes a kernel module, which can comprise various components such as a graphics rendering layer, input management layer, abstraction layer, engine resources, file system, thread scheduling module, engine editing tools, project management module, mixed reality module, resource production module, and resource management module. The kernel module adheres to a unified coding standard; both existing and newly developed code within the kernel module are refactored or written based on this unified standard.

[0027] Each application module achieves cross-language interaction with the kernel module through its corresponding cross-language interaction interface.

[0028] See Figure 2 , Figure 2 A flowchart of an engine processing method according to an embodiment of this specification is shown, which specifically includes the following steps.

[0029] Step 202: Receive the access command sent by the target platform, and deploy the kernel module of the target engine and the target application module on the target platform. The target application module is the application module corresponding to the target platform among the multiple application modules of the target engine.

[0030] Specifically, a platform can be understood as the basic framework and environment that enables the deployment and operation of computer programs and supports the development and operation of application software. Different platforms may support different operating systems.

[0031] For example, the operating system may include HarmonyOS, HarmonyOS NEXT, Android, iOS, macOS, Windows, and Linux, etc.

[0032] In practical applications, because the software ecosystems corresponding to different operating systems are often isolated from each other, the specific implementation methods of the same function and the management and configuration methods of resources differ on different platforms. Therefore, it is crucial for engine developers to know how to connect the engine to different platforms, enable the engine to support various platforms, and enable the engine to start project development on different platforms, as well as how to run products developed based on the engine normally on different platforms, so that products developed based on the engine have good compatibility with various platforms.

[0033] Specifically, the target platform can be understood as any platform, and the target platform has a corresponding operating system.

[0034] Optionally, the target platform's operating system can be any of the aforementioned operating systems.

[0035] It should be noted that HarmonyOS NEXT, as the first major version following HarmonyOS 1.0 to HarmonyOS 4.0, boasts excellent performance and innovative features. Providing support and compatibility for the HarmonyOS NEXT operating system will help us stay at the forefront of game engine technology, promote innovation in the software industry, and provide users with a convenient and high-quality user experience.

[0036] Therefore, the following will take the HarmonyOS NEXT platform as an example to further explain the embodiments of this specification.

[0037] Specifically, access commands can be understood as instructions used to direct the target engine to access the target platform. Access commands can specifically be commands within the official HarmonyOS NEXT integrated development environment, DevEco Studio.

[0038] Specifically, an engine is a component or framework in a computer system used to perform computational tasks, process data, execute instructions, and manage resources. It provides the underlying architecture or toolset to help developers quickly build, deploy, and manage applications. It can include various functions such as data processing, algorithm implementation, and user interface design.

[0039] A target engine can be understood as a game engine that provides functions such as graphics rendering, physics simulation, and sound effects processing, enabling game developers to quickly create games. For example, game engines can include Unity, Unreal Engine, Cocos2d-x, and so on.

[0040] In one or more embodiments of this specification, the target engine may specifically refer to a self-developed engine based on the independent research and development of the engine developers.

[0041] Optionally, the target engine mainly includes a kernel module and multiple application modules.

[0042] The kernel module can be understood as the module corresponding to the engine. It mainly includes the engine's underlying code, engine resource files, and various editors provided by the engine. The kernel module is used to implement the various functions of the engine.

[0043] Furthermore, the code in the kernel module is written based on the language specifications supported by the engine. Different developers use the same language specifications to ensure the maintainability of the code and its compatibility with multiple platforms.

[0044] In one optional embodiment of this specification, the kernel module is also called the C++ engine module, which is developed based on the C++ language standard specification.

[0045] Specifically, application modules can be understood as modules corresponding to different platforms, encapsulated based on the system language of each platform. Application modules may contain specific implementation methods for the corresponding platform, platform-specific resources, files, and so on. Application modules can also be understood as platform layers within the engine that correspond to each platform.

[0046] For example, HarmonyOS NEXT corresponds to the ArkTS platform layer, Android corresponds to the Java platform layer, iOS and macOS correspond to the Objective-C platform layer, and Windows and Linux correspond to the C++ platform layer.

[0047] The target application module can be understood as the application module corresponding to the target platform. In an optional embodiment of this specification, the target application module is the application module corresponding to HarmonyOS NEXT, that is, the ArkTS platform layer, which can support the official HarmonyOS NEXT integrated development environment DevEco Studio and the official HarmonyOS NEXT NDK development solution Node-API. The target application module includes ArkTS platform layer code, resources, and files configured based on HarmonyOS NEXT.

[0048] In practical applications, the target application module not only enables access to the target engine on any device that supports HarmonyOS NEXT and allows for project development through the target engine, but also ensures that software products developed based on the target engine are compatible with any device that supports HarmonyOS NEXT.

[0049] In practice, before integrating the target engine into the target platform, the engine developers need to complete the development of the target engine.

[0050] According to one or more optional embodiments of this specification, before receiving the access instruction sent by the target platform, the following steps may also be included:

[0051] Configure the kernel module and multiple application modules. The kernel module is configured based on a unified coding standard and is used to implement the common logic of the target engine.

[0052] Specifically, a kernel module can be understood as a module corresponding to the engine side of the target engine, which is encapsulated based on the engine's native language. A kernel module mainly includes the engine's underlying code, engine resources, various editors provided by the engine, project files, etc., and is used to implement the engine's various functions.

[0053] In one optional embodiment of this specification, the kernel module is also called the C++ engine module, which refactors the existing engine code and develops new content based on the C++ language standard specification.

[0054] Specifically, general logic can be understood as the logic that the engine itself can implement, which may include the engine's C++ functions, the interfaces provided by the engine, engine functions, the editor, and so on.

[0055] Specifically, application modules can be understood as modules encapsulated based on the system language of each platform. Application modules can also be called platform layers.

[0056] Optionally, depending on the different operating systems the platform supports, corresponding application modules can be configured in the target engine for each operating system platform. That is, the target engine can include multiple different application modules, each corresponding to a different platform.

[0057] By applying this embodiment, by configuring the kernel module and multiple application modules separately, it is possible to encapsulate different application modules, reduce the coupling between application modules and the engine kernel, improve the engine's compatibility with different platforms and the engine's scalability, thereby enabling the development of a cross-platform self-developed engine. Furthermore, by having development team members follow a unified coding standard, the written code format can be compatible with the standards of all target platforms, thereby increasing the maintainability of the code.

[0058] In an optional embodiment of this specification, the kernel module includes a graphics rendering layer; configuring the kernel module may include the following steps:

[0059] Configure the corresponding graphical interface for each platform for multiple platforms;

[0060] Encapsulate the graphics interfaces corresponding to each platform to obtain the target graphics interface corresponding to the graphics rendering layer.

[0061] Specifically, the graphics rendering layer, also known as the graphics rendering pipeline layer, is one of the lowest-level architectures designed for the target engine. The graphics rendering layer primarily provides graphics rendering functionality; it is used to present graphics through the rendering pipeline.

[0062] The reason why different platforms have different graphics interfaces is that different platforms have different implementations of graphics rendering.

[0063] Optionally, for multiple platforms, the corresponding graphical interface for each platform can be configured separately, which may include:

[0064] Based on the underlying graphics API, macros corresponding to each platform are configured to obtain the corresponding graphics interface for each platform.

[0065] Specifically, the target graphical interface can be understood as a general graphical interface that is encapsulated based on the graphical interfaces corresponding to each platform.

[0066] In practice, all platforms can call this universal graphics interface to achieve graphics rendering and presentation.

[0067] For example, the underlying graphics API could be Vulkan. Vulkan is a cross-platform 2D and 3D graphics application programming interface (API) with advantages such as cross-platform support, low-level access, high performance and low latency, and full functionality. It can run on multiple operating system platforms (such as PC, Android, iOS, and HarmonyOS NEXT), providing developers with broad compatibility. In addition, Vulkan also provides support for virtual reality, offering users a smoother VR and AR experience through its high performance and low latency characteristics.

[0068] This embodiment employs a cross-platform rendering interface technology that is independent of the underlying graphics device interface. Based on the underlying graphics API (such as Vulkan), it encapsulates the system API at the graphics rendering pipeline level to obtain a universal graphics interface. This achieves independence from the underlying graphics device interface, enabling products developed based on the engine to run on Windows, Android phones, iPhones, and mobile devices supporting HarmonyOS NEXT, and supporting AR and VR display output and interaction. This not only allows the engine to run on multiple devices and platforms, realizing its cross-platform design, but also enables multi-platform deployment and collaboration with real-time debugging systems, multi-platform performance diagnostics, and data collection systems, achieving multi-platform compatibility and adaptation.

[0069] In an optional embodiment of this specification, the kernel module includes an input management layer; configuring the kernel module may include the following steps:

[0070] Configure the target input interface corresponding to the input management layer. The target input interface is used to receive input signals from various types of devices and convert the input signals into target processing instructions corresponding to the target device type based on the target device type of the input signals.

[0071] Specifically, the input management layer can be understood as a unified input management system designed for the target engine, providing additional support for input from external devices on mobile devices. For example, external devices may include Bluetooth devices, keyboards, and gamepads, etc.

[0072] Specifically, the target input interface can be understood as a unified input interface capable of receiving input signals from different external devices, that is, supporting different input methods. For example, different input methods may include keyboard, mouse, touch screen, gamepad input, etc., according to various platform specifications.

[0073] Optionally, the target input interface receives input signals from various types of devices and can determine the target device type corresponding to the input signal; based on the target device type, the input signal is converted into a target processing instruction corresponding to the target device type.

[0074] Specifically, target processing instructions are instructions that the target engine can recognize and process.

[0075] By applying this embodiment, by defining a unified input interface, the target engine can select the appropriate input method according to the device type at runtime. Users can use wired, Bluetooth and other input methods even on mobile devices, and experience the engine product more immersively through external devices such as mice, keyboards and gamepads.

[0076] In one optional embodiment of this specification, configuring multiple application modules may include the following steps:

[0077] Obtain the platform-level code written in the system language corresponding to each platform and the resources configured for each platform;

[0078] The first platform layer code and the first resource are encapsulated into the first application module. The first application module is the application module corresponding to the first platform. The first platform can be any one of the platforms. The first platform layer code is the code written based on the system language corresponding to the first platform. The first resource is the resource configured for the first platform.

[0079] Specifically, platform layer code can be understood as code written for each platform using the corresponding system language.

[0080] In practical applications, the specific implementation of the same function differs on different platforms; the storage format of resources and the file management method also differ on different platforms. Therefore, developers will develop corresponding platform-level code for each platform and configure the corresponding files and resources separately.

[0081] For example, for the HarmonyOS NEXT platform, the ArkTS platform layer code will be developed based on the system language supported by HarmonyOS NEXT, and the files and resources supported by HarmonyOS NEXT will be configured.

[0082] In actual implementation, when developing corresponding platform-layer code for each platform and configuring the acquisition of resources, the platform-layer code and resources belonging to the same platform can be encapsulated into the application module corresponding to that platform, that is, the platform layer.

[0083] For example, the ArkTS platform layer code and its corresponding files and resources can be encapsulated into the ArkTS platform layer. Similarly, the platform layer code for the Android platform can be encapsulated into the Java platform layer; the platform layer code for iOS and macOS platforms can be encapsulated into the Objective-C platform layer; and the platform layer code for Windows and Linux platforms can be encapsulated into the C++ platform layer.

[0084] By applying this embodiment, through module division, the corresponding platform layer can be accessed according to different system languages, enabling the encapsulation of different platform layers, reducing coupling with the engine kernel, and improving engine performance. This allows the engine to develop the corresponding platform layer using the system language supported by the platform, achieving cross-platform compatibility for various platforms and realizing better compatibility.

[0085] In practical applications, in order to achieve cross-language interaction between application modules and kernel modules, in addition to separately encapsulating each application module and kernel module, in an optional embodiment of this specification, after encapsulating the first platform layer code and the first resource into the first application module, the following steps may also be included:

[0086] Based on the operating system adapted to the first application module, configure the cross-language interaction interface corresponding to the first application module. The cross-language interaction interface is used to realize cross-language interaction between the first application module and the kernel module.

[0087] Specifically, the cross-language interaction interface can be understood as the interface defined in the first application module, which enables cross-language interaction between the first application module and the kernel module.

[0088] For example, when the first application module is the ArkTS platform layer, the cross-language interaction interface corresponding to the ArkTS platform layer is Node-API.

[0089] In practical applications, functions can be exported from the kernel module through a cross-language interaction interface, while some system functions of the first application module are provided to the kernel module, thereby realizing cross-language interaction between the first application module and the kernel module.

[0090] For example, when the first application module is the ArkTS platform layer and the cross-language interaction interface is Node-API, C++ functions exported from the C++ engine module can be obtained through the Node-API interface, while some ArkTS system functions are provided to the C++ engine module to realize cross-language interaction between the ArkTS platform layer and C++.

[0091] By applying this embodiment, by configuring the cross-language interaction interface corresponding to the application module according to the operating system adapted to the application module, cross-language interaction between the application module and the kernel module can be realized, thereby achieving cross-platform compatibility of the engine.

[0092] In an optional embodiment of this specification, the kernel module includes an abstraction layer; configuring the kernel module may include the following steps:

[0093] Configure multiple application interfaces corresponding to the application module. Different application interfaces are used to call the platform layer code in the application module to implement different functions.

[0094] Encapsulate multiple application interfaces to obtain an abstraction layer and its corresponding abstract interface.

[0095] Specifically, an application interface can be understood as an interface used to call platform layer code in an application module.

[0096] In practical applications, since the specific implementation code for many functions is in each application module, the kernel module does not need to implement them. Therefore, an abstraction layer can be created to encapsulate platform-specific API calls to shield the differences between different platforms.

[0097] For example, modules such as file system, graphics rendering, input processing, and audio management can all be implemented through abstract interfaces.

[0098] By applying this embodiment, an abstraction layer is created to encapsulate the platform's API and obtain an abstract interface. The interface name can be the same for different platforms, thus shielding the differences between different platforms. With a small amount of platform layer code, the engine can seamlessly support the HarmonyOS NEXT platform, while also maintaining high compatibility and stability on other platforms.

[0099] In practical applications, once the target engine, its kernel module, and multiple application modules are obtained through development, the engine can be connected to various platforms.

[0100] According to one or more optional embodiments of this specification, receiving an access command sent by the target platform and deploying the kernel module of the target engine and the target application module on the target platform may include the following steps:

[0101] Receive the access command sent by the target platform, obtain the target application module corresponding to the target platform from multiple application modules of the target engine, and obtain the kernel module of the target engine;

[0102] Package the kernel module and the target application module to obtain the application package, and then deploy the application package on the target platform.

[0103] Specifically, the target platform is the HarmonyOS NEXT platform, and the access commands are the build commands of DevEco Studio. The target application module is the ArkTS platform layer, and the kernel module is the C++ engine module.

[0104] In practical applications, based on the build instructions of DevEco Studio, the ArkTS platform layer corresponding to the HarmonyOS NEXT platform can be obtained from multiple platform layers; the ArkTS platform layer code and the engine library files in the C++ engine module are packaged together to generate an application package, and the application is deployed to various devices that support the HarmonyOS NEXT platform.

[0105] By applying this embodiment, the target application module corresponding to the target platform and the kernel module of the target engine are obtained; the kernel module and the target application module are packaged to obtain an application package, and the application package is deployed on the target platform, which enables the engine to be connected to the platform, making it convenient to use the engine for project development on the platform in the future.

[0106] In practical applications, once engine access is completed, the engine startup process can be executed to start the target engine on the target platform.

[0107] According to one or more optional embodiments of this specification, after the target engine is accessed in the target platform, the application can be started and the UI components of the ArkTS application module can be loaded.

[0108] Furthermore, C++ functions exported from the C++ engine module are obtained through the Node-API interface, while some ArkTS system functions are provided to the C++ engine module, enabling cross-language interaction between the ArkTS platform layer and the C++ engine module.

[0109] Step 204: Create at least one application component by deploying the target application module on the target platform, wherein the application component is used to implement the engine function of the target engine on the target platform.

[0110] In practical applications, based on the cross-language interaction between the ArkTS platform layer and the C++ engine module achieved through the Node-API interface, at least one application component can be created by deploying the target application module on the target platform.

[0111] Specifically, application components may include platform-layer components such as rendering windows and file management.

[0112] According to one or more optional embodiments of this specification, creating at least one application component through a target application module deployed on a target platform may include the following steps:

[0113] By deploying target application modules on the target platform, and based on the various engine functions of the target engine, application components corresponding to each engine function are created.

[0114] Call the cross-language interaction interface to transfer the component instance of the application component to the kernel module.

[0115] Optionally, by deploying the target application module on the target platform, and based on the various engine functions of the target engine, application components corresponding to each engine function can be created, which may include:

[0116] Identify the various engine functions of the target engine;

[0117] Determine the corresponding development tools and libraries based on the type of component to be created and the engine functionality;

[0118] Based on development tools and libraries, write code to implement engine functions and define the corresponding interfaces for components.

[0119] In practical applications, when creating application components, the first step is to clearly define the type of component required by the target engine and the engine functions that the component will implement. Then, based on the component's type and functionality, appropriate development tools and libraries can be selected. Further steps include designing and implementing the component's interfaces and functions. Finally, component integration and debugging can be performed, and so on.

[0120] By applying this embodiment, by creating application components corresponding to the functions of each engine, and by calling the cross-language interaction interface to transfer the component instances of the application components to the kernel module, seamless access between the application platform and the kernel module can be achieved, enabling the target engine to be started on the target platform.

[0121] Step 206: Initialize application components and engine functions, and control the target platform to display the target engine's interface.

[0122] In practical applications, after creating application components corresponding to each engine function and calling cross-language interaction interfaces to transfer component instances of application components to the kernel module, application components and engine functions can be initialized, and the target platform can be controlled to display the engine interface of the target engine.

[0123] Specifically, the engine interface can be understood as the interface provided by the engine, which is different from the UI interface provided by the application module.

[0124] According to an optional embodiment of this specification, initializing application components and engine functions may include:

[0125] Determine the initialization resources, and initialize application components and engine functions based on the initialization resources.

[0126] Specifically, initialization resources can be understood as the relevant files and resources that need to be prepared in advance for engine initialization, which may include engine resource files and target platform library files.

[0127] In practical applications, the kernel module can include a file system. During engine initialization, the file system can be used to read and check the target platform runtime library installation status, set the platform resource path, and write the engine resource files and missing library files for the target platform into the platform's local environment. This completes the preparation of initialization resources.

[0128] According to another optional embodiment of this specification, initializing application components and engine functions may further include:

[0129] The thread scheduling module creates engine threads and operating system threads;

[0130] Manages data interaction between the kernel module and the target application module, and synchronizes the target platform runtime environment.

[0131] Optionally, the thread scheduling module is used to create and maintain engine threads and operating system threads during engine initialization.

[0132] In practical applications, initialization operations can be performed using engine threads once initialization resources have been prepared.

[0133] According to another optional embodiment of this specification, initializing application components and engine functions may further include:

[0134] The function methods in the kernel module are called to initialize application components and engine functions. These function methods are called through the cross-language interaction interface of the target application module.

[0135] Specifically, the functions and methods in the kernel module can be understood as C++ functions in the C++ engine module, or as the function interfaces exposed by the kernel module to various application modules.

[0136] Optionally, once the application components and engine functions have been initialized, the application interface can be switched from the native UI interface, i.e., the UI interface corresponding to the ArkTS platform layer, to the engine interface, and engine drawing and rendering can begin, thus completing the engine startup process.

[0137] In actual implementation, once the engine startup process is completed, it is equivalent to successfully starting the target engine on the target platform. At this point, project development can begin on the target platform based on the target engine.

[0138] It should be noted that products developed on the target platform based on the target engine are directly compatible with the target platform, and the product's applications can run on the target platform.

[0139] According to one or more optional embodiments of this specification, the engine interface includes project building controls; after controlling the target platform to display the engine interface of the target engine, the following steps may also be included:

[0140] In response to a trigger operation on the project build control, the build tool of the target platform is invoked based on the build script in the kernel module, and the target project is built in the development environment corresponding to the target platform.

[0141] Specifically, the build script can be a CMake script. CMake scripts can be used to manage the project build process on different platforms separately.

[0142] Alternatively, developers can write different CMake scripts for different platforms, and then integrate the CMake scripts for all platforms into a single project management file, which can be managed through macros, thereby enabling the management of the build process for different platforms based on a single CMake script.

[0143] This embodiment utilizes CMake scripts for project code management, enabling the generation of platform-specific projects using different development environments and build tools. For the HarmonyOS NEXT platform, the DevEco Studio-based project build process allows developers to quickly automate project builds with just the DevEco Studio development environment. Developers can generate target projects with a single click using the project build controls, freeing them to focus more on feature development and improving project efficiency.

[0144] In an optional embodiment of this specification, the application component includes a scene processing component; after controlling the target platform to display the engine interface of the target engine, the following steps may also be included:

[0145] Receive real images captured by the target device in a real environment;

[0146] It identifies real objects in real images and adds virtual scene information to the real objects through a scene processing component.

[0147] Specifically, scene processing components can be understood as components created based on scene systems or APIs encapsulated in OpenXR. Scene processing components can be used to implement AR or VR functions.

[0148] In one optional embodiment of this specification, a unified standard is designed, including APIs based on OpenXR, cameras and scene systems for various platforms, and applicable to mixed reality systems based on AR and VR.

[0149] Specifically, OpenXR is a third-party library that provides a unified set of development interfaces, making it easier for application developers to create applications suitable for different VR / AR devices. The OpenXR standard was developed by the Khronos Group to standardize the specifications between devices and applications on VR / AR platforms.

[0150] For example, many devices such as SteamVR, Oculus, HoloLens, and Pico support this standard.

[0151] In practical applications, mixed reality systems can use cameras from different devices to capture images of the real environment, identify objects in the real environment from the images, and overlay virtual scene information onto the images. With the help of virtual scenes, the engine can integrate virtual information into the real scene, including adding 3D models to the real environment, performing lighting calculations, and generating virtual shadows, thereby creating a highly realistic and interactive mixed reality environment.

[0152] This embodiment utilizes a mixed reality system to add virtual scene information to images, enabling AR and VR display output and interaction. Furthermore, based on the OpenXR open standard, it is compatible with input control from various VR and AR device controllers and grippers to meet diverse interaction needs. In addition to mainstream VR and AR devices such as Oculus and HoloLens, it also supports more domestically produced virtual reality devices like Pico, which is beneficial to the development of the domestic virtual reality device and software ecosystem.

[0153] In one or more optional embodiments of this specification, the supporting tools for the developed engine also include scene editors, model editors, video editors, and design editors. These editing tools are integrated into the kernel module and support multi-platform development, including but not limited to Windows, macOS, HarmonyOS NEXT, and other mainstream mobile platforms.

[0154] When using the engine's accompanying tools, developers can focus on content creation without worrying about platform differences, easily and quickly producing realistic characters, scenes, animations, and other content. The tools enable product output across multiple platforms and devices, enriching the diversity of deliverables. The editing tools support multi-platform development, allowing developed products to quickly adapt to different operating environments and meet broader market demands. Developers can complete product development within the same editing tool suite and then deploy it to multiple platforms, eliminating the need for separate development for each platform and significantly improving development efficiency and convenience.

[0155] Since the creation of engine resources needs to take into account the compatibility of resources with all target platforms of the engine, in one or more optional embodiments of this specification, the engine resources can be set to a cross-platform unified format or the optimal format for each platform, based on performance and metrics.

[0156] For some high-precision model resources used in the engine, the load is too high in the mobile environment, so they cannot be used directly in mobile applications. For these high-precision models that exceed the performance limit, automated tools can be used to generate or convert them into resources suitable for mobile devices. For example, the model can be used to generate LOD resources, limit the texture accuracy, and simplify materials to ensure that the model resources can also perform well on mobile devices.

[0157] According to one or more optional embodiments of this specification, the target application module includes a target debugger; the engine processing method may further include the following steps:

[0158] Monitor the data generated by the target platform running the target product, where the target product is a product developed based on the target platform and through the target engine;

[0159] Based on the target debugger and the data information, the target product is tested.

[0160] Specifically, a target debugger can be understood as a debugger provided by the target application module, used to achieve cross-platform debugging for the target platform.

[0161] In practical applications, testing can mainly include performance testing and compatibility testing.

[0162] This specification also establishes a comprehensive cross-platform debugging strategy, and develops a real-time debugging system and a multi-platform performance diagnostic and data collection system. In the real-time debugging system, different debuggers are selected for different platforms (e.g., MSDB is used for Windows, and LLDB is used for Android and HarmonyOS NEXT platforms), with each debugger provided by its corresponding platform layer.

[0163] By using this embodiment, a multi-platform performance diagnostic and data collection system can be used to cover various hardware and operating system combinations, enabling automated testing of multiple devices and operating systems. By collecting various performance data, it ensures that the game application can run stably on different devices and operating systems, and promptly detects performance bottlenecks and platform compatibility issues.

[0164] According to an optional embodiment of this specification, the engine processing method may further include:

[0165] During runtime, the system detects the target platform's operating system data, device hardware parameters, and target platform driver capabilities.

[0166] The engine settings are adaptively adjusted based on the test results.

[0167] In practical applications, the target engine can detect the target platform's operating system data, device hardware parameters, and target platform driver capabilities at runtime, and adaptively adjust engine settings based on the detection results.

[0168] By applying this embodiment, by detecting the operating system data, device hardware parameters, and target platform driver capabilities of the target platform, the engine can automatically adjust its operating parameters based on the detection results at runtime on different target platforms, thereby enabling functions available on the target platform or disabling functions not supported by the target platform, further improving engine performance.

[0169] According to an optional embodiment of this specification, the engine processing method may further include:

[0170] Register system events and notification callbacks for the target platform.

[0171] Optionally, system events and notification callbacks for the target platform can be registered based on the differences in the lifecycle of different platforms, thereby adapting to the system functions of the target platform in a targeted manner.

[0172] Specifically, the system functions of the target platform may include system services such as input, graphics, and networking.

[0173] By applying this embodiment, by registering system events and notification callbacks of the target platform, the system functions of the target platform can be adapted in a targeted manner, further improving the engine's compatibility with different platforms, ensuring that the application can run smoothly on the target platform, and realizing the various functions provided by the engine.

[0174] This specification provides an engine processing method that receives an access command sent by a target platform, deploys the kernel module and target application module of the target engine on the target platform, wherein the target application module is the application module corresponding to the target platform among multiple application modules of the target engine; creates at least one application component through the target application module deployed on the target platform, wherein the application component is used to implement the engine function of the target engine on the target platform; initializes the application component and engine function, and controls the target platform to display the engine interface of the target engine.

[0175] Thus, by receiving the access command sent by the target platform, the kernel module and application module of the target engine are deployed on the target platform, enabling the target engine to access the target platform and provide support for it. By deploying the application module on the target platform, at least one application component is created, allowing the target engine to be started after access is completed. By initializing the application component and engine functions, the target platform is controlled to display the engine interface of the target engine, thereby initializing the engine and completing the startup process of the target engine on the target platform. This allows project development based on the target engine to be carried out in the development environment provided by the target platform, and the developed product can run stably on the target platform with good platform compatibility.

[0176] It should be noted that the engine processing method provided in the embodiments of this specification is the first to support adaptation to the HarmonyOSNEXT operating system and has better compatibility with mobile devices from various manufacturers. In addition to mobile devices running HarmonyOSNEXT, this method also sets targeted optimization and compatibility strategies for differences in CPU and software versions of different devices. This method aims to leverage the specifications of various system platforms to achieve input support for various wired, Bluetooth keyboards and gamepads, including most peripheral models, increasing user interaction methods, enriching game mechanics, reducing the operational complexity of mobile devices, and improving the software product's running experience on the machine.

[0177] Meanwhile, based on the OpenXR open standard, it is compatible with input control from different VR and AR device controllers and grips to meet various interaction methods. In addition to mainstream VR and AR devices such as Oculus and HoloLens, it supports more domestic virtual reality devices like Pico, which is beneficial to the development of the domestic virtual reality device and software ecosystem.

[0178] See Figure 3 , Figure 3 This document illustrates an engine architecture diagram of a self-developed engine according to an embodiment of this specification. Specifically, the self-developed engine comprises two main components: an application layer and an engine layer. The application layer includes multiple platform layers, each containing corresponding platform layer code and a debugger. The engine layer includes a C++ engine module, which comprises various components such as a graphics rendering layer, an input management layer, an abstraction layer, engine resources, a file system, a thread scheduling module, an engine editing tool, a project management module, a mixed reality module, a resource production module, and a resource management module. Each platform layer achieves cross-language interaction with the C++ engine module through a corresponding cross-language interaction interface.

[0179] The self-developed engine provided in this embodiment can access multiple platforms, including HarmonyOS NEXT, realizing cross-platform engine access technology. It not only supports existing platforms such as Windows, Android, and iOS, but also pioneers full support for the HarmonyOS NEXT platform. The self-developed engine has built a platform-specific project and compilation environment for HarmonyOS NEXT, developed related automated tools, and refactored all platform-independent code. By developing an abstract platform layer and a flexible rendering pipeline, products developed based on the engine can run on the HarmonyOS NEXT platform. By providing support for the emerging HarmonyOS NEXT platform, the self-developed engine can better meet the usage needs of domestic users for HarmonyOS devices and applications.

[0180] The self-developed engine provided in this embodiment also includes a cross-platform resource production pipeline and a flexible and efficient cross-platform unified resource management system. The cross-platform resource production pipeline, by defining resource specifications for each platform, packages and integrates different types of resource files (textures, audio, models, etc.) into a custom resource format and file index, and develops automated resource conversion tools, enabling unified format resource files to be previewed on multiple platforms within the editor. This allows artists to focus on creating and maintaining individual versions of resources, significantly reducing the manpower and time costs of resource production.

[0181] A cross-platform unified resource management system can be divided into a resource packaging end and a resource loading end. Packaging game resources (such as textures, audio, and models) into a unified format not only reduces the size of resource files but also improves loading and search efficiency, facilitating management and loading. It also enables data compression and decompression, reducing product package size and resource update size. In addition to packaging resources, the resource management system also features resource push functionality, supporting hot updates and pushing new resource changes to clients on any platform, including HarmonyOS NEXT. This system can not only update or clean up local resources based on version information, making it convenient for users to update product content, but it can also predict resources that users may need in real time during application runtime and load them in advance. Even if server-side resources change frequently, the client can update resources promptly, ensuring users always experience the latest resources.

[0182] Figure 4 A structural block diagram of a computing device 400 according to one embodiment of this specification is shown. The components of the computing device 400 include, but are not limited to, a memory 410 and a processor 420. The processor 420 is connected to the memory 410 via a bus 430, and a database 450 is used to store data.

[0183] The computing device 400 also includes an access device 440, which enables the computing device 400 to communicate via one or more networks 460. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 440 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0184] In one embodiment of this specification, the aforementioned components of the computing device 400 and Figure 4 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 4 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0185] The computing device 400 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 400 can also be a mobile or stationary server.

[0186] The processor 420 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the engine processing method described above.

[0187] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the engine processing method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the engine processing method described above.

[0188] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the engine processing method described above.

[0189] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the engine processing method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the engine processing method described above.

[0190] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the engine processing method described above.

[0191] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the engine processing method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the engine processing method described above.

[0192] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0193] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0194] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0195] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0196] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. An engine processing method, characterized in that, include: Receive the access command sent by the target platform, and deploy the kernel module of the target engine and the target application module on the target platform, wherein the target application module is the application module corresponding to the target platform among the multiple application modules of the target engine; By deploying a target application module on the target platform, at least one application component is created, wherein the application component is used to implement the engine function of the target engine on the target platform. The method of creating at least one application component includes: based on the engine function of the target engine, creating application components corresponding to each engine function respectively; calling a cross-language interaction interface; and transmitting the component instance of the application component to the kernel module. The cross-language interaction interface is used to realize cross-language interaction between the kernel module and the target application module. Initialize the application components and engine functions, and control the target platform to display the engine interface of the target engine; The configuration of the kernel module includes: configuring multiple application interfaces corresponding to the target application module, wherein different application interfaces are used to call platform layer code in the target application module to implement different functions, encapsulating multiple application interfaces to obtain an abstraction layer and corresponding abstract interfaces, wherein the abstraction layer is used to shield the differences between different platforms.

2. The method according to claim 1, characterized in that, Before receiving the access command sent by the target platform, the method further includes: Configure the kernel module and the multiple application modules, wherein the kernel module is configured based on a unified coding standard and is used to implement the general logic of the target engine.

3. The method according to claim 2, characterized in that, The kernel module includes a graphics rendering layer; The configuration of the kernel module includes: Configure the corresponding graphical interface for each platform for multiple platforms; The graphics interfaces corresponding to each platform are encapsulated to obtain the target graphics interface corresponding to the graphics rendering layer.

4. The method according to claim 2, characterized in that, The kernel module includes an input management layer; The configuration of the kernel module includes: Configure the target input interface corresponding to the input management layer, wherein the target input interface is used to receive input signals from various types of devices, and convert the input signals into target processing instructions corresponding to the target device type based on the target device type of the input signals.

5. The method according to claim 2, characterized in that, The configuration of the plurality of application modules includes: Obtain the platform-level code written in the system language corresponding to each platform and the resources configured for each platform; The first platform layer code and the first resource are encapsulated into the first application module, wherein the first application module is the application module corresponding to the first platform, the first platform is any one of the platforms, the first platform layer code is code written based on the system language corresponding to the first platform, and the first resource is a resource configured for the first platform.

6. The method according to claim 5, characterized in that, After encapsulating the first platform layer code and the first resource into the first application module, the method further includes: According to the operating system adapted to the first application module, configure the cross-language interaction interface corresponding to the first application module, wherein the cross-language interaction interface is used to realize cross-language interaction between the first application module and the kernel module.

7. The method according to claim 1, characterized in that, The step of receiving the access command sent by the target platform and deploying the kernel module of the target engine and the target application module on the target platform includes: Receive the access command sent by the target platform, obtain the target application module corresponding to the target platform from multiple application modules of the target engine, and obtain the kernel module of the target engine; The kernel module and the target application module are packaged to obtain an application package, and the application package is deployed on the target platform.

8. The method according to claim 1, characterized in that, The creation of at least one application component through the target application module deployed on the target platform includes: By deploying the target application module on the target platform, application components corresponding to each engine function are created based on the multiple engine functions of the target engine; The cross-language interaction interface is invoked to transfer the component instance of the application component to the kernel module.

9. The method according to claim 1, characterized in that, The engine interface includes project building controls; After controlling the target platform to display the engine interface of the target engine, the method further includes: In response to a trigger operation on the project build control, the build tool of the target platform is invoked based on the build script in the kernel module to build the target project in the development environment corresponding to the target platform.

10. The method according to claim 9, characterized in that, The application components include scene processing components; After controlling the target platform to display the engine interface of the target engine, the method further includes: Receive real images captured by the target device in a real environment; Identify real objects in the real image, and add virtual scene information to the real objects through the scene processing component.

11. The method according to claim 1, characterized in that, The target application module includes a target debugger; The method further includes: Monitor the data information generated by the target platform running the target product, wherein the target product is a product developed based on the target platform and through the target engine; Based on the target debugger, the target product is tested according to the data information.

12. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the engine processing method according to any one of claims 1 to 11.

13. A computer-readable storage medium, characterized in that, It stores a computer program / instruction that, when executed by a processor, implements the steps of the engine processing method according to any one of claims 1 to 11.

14. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, implements the steps of the engine processing method according to any one of claims 1 to 11.

Images