A method for rendering a large map static decoration in a game and a computer readable storage medium
By extracting prefab information of static decorations on the large map during the offline phase and serializing it into a pre-rendered data file, combined with multi-threading and object pool management, the rendering process is optimized, solving the problem of low rendering efficiency of large maps in existing technologies and achieving efficient rendering results.
Patent Information
- Application Number
- CN202611251725.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-18
- Publication Date
- 2026-11-06
AI Technical Summary
Existing technologies cause excessive consumption of hardware resources and long rendering times when rendering a large number of static decorations in a large map, and the conventional dynamic batch processing mechanism fails, resulting in game screen stuttering.
By acquiring prefabs of static decorations offline, extracting transformation matrices and texture region information, serializing them into pre-rendered data files, initializing contiguous arrays in memory, dynamically updating the rendering working set, and using scene-shared base meshes and materials for batch instantiation rendering, the rendering process is optimized by combining multi-threading and object pool management.
It effectively reduces the number of drawing calls, reduces data transmission bandwidth, improves material sampling efficiency, ensures stable frame rate under high load scenarios, avoids process pauses caused by frequent memory allocation and destruction, and improves rendering efficiency.
Smart Images

Figure CN123052159A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of online games, and more particularly to a method for rendering static decorations on a large map in a game and a computer-readable storage medium. Background Technology
[0002] In 2D strategy games and other video games with large world maps, a vast number of static decorations, such as vegetation, terrain features, and buildings, are typically distributed across the map to create a realistic and rich virtual environment. These expansive maps with numerous elements are known as large maps. These static decorations form the basic visual presentation of the game world, and their rendering efficiency directly affects the overall visual presentation and player experience.
[0003] Existing rendering solutions often generate independent draw calls for each rendering component when handling a large number of decorations, leading to significant overhead for the graphics processor during state transitions. Furthermore, independently maintaining the component properties and hierarchy transformations of numerous objects at runtime consumes substantial CPU computing resources and results in high memory usage. Additionally, conventional dynamic batching mechanisms often fail when decorations in a scene use different atlases or materials, preventing the system from effectively merging rendering batches.
[0004] In summary, existing rendering technologies generally suffer from drawbacks such as excessive consumption of hardware and software resources and long rendering times when dealing with massive amounts of decorations on large maps, which can easily cause game stuttering. Therefore, the industry urgently needs a new rendering solution to overcome the performance bottleneck caused by massive static objects. Summary of the Invention
[0005] In order to overcome the above-mentioned technical defects, the purpose of this invention is to provide a method for rendering static decorations on a large map in a game and a computer-readable storage medium.
[0006] This invention discloses a method for rendering static decorations on a large map in a game. The rendering method includes: Obtain the prefab of static decorations in the scene, extract the key parameters for instantiation rendering from them; the key parameters include the transformation matrix and texture region information; and serialize the key parameters into a pre-rendered data file. Load the pre-rendered data file and initialize the rendering workset in memory based on key parameters. The rendering workset contains a contiguous array for storing rendering parameters, including a transformation matrix array and a texture array. Get the display status of static decorations in the current field of view, and dynamically update the rendering work set according to the display status, so that the rendering parameters corresponding to the static decorations in the display state are arranged continuously in the continuous array; The rendering parameters arranged in a continuous sequence are submitted in batches to the graphics rendering interface. Using the basic mesh and materials shared by the scene, the static decorations within the field of view are instantiated and rendered.
[0007] Preferably, the transformation matrix is a 4×4 transformation matrix; the texture region information is represented as a four-dimensional vector consisting of four components; the rendering method further includes: The four-dimensional vector encoding of texture region information is written into the homogeneous coordinate row of the 4×4 transformation matrix so that the 4×4 transformation matrix can simultaneously carry spatial transformation data and texture mapping data. The homogeneous coordinates are the fourth row of the 4×4 transformation matrix. Preferably, the pre-rendered data file also includes an atlas page index; The rendering workset is submitted in batches to the graphics processor for rendering by instantiating the rendering interface, including: Bind an atlas of multiple merged texture maps to a graphics processor; The graphics processor's shader determines the target texture map in the atlas resources using a branchless selection function based on the atlas page index corresponding to the current rendering instance; Pixel sampling is performed on the target texture map by combining the texture region information extracted from the homogeneous coordinate rows of the 4×4 transformation matrix.
[0008] Preferably, the rendering working set is dynamically updated according to the display state, so that the rendering parameters corresponding to the static decorations in the display state are arranged continuously in a continuous array, including: An active statistic is set and maintained for the continuous array. The active statistic is used to indicate the number of static decorations that are currently in the display state, and the interval from the starting position to the corresponding position of the active statistic in the continuous array is the active data segment. When the display state of any static decoration is switched from visible to hidden, the rendering parameters corresponding to the static decoration in the continuous array are swapped with the rendering parameters at the end of the active data segment, and the active statistics are decremented. When the display state of any static decoration changes from hidden to visible, the rendering parameters corresponding to the static decoration are swapped with the rendering parameters of the next position after the end of the active data segment, and the active statistics are incremented.
[0009] Preferably, when the rendering method is applied to a multi-threaded device, initializing the rendering working set in memory includes: Initialize the first rendering workset, the second rendering workset, and the command queue in memory; The rendering working set is dynamically updated based on the display status, including: The main thread reads the first rendering work set and, in response to changes in the display state of static decorations, generates corresponding operation instructions and stores them in the command queue. The secondary thread reads the command queue and performs data processing on the second rendering workset according to the operation instructions; When the current frame finishes rendering, the main thread swaps the pointers of the first rendering working set and the second rendering working set so that the updated second rendering working set can be read by the main thread in the next frame.
[0010] Preferably, the secondary thread performs data processing on the second rendering working set in the background according to operation instructions, including: Count the cumulative changes corresponding to operation instructions in the command queue; When the cumulative amount of changes reaches the preset threshold, the sub-thread extracts the vertical coordinate components of the transformation matrix corresponding to each static decoration in the second rendering work set. Using the vertical coordinate components as the basis for depth sorting, the rendering parameters in the second rendering working set are subjected to insertion sort.
[0011] Preferably, the rendering method further includes: Divide the large map into multiple grids and register static decorations to the corresponding grids according to their location coordinates and depth levels; Calculate the set of target tiles that are currently active based on the map area covered by the current rendering camera; In response to changes in the active state of a tile, the display status of static decorations within the target tile set is switched to "show" in batches, and the display status of static decorations that leave the target tile set is switched to "hide" in batches.
[0012] Preferably, the rendering method further includes: Pre-build an object pool in memory corresponding to the static decorator type; When any static decoration in the display state moves away from the rendering camera and the distance reaches a preset recycling threshold, the contiguous array carrying the rendering parameters is returned to the object pool. When a new static decoration of the same type is added and enters the display state, a free contiguous array is extracted from the object pool.
[0013] Preferably, the steps of obtaining a prefab of a static decoration in the scene, extracting key parameters for instantiation rendering from it, and serializing the key parameters into a pre-rendered data file are implemented when computing power is idle or offline. Other steps in the rendering method are performed online.
[0014] The second aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the rendering method for static decorations on a large map in a 2D game according to any of the preceding claims.
[0015] Compared with existing technologies, the above technical solution has the following advantages: 1. The rendering method for static decorations on large maps in 2D games provided in this application obtains prefabs of static decorations in the scene during the offline stage, extracts key parameters containing transformation matrices and texture region information, and serializes them into pre-rendered data files, avoiding the resource parsing overhead during online runtime. When initializing the rendering working set in memory, a contiguous array containing transformation matrix arrays and texture arrays is constructed, and the rendering working set is dynamically updated according to the obtained display status of static decorations in the current field of view, so that the rendering parameters corresponding to the static decorations in the display state are continuously arranged in the contiguous array. This continuously arranged data structure can directly meet the data reading specifications of the underlying graphics application interface, thereby submitting the continuously arranged rendering parameters in batches to the graphics rendering interface, and performing instantiation rendering using the scene-shared basic mesh and materials. This method effectively avoids the state switching overhead caused by massive independent objects in the rendering of existing technologies, and significantly reduces the number of drawing calls; 2. This application writes the vector encoding of texture region information into the homogeneous coordinate row of the transformation matrix. By reusing this homogeneous coordinate row, a single transformation matrix can simultaneously carry spatial transformation data and texture mapping data, effectively reducing the data bandwidth transmitted to the graphics processor. Simultaneously, the atlas page index contained in the pre-rendered data file enables the rendering pipeline to support multiple atlases. The graphics processor's shader uses a branchless selection function to determine the target texture map, avoiding instruction pauses caused by conditional branching statements in existing technologies and improving the execution efficiency of material sampling. To maintain the compactness of the continuous array, the system maintains an active statistic indicating the number of display states. When the display state of a static decoration changes, its rendering parameters are swapped with the rendering parameters at the end of the active data segment. This swapping strategy keeps the time complexity of state updates at a constant level, ensuring the execution stability of large-scale decoration state switching. 3. In multi-threaded devices, this application achieves physical isolation of read and write operations by initializing a first rendering working set, a second rendering working set, and a command queue in memory. The main thread focuses on reading the first working set for rendering and committing it, and stores the operation instructions generated by state changes into the command queue; the secondary thread performs data processing on the second working set in the background according to the operation instructions, and the main thread swaps the pointers of the two working sets at the end of the current frame rendering, thereby eliminating lock contention overhead and ensuring stable frame rate in high-load scenarios. In addition, to ensure the correct occlusion relationship of semi-transparent objects, the secondary thread counts the cumulative changes in the background, and extracts the vertical coordinate components of the transformation matrix as the basis for depth sorting when a preset threshold is reached, and performs insertion sort on the second working set. This delayed-triggered sorting mechanism utilizes the near-ordered nature of data between consecutive frames, restores data order with extremely low comparison and swapping costs, and significantly reduces the computational load of full sorting; 4. Finally, regarding scene visibility management and memory scheduling, this application divides the large map into multiple grids and registers static decorations to corresponding grids according to their location and depth. The system calculates the set of active target grids based on the area covered by the current rendering camera and responds to changes in grid status by batch switching the display and hiding states of decorations, effectively controlling the upper limit of computational complexity for frustum culling in complex scenes. Combined with a pre-built object pool in memory, when a decoration moves far from the camera and reaches a recycling threshold, its contiguous array is returned to the cache. When a new decoration is added for display, a free contiguous array is directly extracted, achieving contiguous array-level recycling and avoiding process pauses caused by frequent memory allocation and destruction. The above methods are further encapsulated into program instructions on a computer-readable storage medium, possessing cross-hardware platform compatibility and providing physical carrier support for the practical engineering implementation and software distribution of the rendering solution. Attached Figure Description
[0016] Figure 1 A flowchart illustrating the rendering method for static decorations on a large map in a 2D game provided in this application. Detailed Implementation
[0017] The advantages of the present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments.
[0018] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.
[0019] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure 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 herein refers to and includes any and all possible combinations of one or more of the associated listed items.
[0020] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."
[0021] In the description of this invention, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.
[0022] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two components. They can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.
[0023] In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the convenience of the description of the invention and have no specific meaning in themselves. Therefore, "module" and "part" can be used interchangeably.
[0024] Please see Figure 1 , Figure 1 A flowchart illustrating the rendering method for static decorations on a large map in a 2D game provided in this application.
[0025] like Figure 1 As shown, this invention discloses a method for rendering static decorations on a large map in a game. The rendering method includes: Obtain the prefab of static decorations in the scene, extract the key parameters for instantiation rendering from them; the key parameters include the transformation matrix and texture region information; and serialize the key parameters into a pre-rendered data file. Load the pre-rendered data file and initialize the rendering workset in memory based on key parameters. The rendering workset contains a contiguous array for storing rendering parameters, including a transformation matrix array and a texture array. Get the display status of static decorations in the current field of view, and dynamically update the rendering work set according to the display status, so that the rendering parameters corresponding to the static decorations in the display state are arranged continuously in the continuous array; The rendering parameters arranged in a continuous sequence are submitted in batches to the graphics rendering interface. Using the basic mesh and materials shared by the scene, the static decorations within the field of view are instantiated and rendered.
[0026] This can be understood as follows: The rendering method for static decorations on large maps provided in this application obtains prefabs of static decorations in the scene offline, extracts key parameters containing transformation matrices and texture region information, and serializes them into pre-rendered data files, avoiding the resource parsing overhead during online runtime. When initializing the rendering working set in memory, a contiguous array containing transformation matrix arrays and texture arrays is constructed, and the rendering working set is dynamically updated according to the display status of static decorations in the current field of view (or, as can be understood, the current field of view when the client is running the game), so that the rendering parameters corresponding to the static decorations in the display state are continuously arranged in the contiguous array. This continuously arranged data structure can directly meet the data reading specifications of the underlying graphics application interface, thereby submitting the continuously arranged rendering parameters in batches to the graphics rendering interface, and performing instantiation rendering using the scene-shared basic mesh and materials. This method effectively avoids the state switching overhead caused by massive independent objects in the rendering of existing technologies, and significantly reduces the number of drawing calls. In actual tests, tens of thousands of instances can be compressed to 10-20 DrawCalls, thereby reducing DrawCalls to an extremely low level.
[0027] The above is an explanation of the basic concept provided in this application. The specific methods for each step will be explained in detail below.
[0028] First, there are no restrictions on the specific implementation method of the key parameters.
[0029] In one possible implementation, the transformation matrix is a 4×4 transformation matrix; the texture region information is represented as a four-dimensional vector consisting of four components; the rendering method also includes: The four-dimensional vector encoding of texture region information is written into the homogeneous coordinate row of the 4×4 transformation matrix so that the 4×4 transformation matrix can simultaneously carry spatial transformation data and texture mapping data. The homogeneous coordinates are the fourth row of the 4×4 transformation matrix.
[0030] It should be noted here that, for example, the 4th row (m30, m31, m32, m33) of a standard local to world matrix is always [0, 0, 0, 1]. This row is the homogeneous coordinate row / projection row, and it does not carry any transformation information for ordinary translation, rotation, and scaling transformations: Scaling and rotation are the direction vectors in the first 3 rows and 3 columns (columns 0 / 1 / 2). The translation (position) is in column 3 (m03,m13,m23).
[0031] Therefore, the last line does not actually contain any information and is always [0,0,0,1] in the data structure, so it will occupy 4 floats.
[0032] Therefore, this application specifically sets the sprite's outline texture in the 4th row of the 4×4 transformation matrix. This combines the four-dimensional vector encoding of the transformation matrix and texture region information into a single 4×4 transformation matrix. During client-side rendering, it is only necessary to retrieve the texture from the 4th row, treat the last row as [0,0,0,1], and restore it to a normal affine matrix for use.
[0033] By reusing this homogeneous coordinate row, a single 4×4 transformation matrix can simultaneously carry spatial transformation data and texture mapping data, completing the transfer of all required rendering parameters without increasing additional video memory usage. This data structure reuse effectively reduces the data bandwidth transmitted from the central processing unit to the graphics processing unit, improving overall data throughput efficiency.
[0034] The above explains the specific implementation of the transformation matrix. It is understandable that the pre-rendered data file may include more parts to achieve additional functionality.
[0035] For example, in one possible implementation, the pre-rendered data file also includes an atlas page index; The rendering workset is submitted in batches to the graphics processor for rendering by instantiating the rendering interface, including: Bind an atlas of multiple merged texture maps to a graphics processor; The graphics processor's shader determines the target texture map in the atlas resources using a branchless selection function based on the atlas page index corresponding to the current rendering instance; Pixel sampling is performed on the target texture map by combining the texture region information extracted from the homogeneous coordinate rows of the 4×4 transformation matrix.
[0036] The pre-rendered data file contains atlas page indexes, enabling the rendering pipeline to support multiple atlases to overcome the size limitations of single texture maps. During instantiation rendering, after binding the atlas resource, composed of multiple merged texture maps, to the graphics processor, the graphics processor's shader directly determines the target texture map from the atlas resource using a branchless selection function based on the atlas page index corresponding to the current rendering instance. The branchless selection function avoids the instruction pauses and parallel computation interruptions caused by conditional branching statements in the graphics processor in existing technologies. Combined with the texture region information extracted from the homogeneous coordinate rows of the 4×4 transformation matrix, pixel sampling is performed on the target texture map, ensuring full-load operation of the graphics processor's internal shader cores and improving the execution efficiency of material sampling.
[0037] Secondly, there are no restrictions on the specific implementation method of dynamically updating the rendering working set based on the display status.
[0038] In one possible implementation, the rendering working set is dynamically updated based on the display state, ensuring that the rendering parameters corresponding to static decorations in the display state are arranged continuously in a contiguous array, including: An active statistic is set and maintained for the continuous array. The active statistic is used to indicate the number of static decorations that are currently in the display state, and the interval from the starting position to the corresponding position of the active statistic in the continuous array is the active data segment. When the display state of any static decoration is switched from visible to hidden, the rendering parameters corresponding to the static decoration in the continuous array are swapped with the rendering parameters at the end of the active data segment, and the active statistics are decremented. When the display state of any static decoration changes from hidden to visible, the rendering parameters corresponding to the static decoration are swapped with the rendering parameters of the next position after the end of the active data segment, and the active statistics are incremented.
[0039] The contiguous array needs to maintain a compact and valid data structure to support batch rendering calls. By setting and maintaining an activity statistic for the contiguous array to indicate the number of static decorations currently in the display state, the interval from the start position to the corresponding position of the activity statistic in the contiguous array is defined as the active data segment. When the display state of a static decoration changes from visible to hidden, the rendering parameters corresponding to that static decoration in the contiguous array are directly swapped with the rendering parameters at the end of the active data segment, and the activity statistic is decremented; the same swapping and incrementing occurs when the state changes from hidden to visible. This swapping strategy keeps the time complexity of a single state update at a constant level, avoids full array copying or memory reallocation, and ensures the stability of large-scale decoration state switching during rapid view movement.
[0040] Furthermore, this application also provides an optimization solution for the current situation where devices often have multiple cores and multiple threads.
[0041] In one possible implementation, when the rendering method is applied to a multi-threaded device, the rendering working set is initialized in memory, including: Initialize the first rendering workset, the second rendering workset, and the command queue in memory; The rendering working set is dynamically updated based on the display status, including: The main thread reads the first rendering work set and, in response to changes in the display state of static decorations, generates corresponding operation instructions and stores them in the command queue. The secondary thread reads the command queue and performs data processing on the second rendering workset according to the operation instructions; When the current frame finishes rendering, the main thread swaps the pointers of the first rendering working set and the second rendering working set so that the updated second rendering working set can be read by the main thread in the next frame.
[0042] This can be understood as follows: When applied to multi-threaded devices, a first rendering working set, a second rendering working set, and a command queue are initialized in memory. The main thread focuses on reading the first rendering working set, submitting it for rendering, and storing operation instructions generated in response to changes in the display state of static decorations into the command queue. Meanwhile, secondary threads read the command queue in the background and perform data processing on the second rendering working set according to the operation instructions. At the end of the current frame's rendering, the main thread swaps the pointers of the first and second rendering working sets. This mechanism achieves physical isolation between read and write operations, ensuring that the main thread's rendering instruction submission process is not blocked by background data update operations, eliminating lock contention overhead in a multi-threaded environment, and guaranteeing stable frame rates during high-load scenarios.
[0043] Furthermore, in one possible implementation, the secondary thread performs data processing on the second rendering working set in the background according to operation instructions, including: Count the cumulative changes corresponding to operation instructions in the command queue; When the cumulative amount of changes reaches the preset threshold, the sub-thread extracts the vertical coordinate components of the transformation matrix corresponding to each static decoration in the second rendering work set. Using the vertical coordinate components as the basis for depth sorting, the rendering parameters in the second rendering working set are subjected to insertion sort.
[0044] Transparent or semi-transparent static decorations must be rendered in a strict from-far to-near order to ensure correct occlusion relationships. A secondary thread in the background counts the cumulative changes corresponding to operation commands in the command queue. When the cumulative changes reach a preset threshold, it extracts the vertical coordinate components of the transformation matrices corresponding to each static decoration in the second rendering workset. Using the vertical coordinate components as the basis for depth sorting, insertion sort is performed on the rendering parameters within the second rendering workset. Since only a small number of static decorations undergo state changes between consecutive frames in real-world scenarios, the overall data is nearly ordered. Delayed-triggered insertion sort can restore the complete order of the data with extremely low comparison and swapping costs, significantly reducing the computational load of conventional full-scale sorting algorithms.
[0045] Finally, the rendering method provided in this application may include more steps and implement more functions, and this application makes no restrictions on these steps.
[0046] For example, in one possible implementation, the rendering method further includes: Divide the large map into multiple grids and register static decorations to the corresponding grids according to their location coordinates and depth levels; Calculate the set of target tiles that are currently active based on the map area covered by the current rendering camera; In response to changes in the active state of a tile, the display status of static decorations within the target tile set is switched to "show" in batches, and the display status of static decorations that leave the target tile set is switched to "hide" in batches.
[0047] The large map is divided into multiple grids, and static decorations are registered to the corresponding grids according to their location coordinates and depth level. At runtime, the set of currently active target grids is calculated based on the map area covered by the current rendering camera. Instead of performing independent frustum intersection tests for individual static decorations, the system responds to changes in grid activity by batch switching the display status of static decorations within the target grid set to visible and batch switching the display status of static decorations leaving the target grid set to hidden. This grid-based batch management strictly limits the scale of visibility culling calculations to the number of grids, effectively controlling the upper limit of computational load in complex scenes.
[0048] In another possible implementation, the rendering method also includes: Pre-build an object pool in memory corresponding to the static decorator type; When any static decoration in the display state moves away from the rendering camera and the distance reaches a preset recycling threshold, the contiguous array carrying the rendering parameters is returned to the object pool. When a new static decoration of the same type is added and enters the display state, a free contiguous array is extracted from the object pool.
[0049] An object pool corresponding to the static decorator type is pre-built in memory. When a static decorator in the display state moves away from the rendering camera and the distance reaches a preset recycling threshold, the contiguous array carrying the rendering parameters is returned to the object pool for caching. When a new static decorator of the same type enters the display state, a free contiguous array is directly retrieved from the object pool. This object pool-based memory scheduling strategy achieves contiguous array-level recycling, avoiding frequent instantiation, allocation, and destruction operations in the heap memory. This effectively eliminates process pauses caused by garbage collection during runtime and ensures long-term stable memory usage.
[0050] The above is a complete description of the rendering method for static decorations on large maps in 2D games provided in this application.
[0051] It should be noted that the specific implementation time for each step of the above rendering method is also unlimited.
[0052] In one possible implementation, the steps of obtaining a prefab of a static decoration in the scene, extracting key parameters for instantiation rendering from it, and serializing the key parameters into a pre-rendered data file are implemented when computing power is idle or offline. Other steps in the rendering method are performed online.
[0053] The steps of acquiring prefabs of static decorations in the scene, extracting key parameters for instantiation rendering, and serializing them into pre-rendered data files are performed before computing power is available or offline. This strategy decouples the time-consuming and non-real-time dependent asset parsing and conversion work from the main workflow, allowing only lightweight file loading and memory read operations to be performed online. This not only significantly shortens the initial loading time of the game scene but also frees up computing resources for the core rendering logic in online mode.
[0054] The second aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the rendering method for static decorations on a large map in a 2D game according to any of the preceding claims.
[0055] A computer program stored on a computer-readable storage medium can perform the above-mentioned processing steps when executed by a processor, enabling the rendering method of static decorations on large maps to be encapsulated as a standardized software product or middleware component. This medium has cross-hardware platform compatibility and can be deployed on various terminal devices, providing physical carrier support for the practical engineering implementation and software distribution of rendering solutions.
[0056] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.
Claims
1. A method for rendering static decorations on a large map in a game, characterized in that, The rendering method includes: Obtain the prefab of static decorations in the scene, and extract key parameters for instantiation rendering from them; the key parameters include transformation matrix and texture region information; and serialize the key parameters into a pre-rendered data file. Load the pre-rendered data file and initialize a rendering workset in memory based on the key parameters. The rendering workset contains a contiguous array for storing rendering parameters, and the contiguous array includes a transformation matrix array and a texture array. Obtain the display status of static decorations within the current field of view, and dynamically update the rendering work set according to the display status, so that the rendering parameters corresponding to the static decorations in the display state are arranged continuously in the continuous array; The continuously arranged rendering parameters are submitted in batches to the graphics rendering interface, and the static decorations within the field of view are instantiated and rendered using the shared basic mesh and materials of the scene.
2. The rendering method for static decorations on a large map in a 2D game as described in claim 1, characterized in that, The transformation matrix is a 4×4 transformation matrix; the texture region information is represented as a four-dimensional vector consisting of four components; the rendering method further includes: The four-dimensional vector encoding of the texture region information is written into the homogeneous coordinate row of the 4×4 transformation matrix, so that the 4×4 transformation matrix can simultaneously carry spatial transformation data and texture mapping data. The homogeneous coordinates are the fourth row of the 4×4 transformation matrix.
3. The rendering method for static decorations on a large map in a 2D game as described in claim 2, characterized in that, The pre-rendered data file also includes an atlas page index; The step of submitting the rendering workset in batches to the graphics processor for rendering through the instantiated rendering interface includes: Bind an atlas of multiple merged texture maps to a graphics processor; The graphics processor's shader determines the target texture map in the atlas resource using a branchless selection function based on the atlas page index corresponding to the current rendering instance; Pixel sampling is performed on the target texture map by combining the texture region information extracted from the homogeneous coordinate rows of the 4×4 transformation matrix.
4. The rendering method for static decorations on a large map in a 2D game as described in claim 1, characterized in that, The step of dynamically updating the rendering working set according to the display state, so that the rendering parameters corresponding to the static decorations in the display state are arranged continuously in the continuous array, includes: An active statistic is set and maintained for the continuous array. The active statistic is used to indicate the number of static decorations that are currently in the display state, and the interval from the starting position to the corresponding position of the active statistic in the continuous array is the active data segment. When the display state of any static decoration is switched from displayed to hidden, the rendering parameters corresponding to the static decoration in the continuous array are swapped with the rendering parameters at the end of the active data segment, and the active statistics are decremented. When the display state of any static decoration changes from hidden to displayed, the rendering parameters corresponding to the static decoration are swapped with the rendering parameters of the next position after the end of the active data segment, and the active statistics are incremented.
5. The rendering method for static decorations on a large map in a 2D game as described in claim 1, characterized in that, When the rendering method is applied to a multi-threaded device, the initialization of the rendering working set in memory includes: Initialize the first rendering workset, the second rendering workset, and the command queue in memory; The step of dynamically updating the rendering working set according to the display state includes: The main thread reads the first rendering work set and, in response to changes in the display state of static decorations, generates corresponding operation instructions and stores them in the command queue. The secondary thread reads the command queue and performs data processing on the second rendering work set according to the operation instructions; At the end of the current frame rendering, the main thread swaps the pointers of the first rendering working set and the second rendering working set so that the updated second rendering working set can be read by the main thread in the next frame.
6. The rendering method for static decorations on a large map in a 2D game as described in claim 5, characterized in that, The secondary thread performs data processing on the second rendering working set in the background according to the operation instructions, including: Calculate the cumulative number of changes corresponding to the operation instructions in the command queue; When the cumulative change amount reaches a preset threshold, the sub-thread extracts the vertical coordinate components of the transformation matrix corresponding to each static decoration in the second rendering work set. Using the vertical coordinate components as the basis for depth sorting, insertion sort is performed on the rendering parameters in the second rendering workset.
7. The method for rendering static decorations on a large map in a 2D game as described in claim 1, characterized in that, The rendering method also includes: The large map is divided into multiple grids, and the static decorations are registered to the corresponding grids according to their location coordinates and depth levels; Calculate the set of target tiles that are currently active based on the map area covered by the current rendering camera; In response to a change in the active state of a tile, the display state of static decorations within the target tile set is switched to "show" in batches, and the display state of static decorations that leave the target tile set is switched to "hide" in batches.
8. The rendering method for static decorations on a large map in a 2D game as described in claim 1, characterized in that, The rendering method also includes: Pre-build an object pool in memory corresponding to the static decorator type; When any static decoration in the display state moves away from the rendering camera and the distance reaches a preset recycling threshold, the continuous array carrying the rendering parameters is returned to the object pool. When a new static decoration of the same type enters the display state, a free contiguous array is extracted from the object pool.
9. The rendering method for static decorations on a large map in a 2D game as described in claim 1, characterized in that, The steps of obtaining the prefab of static decorations in the scene, extracting key parameters for instantiation rendering from them, and serializing the key parameters into a pre-rendered data file are implemented when computing power is idle or offline. The other steps in the rendering method are performed online.
10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a processor, implements the steps of the method for rendering static decorations on a large map in a 2D game as described in any one of claims 1 to 9.
