Method and apparatus for controlling frame rate of virtual game, storage medium, and electronic device

Abstract

The present application discloses a method and apparatus for controlling the frame rate of a virtual game, a storage medium, and an electronic device. The method comprises: when a running parameter of a virtual game satisfies a frame rate control condition, acquiring an average spent rendering time of the virtual game, the average spent rendering time being used for representing the average time spent by the virtual game to render each picture within a historical time period; and, when the average spent rendering time is greater than a spent rendering time per frame corresponding to a frame rate setting of the virtual game, adjusting a rendering period of the virtual game so as to match the average spent rendering time, the rendering period being used for indicating a time interval between the completion of rendering each picture of the virtual game and the start of rendering the next picture. The present application solves the technical problem of the stability of frame rate control being low in a virtual game.

Description

Frame rate control method and device for virtual game, storage medium and electronic device

[0001] The present application claims priority from the Chinese patent application No. 2024111137497, filed on August 14, 2024, and entitled "Frame rate control method and device for virtual game, storage medium and electronic device", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the field of computers, in particular to frame rate control for virtual games. BACKGROUND

[0003] The rendering requirement of a virtual game is usually high, especially in a complex game scene. If the hardware processing device (such as CPU, GPU, etc.) of a player is insufficient in performance to stably support high frame rate rendering of the game, frame rate fluctuation will occur, resulting in low stability of frame rate control for the virtual game. Therefore, there is a problem of low stability of frame rate control for the virtual game.

[0004] At present, no effective solution has been proposed for the above problem. SUMMARY

[0005] Embodiments of the present application provide a frame rate control method and device for a virtual game, a storage medium and an electronic device to at least solve the technical problem of low stability of frame rate control for the virtual game.

[0006] According to an aspect of an embodiment of the present application, a frame rate control method for a virtual game is provided, comprising: in a case where a running parameter of the virtual game meets a frame rate control condition, obtaining an average rendering time consumption of the virtual game, wherein the average rendering time consumption is used to represent an average time consumption of rendering each frame of picture in a historical time period of the virtual game; in response to the average rendering time consumption being greater than a per-frame rendering time consumption set for the frame rate of the virtual game, adjusting a rendering period of the virtual game to match the average rendering time consumption, wherein the rendering period is used to indicate a time interval between starting and completing rendering of an i-th frame of picture and starting rendering of an i+1-th frame of picture, and the i-th frame of picture and the i+1-th frame of picture are any adjacent frames in the virtual game.

[0007] According to another aspect of the embodiments of the present application, a frame rate control device for a virtual game is also provided, comprising: a first obtaining unit configured to obtain an average rendering time consumption of the virtual game, in a case where a running parameter of the virtual game satisfies a frame rate control condition, wherein the average rendering time consumption is used to represent an average time consumption of rendering each frame of picture in a historical time period of the virtual game; and a first adjusting unit configured to adjust a rendering period of the virtual game to match the average rendering time consumption, in response to the average rendering time consumption being greater than a per-frame rendering time consumption set for a frame rate of the virtual game, wherein the rendering period is used to indicate a time interval between starting and completing rendering of an i-th frame of picture and starting rendering of an i+1-th frame of picture, and the i-th frame of picture and the i+1-th frame of picture are any adjacent frames in the virtual game.

[0008] In yet another aspect, the embodiments of the present application provide an electronic device, comprising:

[0009] a processor, a communication interface, a memory and a communication bus;

[0010] wherein the processor, the communication interface and the memory complete mutual communication through the communication bus; the communication interface is an interface of a communication module;

[0011] the memory is configured to store a computer program and transmit the computer program to the processor; the processor is configured to call the computer program in the memory to execute the method in the above aspects.

[0012] In yet another aspect, the embodiments of the present application provide a storage medium for storing a computer program, wherein the computer program is used to execute the method in the above aspects.

[0013] In yet another aspect, the embodiments of the present application provide a computer program product comprising a computer program which, when executed on a computer, causes the computer to execute the method in the above aspects. In the embodiments of the present application, in a case where a running parameter of a virtual game satisfies a frame rate control condition, an average rendering time consumption of the virtual game is obtained, wherein the average rendering time consumption is used to represent an average time consumption of rendering each frame of picture in a historical time period of the virtual game; and in response to the average rendering time consumption being greater than a per-frame rendering time consumption set for a frame rate of the virtual game, a rendering period of the virtual game is adjusted to match the average rendering time consumption, wherein the rendering period is used to indicate a time interval between starting and completing rendering of an i-th frame of picture and starting rendering of an i+1-th frame of picture, and the i-th frame of picture and the i+1-th frame of picture are any adjacent frames in the virtual game.

[0014] Since the average rendering time consumption is calculated based on the rendering time of each frame picture in a historical time period, it can accurately reflect the actual rendering efficiency of the game under the current hardware condition. Then, the embodiment compares the average rendering time consumption with the per-frame rendering time consumption corresponding to the frame rate setting of the game. If the average rendering time consumption is greater than the per-frame rendering time consumption corresponding to the frame rate setting, it indicates that the rendering capability of the hardware device cannot stably support the high frame rate set by the game. In this case, if the original rendering period is continued to be maintained, it will cause the frame rate to fluctuate because the GPU cannot complete the rendering task within the specified short time.

[0015] To this end, the embodiment adopts the strategy of adjusting the rendering period. By prolonging the rendering period, that is, increasing the time interval between the completion of rendering of each frame picture and the start of rendering of the next frame picture, the actual rendering speed of the hardware is adapted, so that the rendering period is adjusted according to the actual rendering efficiency of the game and the hardware performance instead of relying on the fixed frame rate setting, thereby achieving the purpose of reducing the picture sticking and jumping caused by the frame rate fluctuation, and thus realizing the technical effect of improving the frame rate control efficiency of the virtual game, and further solving the technical problem of low frame rate control stability of the virtual game. BRIEF DESCRIPTION OF DRAWINGS

[0016] FIG. 1 is a schematic diagram of an application environment of an optional frame rate control method of a virtual game according to an embodiment of the present application;

[0017] FIG. 2 is a schematic diagram of a flow of an optional frame rate control method of a virtual game according to an embodiment of the present application;

[0018] FIG. 3 is a schematic diagram of an optional frame rate control method of a virtual game according to an embodiment of the present application;

[0019] FIG. 4 is a schematic diagram of another optional frame rate control method of a virtual game according to an embodiment of the present application;

[0020] FIG. 5 is a schematic diagram of an optional frame rate control device of a virtual game according to an embodiment of the present application;

[0021] FIG. 6 is a structural schematic diagram of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order for those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should be within the scope of protection of the present application.

[0023] It is to be understood that the terminology "first", "second" and the like used in the specification and the claims of the application as well as the preceding description of the drawings is merely intended to distinguish between similar objects and not necessarily to describe a particular sequential or chronological order. It is to be understood that the use of data "first", "second", etc., can be interchanged, under appropriate circumstances, to describe whatever can come first, second, etc., other than as they come in the illustrative order described or claimed. Furthermore, the terms "comprise", "comprising", "include", "including", and the like, are to be construed open-ended, as containing, but not limited to, what is explicitly provided. Thus, use of these terms is not intended to exclude additional steps, components, or elements, or combinations thereof.

[0024] According to an aspect of the embodiments of the present application, there is provided a frame rate control method for a virtual game. Optionally, as an optional implementation, the frame rate control method for the virtual game can be applied, but is not limited to, an environment as shown in FIG. 1. Wherein, it can include, but is not limited to, a user device 102 and a server 112. The user device 102 can include, but is not limited to, a display 104, a processor 106 and a memory 108. The server 112 includes a database 114 and a processing engine 116.

[0025] The specific process can be as follows:

[0026] In step S102, the user device 102 acquires the running parameters of the virtual game.

[0027] In step S104, the running parameters are sent to the server 112 through the network 110.

[0028] In steps S106-S110, the server 112 determines whether the running parameters of the virtual game meet the frame rate control condition through the processing engine 116. If the running parameters of the virtual game meet the frame rate control condition, the average rendering time of the virtual game is obtained. In response to the average rendering time being greater than the rendering time per frame set for the frame rate of the virtual game, the rendering period of the virtual game is adjusted to match the average rendering time, and the rendered game picture is obtained.

[0029] In step S112, the rendered game picture is sent to the user device 102 through the network 110. The user device 102 displays the rendered game picture on the display 104 through the processor 106, and stores the rendered game picture in the memory 108.

[0030] In addition to the example shown in FIG. 1, the terminal device described above can be a terminal device configured with a target client, and can include, but is not limited to, at least one of the following: a mobile phone (such as an Android mobile phone, an iOS mobile phone, etc.), a notebook computer, a tablet computer, a palm computer, a MID (Mobile Internet Device), a PAD, a desktop computer, a smart television, a virtual reality related device (such as a VR headset, a handle / controller, a game console), etc. The target client can be a video client, an instant messaging client, a browser client, an education client, etc. The network described above can include, but is not limited to: a wired network including a local area network, a metropolitan area network, and a wide area network, and a wireless network including Bluetooth, WIFI, and other networks that enable wireless communication. The server described above can be a single server, a server cluster composed of multiple servers, or a cloud server. The above is only an example, and the present embodiment does not make any limitation on this.

[0031] Optionally, as an optional implementation, as shown in FIG. 2, the frame rate control method of the virtual game can be executed by an electronic device, which can be, for example, a user device or a server as shown in FIG. 1, and the specific steps include:

[0032] S202, in a case where a running parameter of the virtual game meets a frame rate control condition, obtaining an average rendering time consumption of the virtual game, wherein the average rendering time consumption is used to represent an average time consumption of rendering each frame of picture in a historical time period of the virtual game;

[0033] S204, in response to the average rendering time consumption being greater than a per-frame rendering time consumption set for the frame rate of the virtual game, adjusting a rendering period of the virtual game to match the average rendering time consumption, wherein the rendering period is used to indicate a time interval between starting and completing rendering of an i-th frame of picture and starting rendering of an i+1-th frame of picture, and the i-th frame of picture and the i+1-th frame of picture are any adjacent frames in the virtual game.

[0034] Optionally, in the present embodiment, the frame rate control method of the virtual game described above can be applied in multiple scenes, such as a highly complex game scene, which contains a large number of polygons, textures, and light and shadow effects, and puts high requirements on the rendering capability of hardware. The game engine continuously monitors the running parameter of the game, and calculates and obtains the average rendering time consumption in the past period of time when the frame rate control condition is met. The game engine compares the average rendering time consumption with the per-frame rendering time consumption corresponding to the game frame rate setting. If it is found that the average rendering time consumption exceeds the preset per-frame rendering time consumption, the game engine will automatically adjust the rendering period to match the current average rendering time consumption.

[0035] For example, in a game scenario running on a low-configuration hardware device, the hardware performance of the player's device is detected when the game starts. Based on the hardware performance, the rendering period and frame rate settings of the game are dynamically adjusted to ensure relatively stable frame rates on different devices. During the game process, the average rendering time consumption is continuously detected, and the rendering period is dynamically adjusted according to the actual situation.

[0036] For another example, in a large-scale massively multiplayer online role-playing game (MMORPG) scenario, multiple players gather in the same area for battle or activities. The server continuously monitors the performance and rendering time consumption of each client. The average rendering time consumption data of all clients is collected and analyzed. When the average rendering time consumption of one or more clients exceeds the preset value, the server dynamically adjusts the rendering period of these clients.

[0037] For another example, in a virtual reality (VR) scenario, when the running parameters of a virtual game or virtual reality application meet the frame rate control conditions, the system detects and calculates the average rendering time consumption. This average rendering time consumption reflects the average time for the virtual reality environment to render each frame of picture in the past period of time. This indicator is crucial for evaluating the performance of the virtual reality application.

[0038] If the average rendering time consumption exceeds the per-frame rendering time consumption corresponding to the frame rate setting of the virtual game or virtual reality application, the rendering period needs to be adjusted. The frame rate setting usually determines the ideal rendering time for each frame of picture, for example, a setting of 60 frames per second means that the ideal rendering time for each frame should be 1 / 60 second.

[0039] When the actual rendering time consumption is higher than this ideal value, if no adjustment is made, it may cause picture lag or delay, seriously affecting the user experience. Therefore, by adjusting the rendering period, that is, the time interval between the completion of rendering of each frame of picture and the start of rendering of the next frame of picture, the performance of the virtual reality application can be optimized.

[0040] Specifically, if the average rendering time consumption is long, the system can automatically increase the rendering period to ensure that each frame of picture has enough time for high-quality rendering. Although this may cause the frame rate to decrease, it can ensure the smoothness and stability of the picture, thereby improving the user experience.

[0041] Conversely, if the average rendering time consumption is short, it means that the system has enough performance to handle a higher frame rate, at which time the rendering period can be appropriately reduced to increase the frame rate, bringing the user a more smooth and delicate virtual reality experience.

[0042] In summary, by dynamically adjusting the rendering period to match the average rendering duration, a smoother and more stable visual experience can be achieved in virtual reality scenarios, enhancing user immersion and satisfaction. Additionally, by adjusting the rendering period in real-time to match the actual rendering duration, unnecessary waste of computing resources can be avoided. When the system detects that the rendering task is relatively light, the rendering period can be appropriately shortened to increase the frame rate; conversely, when the rendering load is heavy, the rendering period is extended to ensure picture quality while avoiding hardware overheating or overloading.

[0043] Optionally, in this embodiment, the "running parameters of the virtual game" can refer to various states and performances of the virtual game during its running process. This includes but is not limited to the smoothness of the game, the picture quality, the response speed, etc. The quality of the running parameters directly affects the game experience of the players.

[0044] Optionally, in this embodiment, the "frame rate control condition" can refer to some standards or parameters set in the virtual game, used to ensure that the frame rate (i.e. the number of frames displayed per second) of the game remains within a stable and ideal range. These conditions can involve hardware performance, network delay, game internal logic, etc.

[0045] Optionally, in this embodiment, the "historical time period" can refer to the time range considered when calculating the average rendering duration. This time period can be a few seconds, a few minutes or longer, depending on the needs and purposes of the analysis. The choice of which historical time period to determine the average rendering duration is related to the time when the running parameters of the virtual game meet the frame rate control condition. When the running parameters of the virtual game meet the frame rate control condition at time A, the historical time period close to time A can be determined as the historical time period for obtaining the average rendering duration.

[0046] Optionally, in this embodiment, the "average rendering duration" can refer to the average time spent by the virtual game in rendering each frame of picture within a certain period of time. This time reflects the computing power and time cost required by the game engine when rendering each frame of picture.

[0047] For further illustration, optionally, assume that a virtual game has rendered 3600 frames of picture in the past one minute. The rendering time of each frame may vary due to factors such as scene complexity and hardware performance. In order to obtain an overall performance indicator, the "average rendering duration" calculates the total rendering time of the 3600 frames of picture and divides it by 3600, thereby obtaining an average value, such as 5 milliseconds per frame for rendering.

[0048] Optionally, in this embodiment, the "frame rendering time corresponding to the frame rate setting of the virtual game" can refer to the theoretical time required to render each frame of the virtual game corresponding to the frame rate set in the game (such as 60fps, 30fps, etc.). Frame rate represents the number of frames displayed per second, so the rendering time of each frame is the time obtained by dividing 1 second by the frame rate.

[0049] For further illustration, optionally, for example, if the frame rate of the game is set to 60fps (frames per second), the theoretical rendering time of each frame should be 1 / 60 second, i.e. about 16.67 milliseconds. This means that in order to maintain a frame rate of 60fps, the game engine needs to complete the rendering of a frame of picture within every 16.67 milliseconds.

[0050] Optionally, in this embodiment, the "rendering cycle of the virtual game" can refer to the total time interval from the start of rendering a frame of picture (such as the i-th frame of picture) by the game engine to the completion of the rendering of the frame, and then to the start of rendering the next frame (such as the i+1-th frame of picture). This cycle includes all steps required for rendering a frame, such as scene preparation, geometry processing, rasterization, pixel shading, etc., as well as any possible synchronization or waiting time.

[0051] Optionally, when the average rendering time (the average value of the actual measured time required for rendering each frame) of the game is higher or lower than the expected rendering time of each frame, this embodiment adjusts the rendering cycle to ensure stable operation of the game.

[0052] If the average rendering time is higher than the expected rendering time of each frame, the rendering cycle can be increased to give each frame more rendering time to prevent picture problems caused by incomplete rendering. This may lower the actual frame rate of the game, but can ensure the integrity and stability of the picture. Conversely, if the average rendering time is lower than the expected value, the rendering cycle can be reduced to increase the frame rate of the game, thereby providing a smoother visual experience.

[0053] For further illustration, optionally, assuming that the frame rate of a virtual game is set to 60fps, the theoretical rendering time of each frame should be 1 / 60 second, i.e. about 16.67 milliseconds. If the average rendering time monitored is 20 milliseconds, which exceeds the theoretical value, this embodiment will automatically adjust the rendering cycle, such as increasing to 20 milliseconds, to ensure that each frame has enough time for rendering, thereby avoiding picture freezing or frame dropping.

[0054] It should be noted that the description of the embodiment relates to the performance optimization strategy of the virtual game. First, when the running parameters of the game meet certain frame rate control conditions, the embodiment will monitor and calculate the average time consumption of rendering each frame in the historical time period. If it is found that the average time consumption exceeds the rendering time consumption per frame under the game frame rate setting, the embodiment will adjust the rendering period of the game to ensure the smooth running of the game.

[0055] By monitoring the average rendering time consumption of the game in real time and adjusting the rendering period as needed, this strategy can ensure that the game can maintain a stable frame rate when facing high load or performance fluctuations. This not only improves the smoothness and responsiveness of the game, but also reduces the phenomenon of screen freezing or frame skipping caused by mismatched hardware performance.

[0056] Further, for example, as shown in FIG. 3, when the running parameters of the virtual game meet the frame rate control conditions (such as abnormal situations such as jitter or tailing of the screen content of the game screen 302), the average rendering time consumption 304 of the virtual game is obtained; when the average rendering time consumption 304 is greater than the rendering time consumption per frame corresponding to the frame rate setting of the virtual game 306, the rendering period 308 of the virtual game is adjusted to match the average rendering time consumption, such as the game screen 310 after adjusting the rendering period 308. Compared with the game screen 302 before adjusting the rendering period 308, the frame rate is more stable.

[0057] Through the embodiments provided in the present application, since the average rendering time consumption is calculated based on the rendering time of each frame of the screen in the historical time period, it can accurately reflect the actual rendering efficiency of the game under the current hardware conditions. Then, the embodiment compares the average rendering time consumption with the rendering time consumption per frame corresponding to the frame rate setting of the game. If the average rendering time consumption is greater than the rendering time consumption per frame corresponding to the frame rate setting, it means that the rendering capability of the hardware device cannot stably support the high frame rate set by the game. In this case, if the original rendering period is maintained, it will cause frame rate fluctuations, because the GPU cannot complete the rendering task within the specified short time. In view of this, the embodiment adopts the strategy of adjusting the rendering period. By prolonging the rendering period, that is, increasing the time interval between the completion of rendering each frame of the screen and the start of rendering the next frame of the screen, the actual rendering speed of the hardware is adapted, so that it is no longer dependent on the fixed frame rate setting, but adjusts the rendering period according to the actual rendering efficiency of the game and the hardware performance, thereby achieving the purpose of reducing the screen freezing and jumping caused by frame rate fluctuations, thereby realizing the technical effect of improving the frame rate control efficiency of the virtual game.

[0058] As an optional solution, before the average rendering time consumption of the virtual game is acquired, the method further comprises: acquiring a CPU preprocessing time, a CPU drawing submission time consumption, and a GPU rendering execution time, wherein the CPU preprocessing time is used to represent a time consumed by the CPU in preparing for rendering in the historical time period, the CPU drawing submission time consumption is used to represent a time consumed by the CPU in preparing and submitting a graphics drawing command to the GPU in the historical time period, and the GPU rendering execution time is used to represent a time consumed by the GPU in receiving the graphics drawing command to completing the rendering work in the historical time period.

[0059] The acquiring of the average rendering time consumption of the virtual game in S202 comprises: acquiring the average rendering time consumption according to the CPU preprocessing time, the CPU drawing submission time consumption, and the GPU rendering execution time.

[0060] Optionally, in the embodiment, the CPU preprocessing time can refer to a time consumed by the CPU in preparing for rendering (such as scene construction, resource loading, etc.) in the historical time period.

[0061] Optionally, in the embodiment, the CPU drawing submission time consumption can refer to a time consumed by the CPU in preparing and submitting a graphics drawing command to the GPU in the historical time period. This can include but is not limited to steps such as generating a drawing command, organizing rendering data, etc.

[0062] Optionally, in the embodiment, the GPU rendering execution time can refer to a time consumed by the GPU in receiving a graphics drawing command to finally completing the rendering work in the historical time period. This can include but is not limited to steps such as GPU executing a rendering pipeline, processing a shader, texture mapping, etc.

[0063] Optionally, in the embodiment, the average rendering time consumption can refer to an average time of rendering each frame of the virtual game in the historical time period, which is calculated based on the CPU preprocessing time, the CPU drawing submission time consumption, and the GPU rendering execution time.

[0064] It should be noted that, before the average rendering time consumption of the virtual game is acquired in the description of the embodiment, three key time parameters, i.e., the CPU preprocessing time, the CPU drawing submission time consumption, and the GPU rendering execution time, need to be acquired. The three time parameters respectively represent a time of the CPU in preparing for rendering, a time of the CPU in preparing and submitting a graphics drawing command to the GPU, and a time of the GPU in receiving a command to completing the rendering work. The average rendering time consumption is acquired based on the three time parameters.

[0065] By breaking down the different stages in the rendering process, it is possible to pinpoint the performance bottlenecks in game rendering. For example, if the CPU pre-processing time is too long, it may indicate that the game scene is too complex or that there is room for optimization in resource loading. If the GPU rendering execution time is too long, it may suggest that there are efficiency issues in the graphics rendering pipeline or the need for more efficient hardware support.

[0066] For further illustration, it is optionally assumed that, within a certain period of time, the CPU pre-processing time is 10 milliseconds, the CPU draw submission time is 5 milliseconds, and the GPU rendering execution time is 20 milliseconds. Then, the total rendering time for this frame is the sum of the three, which is 35 milliseconds. If multiple frames are monitored and the times are averaged, the average rendering time can be obtained.

[0067] By recording and analyzing the CPU pre-processing time, CPU draw submission time, and GPU rendering execution time in detail, game developers can more accurately locate performance bottlenecks and optimize game rendering efficiency. This not only helps to improve the overall running speed and smoothness of the game, but also ensures that players can have a good gaming experience in various hardware environments.

[0068] As an optional solution, the average rendering time is obtained based on the CPU pre-processing time, CPU draw submission time, and GPU rendering execution time, including:

[0069] S1-1, obtaining the cumulative total of CPU pre-processing time, CPU draw submission time, and GPU rendering execution time within a 1-second time period, wherein the historical time period includes a 1-second time period;

[0070] S1-2, obtaining the target frame number of the virtual game rendered within a 1-second time period;

[0071] S1-3, determining the ratio between the cumulative total and the target frame number as the average rendering time.

[0072] Optionally, in this embodiment, the CPU pre-processing time, CPU draw submission time, and GPU rendering execution time can respectively represent the preparation time of the CPU before executing rendering, the time of the CPU preparing and submitting graphics commands to the GPU, and the time of the GPU from receiving commands to completing rendering.

[0073] Optionally, in this embodiment, the cumulative total of the 1-second time period can refer to the cumulative total of the above three time parameters (CPU pre-processing time, CPU draw submission time, and GPU rendering execution time) within a 1-second time period.

[0074] Optionally, in this embodiment, the target frame number can be understood as the number of frames that the virtual game plans to render within a 1-second time period.

[0075] Optionally, in the embodiment, the average rendering time consumption can be calculated by dividing the cumulative total of the time within 1 second by the target frame number, which represents the average time for rendering each frame within the 1 second.

[0076] It should be noted that the embodiment describes a method for calculating the average rendering time consumption of a virtual game, involving three key time parameters: CPU preprocessing time, CPU drawing submission time consumption, and GPU rendering execution time. By obtaining the cumulative total of these times within 1 second, and combining the target frame number of game rendering within the 1 second, the average rendering time consumption per frame is calculated.

[0077] By monitoring these detailed time parameters, developers can gain a deep understanding of the game's rendering process and identify possible performance bottlenecks. In addition, the embodiment can also be used to compare the impact of different hardware configurations or optimization measures on game performance.

[0078] For further illustration, optionally assume that within 1 second, the cumulative total of CPU preprocessing time is 200 milliseconds, the cumulative total of CPU drawing submission time consumption is 100 milliseconds, and the cumulative total of GPU rendering execution time is 400 milliseconds. If the target of the game within the 1 second is to render 60 frames, then the cumulative total of time is 700 milliseconds. The average rendering time consumption is 700 milliseconds divided by 60 frames, approximately equal to 11.67 milliseconds per frame.

[0079] By accurately calculating and monitoring the cumulative total of CPU preprocessing time, CPU drawing submission time consumption, and GPU rendering execution time within each second, and combining the target rendering frame number to determine the average rendering time consumption, the rendering period can be more accurately adjusted to adapt to the actual performance of the hardware. This dynamic adjustment helps to reduce the fluctuation of frame rate, making the game picture smoother and more stable.

[0080] As an optional solution, obtaining the CPU preprocessing time, CPU drawing submission time consumption, and GPU rendering execution time of a virtual game includes:

[0081] S2-1, the time from calling a first function to the time before calling a second function to start rendering is determined as the CPU preprocessing time, wherein the first function is used to make the application of the virtual game wait for the opportunity to start rendering before rendering the current frame, and the second function is used to mark the start of the rendering process after confirming the rendering opportunity, so that the application starts to prepare and submit rendering data for the current frame;

[0082] S2-2, a time period from when the second function is called to start rendering the current frame by the virtual game to when the third function is called to submit the rendered texture, is determined as a CPU drawing submission time consumption.

[0083] The rendered texture can be submitted to a target component for receiving and processing the image data submitted by the third function.

[0084] S2-3, a time period from when the GPU starts receiving the graphics drawing commands after the third function is called to submit the rendered texture by the virtual game to when the GPU completes all the rendering work, is determined as a GPU rendering execution time.

[0085] The rendering work includes all the texture drawing work.

[0086] Optionally, in the embodiment, the CPU preprocessing time can be a time period from when the first function is called to when the second function is called to prepare to start rendering.

[0087] Optionally, in the embodiment, the CPU drawing submission time consumption can be a time period from when the second function is called to start rendering the current frame by the virtual game to when the third function is called to submit the rendered texture to the target component.

[0088] Optionally, in the embodiment, the GPU rendering execution time can be a time period from when the GPU starts receiving the graphics drawing commands after the third function is called to submit the rendered texture by the virtual game to when the GPU completes all the rendering work.

[0089] It should be noted that the embodiment describes how to obtain three key time parameters in the virtual game: the CPU preprocessing time, the CPU drawing submission time consumption, and the GPU rendering execution time.

[0090] By accurately measuring these time parameters, developers can gain insights into the rendering performance of the game, identify possible bottlenecks, and optimize accordingly. For example, if the CPU pre-processing time is excessively long, it may indicate that there are efficiency issues with scene updates or resource loading in the game; if the GPU rendering execution time is excessively long, it may suggest that the graphics rendering pipeline needs optimization or that GPU resources are insufficient.

[0091] For further illustration, it is optionally assumed that during the rendering process of a certain frame, the first function is called at time point A, the second function is called at time point B, the third function is called at time point C, and the GPU completes all texture drawing work at time point D. Then, the CPU pre-processing time is B-A, the CPU drawing submission time is C-B, and the GPU rendering execution time is D-C.

[0092] By accurately measuring and detecting the CPU pre-processing time, CPU drawing submission time, and GPU rendering execution time, the rendering strategy can be dynamically adjusted, such as reducing rendering details, adjusting view distance, or optimizing resource loading, to ensure the stability of the frame rate. This dynamic adjustment can maximize the stability of the frame rate without affecting the visual quality of the game.

[0093] As an optional solution, after adjusting the rendering period of the virtual game to match the average rendering time, the method further comprises:

[0094] In the case where the rendering period is greater than or equal to a preset threshold, the picture content of the next frame is optimized according to the picture content of the current frame.

[0095] Optionally, in this embodiment, the preset threshold can be a pre-set time value for determining whether the rendering period is excessively long, thereby triggering the optimization mechanism.

[0096] Optionally, in this embodiment, optimizing the picture content can be improving or adjusting the picture content of the next frame according to the picture content of the current frame to improve rendering efficiency and / or picture quality.

[0097] It should be noted that during the running of the virtual game, when the average rendering time of the game exceeds the rendering time per frame corresponding to the frame rate setting, the rendering period of the game will be adjusted to match this average rendering time. After that, if the adjusted rendering period is greater than or equal to a preset threshold, the embodiment will optimize the picture content of the next frame according to the picture content of the current frame.

[0098] Optimizing the picture content of the next frame can include but is not limited to the following methods: reducing texture resolution, reducing shadow or lighting effects, simplifying model details, adjusting view distance, etc. These optimization measures aim to reduce the rendering burden of the next frame, thereby maintaining or improving the stability of the frame rate.

[0099] For further illustration, optionally assume that the frame rate of a virtual game is set to 60 frames per second, and each frame should theoretically take about 16.67 milliseconds. If the average rendering time increases to 20 milliseconds due to some complex scenes or special effects, the rendering period needs to be adjusted to 20 milliseconds to match this time consumption. If the rendering period (20 milliseconds) is greater than the preset threshold (for example, 5 milliseconds) at this time, the embodiment will start to optimize the next frame according to the picture content of the current frame, such as by reducing unnecessary details, reducing the complexity of some special effects, and the like.

[0100] Through the embodiments provided in the present application, the game can adaptively optimize the picture content when the rendering period is longer to maintain the stability of the frame rate. This not only improves the smoothness of the game, but also provides a more consistent gaming experience under different hardware configurations or complex scenes. At the same time, this dynamic optimization mechanism also helps to reduce the excessive consumption of hardware resources and improve the overall efficiency of game running.

[0101] As an optional solution, optimizing the picture content of the next frame of the current frame according to the picture content of the current frame comprises:

[0102] S3-1, obtaining a first dynamic element and a first static element in the picture content of the current frame;

[0103] S3-2, predicting a position feature of the first dynamic element in the picture content of the next frame, and optimizing a second dynamic element in the picture content of the next frame by using the position feature;

[0104] S3-3, predicting a visual feature of the first static element in the picture content of the next frame, and optimizing a second static element in the picture content of the next frame by using the visual feature.

[0105] Optionally, in the embodiment, the first dynamic element can be a dynamic (i.e., moving or changing) visual element identified in the current frame. The second dynamic element can be a corresponding or related dynamic element in the next frame.

[0106] Optionally, in the embodiment, the first static element can be a static (i.e., not moving or not changing) visual element identified in the current frame. The second static element can be a corresponding or related static element in the next frame.

[0107] Optionally, in the embodiment, the position feature can be a characteristic such as the position or movement trajectory of the dynamic element in the picture.

[0108] Optionally, in the embodiment, the visual feature can be a visual identifiable characteristic such as the shape, color, texture, and the like of the static element.

[0109] It should be noted that the embodiment describes a method for optimizing the content of a virtual game screen. Specifically, first, dynamic and static elements in the current frame are identified, then the positions and visual features of these elements in the next frame are predicted, and finally these predictions are used to optimize the corresponding elements in the next frame.

[0110] This optimization method can not only be applied to the optimization of individual elements, but also be extended to the optimization of the entire scene. For example, according to the position prediction of dynamic elements, the loading and unloading of scene resources can be performed in advance, thereby reducing resource consumption during rendering; at the same time, according to the visual feature prediction of static elements, the lighting, shadow, and other effects of the scene can be pre-rendered or adjusted to improve the realism and smoothness of the screen.

[0111] Further, it is optionally assumed that there is a fast-moving car (first dynamic element) and a stationary building (first static element) in the current frame. The system first identifies these two elements and predicts where the car will probably move to in the next frame (position feature), and how the visual characteristics such as the color and shape of the building may appear in the next frame (visual feature). Then, according to these predictions, the embodiment optimizes the corresponding elements (second dynamic element and second static element) in the next frame, such as by preloading the relevant resources of the position where the car will arrive, or adjusting the rendering details of the building to improve rendering efficiency and screen quality.

[0112] Through the embodiments provided in the present application, the game can realize intelligent optimization of the content of the next frame screen. Specifically, the positions of dynamic elements and the visual features of static elements can be predicted and optimized in advance, thereby reducing unnecessary calculations and resource consumption when rendering the next frame, improving rendering speed and screen quality. This not only helps to improve the frame rate stability of the game, but also provides players with a more smooth and realistic gaming experience.

[0113] As an optional solution, the method further comprises:

[0114] In the case where the running parameters of the virtual game do not meet the frame rate control condition, the rendering period is adjusted to match the time consumption of each frame rendering for the frame rate setting of the virtual game.

[0115] Optionally, in the embodiment, the rendering period adjustment can be dynamically changing the rendering interval of each frame of screen according to the actual running parameters and frame rate requirements of the game to achieve the expected frame rate.

[0116] It should be noted that the embodiment describes an adjustment strategy, when the running parameters of the virtual game do not meet the frame rate control condition, the rendering period will be adjusted to match the per-frame rendering time corresponding to the frame rate setting. This is to ensure that the game can run stably at the set frame rate, even if the actual running parameters do not match the expected.

[0117] The effect of this strategy is to significantly improve the compatibility and stability of the game. By automatically adjusting the rendering period to match the per-frame rendering time corresponding to the frame rate setting, the game can provide a smoother and more consistent user experience on various hardware configurations. Even in the case of insufficient hardware performance or increased game scene complexity, this strategy can help the game maintain a relatively stable frame rate, thereby reducing the adverse effects of stuttering, frame dropping, etc., and improving the satisfaction of players.

[0118] For further illustration, optionally assuming that the frame rate set by a game is 60 frames per second, the theoretical per-frame rendering time should be 16.67 milliseconds. If for some reason (such as insufficient hardware performance, increased game scene complexity, etc.) the actual running parameters of the game cannot meet this frame rate requirement, the embodiment will automatically adjust the rendering period, which may increase the rendering time per frame, such as adjusting to 20 milliseconds per frame, to ensure that the game can run stably at a lower frame rate, rather than stuttering or crashing.

[0119] By automatically adjusting the rendering period to match the per-frame rendering time corresponding to the frame rate setting, the game can provide a smoother and more consistent user experience on various hardware configurations. Even in the case of insufficient hardware performance or increased game scene complexity, this strategy can help the game maintain a relatively stable frame rate, thereby reducing the adverse effects of stuttering, frame dropping, etc., and improving the satisfaction of players.

[0120] As an optional solution, the method further comprises:

[0121] In the case where the mode of the virtual game running is switched from the first mode to the second mode, it is determined that the running parameters of the virtual game do not meet the frame rate control condition, wherein the first mode is a game mode that meets the frame rate control condition, and the second mode is a game mode that does not meet the frame rate control condition.

[0122] Optionally, in the embodiment, the first mode can refer to a mode in which the game runs in a manner that meets the frame rate control condition, i.e., the rendering speed of the game and the frame rate setting are matched, and the game runs smoothly.

[0123] Optionally, in this embodiment, the second mode can refer to a mode in which the game does not meet the frame rate control conditions. This can be due to an increase in the complexity of the game scene or limited hardware resources, resulting in an actual frame rate of the game that is lower than the set value.

[0124] Optionally, in this embodiment, when the game mode is switched, in order to maintain the smoothness of the game, the rendering interval of each frame of picture will be automatically adjusted according to the frame rate requirement in the new game mode.

[0125] It should be noted that this embodiment describes a rendering cycle adjustment strategy in a specific scenario. When the virtual game is switched from a mode that meets the frame rate control conditions (first mode) to another mode that does not meet the frame rate control conditions (second mode), this embodiment will adjust the rendering cycle accordingly to ensure that in the new game mode, the rendering cycle of the game can match the per-frame rendering time corresponding to the frame rate setting.

[0126] The implementation of this strategy may depend on the internal optimization mechanisms of the game, including but not limited to dynamically adjusting picture quality, reducing unnecessary rendering elements, utilizing hardware acceleration, etc. Through these optimization measures, the game can more flexibly adjust the rendering cycle in different modes to adapt to different frame rate requirements.

[0127] Further, optionally, assume that a game runs in a normal scene (first mode), with stable frame rate and meeting the set requirements. However, when the player enters a complex battle scene (second mode), due to the increase in elements to be rendered, the frame rate of the game begins to drop and no longer meets the original frame rate control conditions. At this time, this embodiment will automatically adjust the rendering cycle, such as by increasing the rendering time of each frame, to ensure that in the new complex scene, the game can still run at a relatively stable frame rate.

[0128] By automatically adjusting the rendering cycle when the game mode is switched, the game can provide a more stable and consistent user experience in various scenarios. Even in the case of limited hardware performance or increased complexity of the game scene, this strategy can help the game maintain a relatively reasonable frame rate, thereby reducing the phenomenon of lag and frame drop, and improving the game experience of the player.

[0129] As an optional solution, for the convenience of understanding, the frame rate control method of the virtual game is applied to the virtual reality game scene, wherein the depth support of the head-mounted device is the key to ensure the immersive experience. Although some solutions perform well in head-mounted device support, there are still limitations in cross-platform adaptability, especially on the Windows platform, which is usually limited to specific rendering technologies such as Direct3D. Considering that many VR games on the Windows platform use streaming technology to transmit audio and video content to the head-mounted device, the present embodiment proposes a virtual head-mounted display (HMD) device. This device focuses on game streaming functions, effectively addressing the shortcomings of existing solutions in Windows VR game streaming, providing users with a smoother and more comprehensive VR gaming experience. This innovation not only expands the application scenarios of VR technology, but also improves the coherence and quality of user experience.

[0130] Optionally, during the rendering process of the virtual game, fine control of the rendering process is required to ensure a smooth and stable visual experience. The present embodiment dynamically adjusts the rendering period by real-time detection of the rendering time consumption of the game to adapt to changes in system resources, thereby achieving the purpose of optimizing frame rate stability and picture quality.

[0131] Specifically, in the game rendering process, the generation of each frame of picture needs to go through careful calculation and control. In order to maintain the stability of the frame rate, the present embodiment obtains the predicted rendering display time and frame interval time from the system runtime through a specific interface before starting to render each frame. This frame interval time actually reflects the average rendering frame rate and is an important basis for adjusting the rendering period.

[0132] In addition, the present embodiment can record key time points such as frame wake-up time, start time, submission time, and GPU completion time by calling relevant interfaces. These data provide a basis for calculating the time consumption of each link for the present embodiment, thereby enabling more accurate prediction and adjustment of the rendering period of the next frame.

[0133] When the system detects that the time consumption of a certain link exceeds the preset rendering period, the present embodiment gradually increases the rendering period to ensure the rendering speed and reduce picture lag. However, in high-load situations, this dynamic adjustment may cause instability in the frame rate. To solve this problem, the present embodiment further optimizes the frame rate control mechanism.

[0134] Specifically, the present embodiment records the rendering time consumption of each frame and calculates the average rendering time consumption after a period of time. This average value is then used as the new rendering period to ensure that the game can be rendered at a smoother frame rate. This method not only effectively reduces the jitter and jumping sensation of the picture, but also significantly improves the gaming experience of the player.

[0135] To achieve the above scheme, as shown in FIG. 4, the embodiment can call the following interfaces:

[0136] 1. xrWaitFrame: Before starting to render a frame, this interface is used to obtain the predicted rendering display time and frame interval time from the system runtime.

[0137] 2. xrBeginFrame and xrEndFrame: Used to record the start and end time of a frame for subsequent calculation of rendering time consumption.

[0138] 3. Customized time consumption calculation and rendering cycle adjustment interface: Used to dynamically adjust the rendering cycle of the next frame according to the recorded time points and time consumption data.

[0139] Through the combined use of these interfaces, the embodiment can achieve fine control of the game rendering process, thereby ensuring that players can enjoy smooth and stable virtual reality game experience.

[0140] Specifically, to improve the stability of game rendering and improve picture quality, the embodiment proposes a time consumption detection and fine frame rate averaging algorithm. Specifically, the frame rate averaging algorithm includes the rendering time consumption of each frame, which covers the pre-rendering execution drawing time consumption, CPU execution drawing time consumption and GPU execution drawing time consumption from wake-up to start drawing. These data provide accurate time consumption information of each link in the rendering process for the frame rate averaging algorithm, which constitutes the basis for subsequent optimization of frame rate control strategy.

[0141] After continuous rendering for more than 1 second, the embodiment starts to calculate the average frame time consumption. By considering the pre-rendering execution drawing time consumption, CPU execution drawing time consumption and GPU execution drawing time consumption, and combining them with the actual rendering frame number within 1 second, a key performance indicator can be obtained—the average rendering time consumption of the last second, such as (pre-rendering execution drawing time consumption + CPU execution drawing time consumption + GPU execution drawing time consumption) / frame number within 1 second. This indicator deeply reflects the rendering efficiency of the game within a specific time window.

[0142] Among them, "frame number within 1 second" represents the actual rendering frame number completed by the game within 1 second. Although the game usually sets an ideal frame rate, such as 60fps or 72fps, under heavy system load, the actual rendering frame number may decrease, for example, fluctuate between 30-50fps. Such frame rate variation will directly affect the visual experience of players. Therefore, the embodiment uses a fine frame rate control strategy to deal with such situations to ensure smoother and more stable game pictures.

[0143] Next, the average rendering time calculated will be used as the new rendering period. This approach aims to render the game at the smoothest possible frame rate, reducing screen jitter and trailing effects caused by frame rate fluctuations. By using the average rendering period to control the frame rate, the difference in sleep time between each frame of the game becomes more uniform, improving the overall stability of the rendering.

[0144] In addition, the frame rate control algorithm of this embodiment also has the ability of dynamic adjustment. With the change of game rendering load, such as when the player switches levels or game modes, the complexity of the rendering scene may change. In this case, the algorithm of this embodiment can automatically adjust the rendering period to adapt to the new load condition. When the rendering load decreases, the rendering period will automatically return to the preset frame rate, such as 60fps or 72fps, ensuring that the game can provide the best visual experience in various scenarios.

[0145] By implementing the frame rate averaging algorithm, the visual effect of the game in the head-mounted device has been significantly improved. The trailing and jitter phenomenon is basically eliminated, providing players with a more stable and smooth virtual reality experience.

[0146] In addition, it needs to be explained that in the process of improving virtual reality (VR) experience, ATW (Asynchronous TimeWarp) and ASW (Asynchronous Spacewarp) technology indeed provides an effective solution to the low frame rate problem. However, these two technologies also have certain limitations. They are highly dependent on specific hardware chips and control algorithms, which to some extent limits their universality. At the same time, the ATW technology mainly solves the change of rendering scene caused by head movement, and has limited compensation ability for the motion inside the rendering scene. While the ASW technology can enhance the accuracy of the picture through prediction, but its motion detection calculation is large, and it needs the support of high-performance hardware.

[0147] In view of the above limitations, this embodiment designs compatibility and optimization strategies to ensure that these technologies can run efficiently on multiple hardware platforms. In addition, this embodiment also integrates deeply with high-performance VR graphics processing hardware to provide necessary motion vectors and reduce the burden of the graphics engine, ensuring the efficient implementation of the ASW technology.

[0148] Specifically, the embodiment first conducts comprehensive detection and optimization of the game rendering process through meticulous time consumption recording and frame rate averaging algorithm. On this basis, the embodiment further introduces ATW technology to deal with possible frame rate instability and delay problems. With the ATW technology, when the VR headset cannot update the next frame in time, the system will automatically generate a new virtual image using the data of the last frame to ensure the smoothness of the animation effect. This not only effectively reduces motion distortion, but also significantly improves the comfort and realism of the VR experience.

[0149] At the same time, in order to further enhance the picture quality, the embodiment also adopts ASW technology. Through in-depth analysis of the previously rendered picture, the ASW technology can accurately detect motion information and predict the position of scene elements in the next frame accordingly. This prediction mechanism makes the picture of the second projection more accurate after complete rendering, thereby greatly improving the dynamic visual effect of the VR scene.

[0150] Through the embodiments provided by the present application, it is possible to effectively reduce the abnormal situations such as visual tailing or picture jumping that may occur during the streaming process of VR games or applications, especially in high-load situations. The main purpose of this improvement is to improve the compatibility of VR streaming in different hardware performance environments, especially for those with relatively low hardware performance, so as to ensure that a wider range of users can enjoy a smooth and stable VR experience, which means that users can obtain a smoother and non-jumping visual experience when experiencing VR content, whether on high-performance or low-performance hardware devices.

[0151] It can be understood that in the specific embodiments of the present application, user information and other related data are involved. When the above embodiments of the present application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0152] It should be noted that, for the foregoing method embodiments, in order to simply describe, they are all expressed as a series of action combinations, but those skilled in the art should know that the present application is not limited to the action sequence described, because according to the present application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0153] According to another aspect of the embodiments of the present application, a frame rate control device for implementing the virtual game frame rate control method described above is also provided. As shown in FIG. 5, the device includes:

[0154] The first obtaining unit 502 is configured to obtain an average rendering time consumption of the virtual game in a case where the running parameter of the virtual game meets a frame rate control condition, where the average rendering time consumption is used to represent an average time consumption of rendering each frame of picture of the virtual game in a historical time period.

[0155] The first adjusting unit 504 is configured to adjust a rendering period of the virtual game to match the average rendering time consumption in response to the average rendering time consumption being greater than a per-frame rendering time consumption set for the virtual game, where the rendering period is used to indicate a time interval between starting and completing rendering of the i-th frame of picture and starting rendering of the (i+1)-th frame of picture, the i-th frame of picture and the (i+1)-th frame of picture being any adjacent frames in the virtual game.

[0156] The specific embodiments can refer to the examples shown in the above-described frame rate control method of the virtual game, which will not be described herein again in this example.

[0157] As an optional solution, the apparatus further includes a second obtaining unit configured to obtain a CPU preprocessing time, a CPU drawing submission time consumption, and a GPU rendering execution time of the virtual game before obtaining the average rendering time consumption of the virtual game, where the CPU preprocessing time is used to represent a time consumed by the CPU in performing preparation work before rendering in the historical time period, the CPU drawing submission time consumption is used to represent a time consumed by the CPU in preparing and submitting a graphics drawing command to the GPU in the historical time period, and the GPU rendering execution time is used to represent a time consumed by the GPU in receiving the graphics drawing command to completing the rendering work in the historical time period.

[0158] The first obtaining unit 502 includes a first obtaining module configured to obtain the average rendering time consumption according to the CPU preprocessing time, the CPU drawing submission time consumption, and the GPU rendering execution time.

[0159] The specific embodiments can refer to the examples shown in the above-described frame rate control method of the virtual game, which will not be described herein again in this example.

[0160] As an optional solution, the first obtaining module includes:

[0161] A first obtaining sub-module is configured to obtain the CPU preprocessing time, the CPU drawing submission time consumption, and the GPU rendering execution time, and a total sum of accumulated time in a 1-second time period, where the historical time period includes the 1-second time period.

[0162] A second obtaining sub-module is configured to obtain a target frame number of the virtual game rendered in the 1-second time period.

[0163] A first determining module is configured to determine a ratio between the total sum of accumulated time and the target frame number as the average rendering time consumption.

[0164] Specific embodiments can refer to the examples shown in the above-mentioned frame rate control method for virtual games, which will not be described here again in this example.

[0165] As an optional solution, the second acquisition unit comprises:

[0166] The second determination module is configured to determine, as the CPU preprocessing time, a time length from the time when the first function is called to the time when the second function is called to start rendering.

[0167] The third determination module is configured to determine, as the CPU drawing submission time consumption, a time length from the time when the second function is called to start rendering the current frame to the time when the third function is called to submit the rendered texture.

[0168] The fourth determination module is configured to determine, as the GPU rendering execution time, a time length from the time when the third function is called to submit the rendered texture to the time when the GPU completes all texture drawing work.

[0169] Specific embodiments can refer to the examples shown in the above-mentioned frame rate control method for virtual games, which will not be described here again in this example.

[0170] As an optional solution, the device further comprises:

[0171] The optimization unit is configured to, after adjusting the rendering period of the virtual game to match the average rendering time consumption, in the case where the rendering period is greater than or equal to a preset threshold, optimize the screen content of the next frame of the current frame according to the screen content of the current frame. Specific embodiments can refer to the examples shown in the above-mentioned frame rate control method for virtual games, which will not be described here again in this example.

[0172] As an optional solution, the optimization unit comprises:

[0173] The second acquisition module is configured to acquire a first dynamic element and a first static element in the screen content of the current frame.

[0174] The first prediction module is configured to predict a position feature of the first dynamic element in the screen content of the next frame, and optimize a second dynamic element in the screen content of the next frame using the position feature.

[0175] The second prediction module is configured to predict a visual feature of the first static element in the screen content of the next frame, and optimize a second static element in the screen content of the next frame using the visual feature.

[0176] The specific embodiments can refer to the examples shown in the above-mentioned frame rate control method of the virtual game, which will not be repeated here in this example.

[0177] As an optional solution, the device further comprises:

[0178] The second adjustment unit is configured to, in a case where the running parameter of the virtual game does not satisfy the frame rate control condition, adjust the rendering period to match the per-frame rendering time consumption set for the frame rate of the virtual game.

[0179] The specific embodiments can refer to the examples shown in the above-mentioned frame rate control method of the virtual game, which will not be repeated here in this example.

[0180] As an optional solution, the second adjustment unit comprises:

[0181] The adjustment module is configured to, in a case where the running mode of the virtual game is switched from the first mode to the second mode, determine that the running parameter of the virtual game does not satisfy the frame rate control condition, wherein the first mode is a game mode that satisfies the frame rate control condition, and the second mode is a game mode that does not satisfy the frame rate control condition.

[0182] The specific embodiments can refer to the examples shown in the above-mentioned frame rate control method of the virtual game, which will not be repeated here in this example.

[0183] According to another aspect of the embodiments of the present application, an electronic device for implementing the above-mentioned frame rate control method of the virtual game is further provided, which can be but is not limited to the user device 102 or the server 112 shown in FIG. 1. The present embodiment takes the user device 102 as an example, and further as shown in FIG. 6, the electronic device comprises a memory 602 and a processor 604, the memory 602 stores a computer program, and the processor 604 is configured to execute the steps in any one of the above-mentioned method embodiments by the computer program.

[0184] Optionally, in the present embodiment, the above-mentioned electronic device can be located in at least one of the plurality of network devices in the computer network.

[0185] Optionally, in the present embodiment, the above-mentioned processor can be configured to execute the following steps by the computer program:

[0186] S1, in a case where the running parameter of the virtual game satisfies the frame rate control condition, obtaining the average rendering time consumption of the virtual game, wherein the average rendering time consumption is used to represent the average time consumption of rendering each frame of picture of the virtual game in a historical time period;

[0187] S2, in response to the average rendering time consumption being greater than a per-frame rendering time consumption set for the virtual game according to a frame rate setting, adjusting a rendering period of the virtual game to match the average rendering time consumption, wherein the rendering period is used to indicate a time interval between starting rendering of an i-th frame and completing rendering to starting rendering of an i+1-th frame, the i-th frame and the i+1-th frame being any adjacent frames in the virtual game.

[0188] Optionally, those skilled in the art can understand that the structure shown in FIG. 6 is only schematic, and FIG. 6 does not limit the structure of the electronic device. For example, the electronic device can further include more or fewer components (such as a network interface) than those shown in FIG. 6, or have a different configuration from that shown in FIG. 6.

[0189] The memory 602 can be used to store software programs and modules, such as program instructions / modules corresponding to the frame rate control method and device of the virtual game in the embodiments of the present application. The processor 604 executes various functions and data processing by running the software programs and modules stored in the memory 602, that is, implements the frame rate control method of the virtual game described above. The memory 602 can include a high-speed random access memory, and can further include a non-volatile memory such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory 602 can further include a memory remotely arranged with respect to the processor 604, which can be connected to the electronic device through a network. Examples of the network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof. Specifically, the memory 602 can be used to store information such as average rendering time consumption, frame rate setting, and rendering period, but is not limited to this. As an example, as shown in FIG. 6, the memory 602 can include the first acquisition unit 502 and the first adjustment unit 504 in the frame rate control device of the virtual game, but is not limited to this. In addition, other module units in the frame rate control device of the virtual game can also be included, but are not limited to this, and will not be described in detail in this example.

[0190] Optionally, the transmission device 606 is used to receive or send data via a network. Specific examples of the network can include wired networks and wireless networks. In one example, the transmission device 606 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices and routers through a network cable to communicate with the Internet or a local area network. In one example, the transmission device 606 is a radio frequency (Radio Frequency, RF) module, which is used to communicate with the Internet in a wireless manner.

[0191] In addition, the electronic device further includes a display 608 configured to display the average rendering time, the frame rate setting, and the rendering period, and the like, and a connection bus 610 configured to connect the various module components in the electronic device.

[0192] In other embodiments, the user device or the server can be a node in a distributed system, where the distributed system can be a blockchain system, which can be a distributed system formed by the plurality of nodes connected through network communication. Wherein, the nodes can form a peer-to-peer network, and any form of computing device, such as a server, a user device, and the like, can become a node in the blockchain system by joining the peer-to-peer network.

[0193] According to an aspect of the present application, a computer program product is provided, which includes computer programs / instructions containing program codes for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network through a communication part, and / or installed from a removable medium. When the computer program is executed by a central processing unit, various functions provided by the embodiments of the present application are performed.

[0194] The above-mentioned sequence numbers of the embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0195] It should be noted that the computer system of the electronic device is only an example, and should not limit the functions and use range of the embodiments of the present application.

[0196] The computer system includes a central processing unit (CPU), which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) or programs loaded from a storage part to a random access memory (RAM). In the random access memory, various programs and data required for system operation are also stored. The central processing unit, the read-only memory, and the random access memory are connected to each other through a bus. An input / output interface (I / O interface) is also connected to the bus.

[0197] The following components are connected to the input / output interface: an input section including a keyboard, a mouse, etc.; an output section including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), etc., and a speaker, etc.; a storage section including a hard disk, etc.; and a communication section including a network interface card such as a local area network card, a modem, etc. The communication section performs communication processing via a network such as the Internet. A drive is also connected to the input / output interface as necessary. A removable media such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive as necessary, so that a computer program read out from it is installed in the storage section as necessary.

[0198] In particular, according to embodiments of the present application, the processes described in the various method flowcharts can be implemented as a computer software program. For example, embodiments of the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program code for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via the communication section, and / or installed from a removable media. When the computer program is executed by the central processing unit, various functions defined in the system of the present application are performed.

[0199] In addition, embodiments of the present application also provide a storage medium for storing a computer program for executing the method provided by the above-mentioned embodiments.

[0200] Optionally, in the present embodiment, the above-mentioned computer readable storage medium can be configured to store a computer program for executing the following steps:

[0201] S1, in the case where the running parameter of the virtual game meets the frame rate control condition, obtaining an average rendering time consumption of the virtual game, wherein the average rendering time consumption is used to represent the average time consumption of rendering each frame of picture in a historical time period of the virtual game;

[0202] S2, in response to the average rendering time consumption being greater than the rendering time consumption per frame set for the virtual game, adjusting a rendering period of the virtual game to match the average rendering time consumption, wherein the rendering period is used to indicate the time interval between the start of rendering and the completion of the rendering of the i-th frame of picture and the start of rendering of the i+1-th frame of picture, the i-th frame of picture and the i+1-th frame of picture being any adjacent frames in the virtual game.

[0203] Embodiments of the present application also provide a computer program product comprising a computer program which, when executed on a computer, causes the computer to perform the method provided by the above-mentioned embodiments.

[0204] Optionally, in the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined target, and can be implemented entirely or partially by using software, hardware (such as a processing circuit or a memory) or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an integral module or unit that includes the functions of the module or unit.

[0205] Optionally, in the embodiments of the present application, a person of ordinary skill in the art can understand that all or part of the steps of the various methods in the above embodiments can be completed by instructing the hardware related to the electronic device through a program, and the program can be stored in a computer readable storage medium, and the storage medium can include a flash disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0206] The serial numbers of the above embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0207] The integrated units in the above embodiments, if implemented in the form of software function units and sold or used as independent products, can be stored in the above computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the parts that contribute to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a plurality of instructions for causing one or more computer devices (which can be personal computers, servers or network devices, etc.) to execute all or part of the steps of the embodiments of the present application.

[0208] In the above embodiments of the present application, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0209] In the several embodiments provided by the present application, it should be understood that the disclosed user equipment can be implemented in other ways. Among them, the above-mentioned device embodiments are only schematic, for example, the division of units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed mutually can be indirect coupling or communication connection through some interface, unit or module, and can be electrical or other forms.

[0210] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0211] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0212] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A frame rate control method of a virtual game, the method being performed by an electronic device, the method comprising: in a case where a running parameter of the virtual game satisfies a frame rate control condition, obtaining an average rendering time consumption of the virtual game, wherein the average rendering time consumption is used to represent an average time consumption of rendering each frame of picture in a historical time period of the virtual game; in response to the average rendering time consumption being greater than a per-frame rendering time consumption set for a frame rate of the virtual game, adjusting a rendering period of the virtual game to match the average rendering time consumption, wherein the rendering period is used to indicate a time interval between starting rendering of an i-th frame of picture and completing rendering of an i+1-th frame of picture, the i-th frame of picture and the i+1-th frame of picture being any adjacent frames in the virtual game.

2. The method of claim 1, before the obtaining the average rendering time consumption of the virtual game, the method further comprising: obtaining a CPU preprocessing time consumption, a CPU drawing submission time consumption, and a GPU rendering execution time consumption of the virtual game, wherein the CPU preprocessing time consumption is used to represent a time consumed by a CPU in a preparation work before performing rendering in the historical time period, the CPU drawing submission time consumption is used to represent a time consumed by the CPU in preparing and submitting a graphics drawing command to a GPU in the historical time period, and the GPU rendering execution time consumption is used to represent a time consumed by the GPU in receiving the graphics drawing command to completing rendering work in the historical time period; the obtaining the average rendering time consumption of the virtual game comprises: obtaining the average rendering time consumption according to the CPU preprocessing time consumption, the CPU drawing submission time consumption, and the GPU rendering execution time consumption.

3. The method of claim 2, the obtaining the average rendering time consumption according to the CPU preprocessing time consumption, the CPU drawing submission time consumption, and the GPU rendering execution time consumption comprises: obtaining a cumulative time sum of the CPU preprocessing time consumption, the CPU drawing submission time consumption, and the GPU rendering execution time consumption in a 1-second time period, wherein the historical time period comprises the 1-second time period; obtaining a target frame number of the virtual game rendered in the 1-second time period; determining a ratio between the cumulative time sum and the target frame number as the average rendering time consumption.

4. The method of claim 2, the obtaining the CPU preprocessing time consumption, the CPU drawing submission time consumption, and the GPU rendering execution time consumption of the virtual game comprises: determining a time length from a time when a first function is called to a time before a second function starts rendering as the CPU preprocessing time consumption, wherein the first function is used to make an application of the virtual game wait for a rendering opportunity to start rendering before rendering a current frame, and the second function is used to mark a start of a rendering process after confirming the rendering opportunity, so that the application starts preparing and submitting rendering data for the current frame. determine a CPU drawing submission time period as a time period from when the second function is called by the virtual game to when a third function is called to submit a rendered texture, wherein the third function is used to mark the end of rendering of the current frame and submit rendered image data; determine a GPU rendering execution time period as a time period from when the GPU starts to receive the graphics drawing commands after the third function is called by the virtual game to when the GPU completes all texture drawing work.

5. The method of claim 1, after the rendering period of the virtual game is adjusted to match the average rendering time period, the method further comprises: in a case where the rendering period is greater than or equal to a preset threshold, optimizing picture content of a next frame of the current frame according to picture content of the current frame.

6. The method of claim 5, the optimizing picture content of the next frame of the current frame according to picture content of the current frame comprises: obtaining a first dynamic element and a first static element in the picture content of the current frame; predicting a position feature of the first dynamic element in the picture content of the next frame and optimizing a second dynamic element in the picture content of the next frame using the position feature; predicting a visual feature of the first static element in the picture content of the next frame and optimizing a second static element in the picture content of the next frame using the visual feature.

7. The method of any one of claims 1 to 6, the method further comprises: in a case where a running parameter of the virtual game does not satisfy a frame rate control condition, adjusting the rendering period to match the per-frame rendering time period.

8. The method of claim 7, the method further comprises: in a case where a mode in which the virtual game runs is switched from a first mode to a second mode, determining that the running parameter of the virtual game does not satisfy the frame rate control condition, wherein the first mode is a game mode that satisfies the frame rate control condition and the second mode is a game mode that does not satisfy the frame rate control condition.

9. A frame rate control device for a virtual game, comprising: a first obtaining unit configured to, in a case where a running parameter of a virtual game satisfies a frame rate control condition, obtain an average rendering time period of the virtual game, wherein the average rendering time period is used to represent an average time period for rendering each frame of pictures of the virtual game in a historical time period; a first adjusting unit configured to, in a case where the average rendering time period is greater than a per-frame rendering time period corresponding to a frame rate setting of the virtual game, adjust a rendering period of the virtual game to match the average rendering time period, wherein the rendering period is used to indicate a time interval between completion of rendering of each frame of pictures of the virtual game and start of rendering of a next frame of pictures.

10. A storage medium for storing a computer program, the computer program being used to execute the method of any one of claims 1 to 8.

11. A computer program product comprising a computer program which, when run on a computer, causes the computer to perform the method of any one of claims 1 to 8.

12. An electronic device comprising a memory and a processor, the memory having stored therein a computer program, the processor being arranged to perform the method of any one of claims 1 to 8 by means of the computer program.

Images