An effective solution to slow loading in online game programs

For 3D video games, the performance of the game engine is crucial. When a player experiences a game, the smoothness of the game is the most basic requirement. Different from single-host games, online games need to consider performance issues because they cannot control the complexity of game elements to meet the efficiency requirements as single-host games do. A large number of players flood into the same area, and a large number of game roles on the same screen cannot be avoided. Therefore, the frame rate of the game is greatly reduced, and a large amount of system resource consumption is also difficult to avoid, this is one of the most difficult problems for online game engines. Here we will talk about the control of the frame rate of the game. Generally, players complain about the game client card. First, the average Frame Rate of the game is very low, and second, the frame rate of the game is very unstable, cause choppy. In fact, the average Frame Rate of the game is low, and the effect on players' mood is far less than that on choppy players. Even if the game has an average of 10 frames, although it is already very bad, it can still be played, but the frequent choppy gives people a bad feeling, at ordinary times, a game of about 40 frames suddenly gets stuck due to loading something, the frame rate drops to a few o'clock points, and then restores to 40 frames. This choppy feeling is annoying. The primary performance problem solved by the game engine is choppy. To solve the problem, you need to do the following: First, do not load Resources in the main thread. The most taboo operation is to open the file, which will suspend the current thread, that is to say, it will pause the rendering thread. All the resource loading operations are carried out in the loading thread. After all, the loading thread does not have to pause at will, but does not affect the rendering of the main thread, the main thread only needs to determine whether the resource has been loaded at each frame. Once we find that the data has been loaded, we can use this data for rendering. Second, it is also the most important point to spread the loading operation to multiple frames. Generally, when a role enters the crowd, or when the magic is flying on the battlefield, a large number of messages need to be sent to the server. The most typical thing is to create a message, whether it is to create a role or create a special effect, even if the multi-thread loading method is used to create an object within a frame and notify the thread to load the underlying resources, the processing of multiple messages will inevitably cause a lag. There is a very good solution here, that is, these message processing operations should not be completed within one frame, but distributed to multiple frames for completion. Generally, the process of processing a network message is such a loop: While (there is a message in the Message Queue) {retrieve the first message from the queue; process this message; delete the message from the queue.} in one frame, the entire message queue is traversed cyclically, and the messages received from this frame are processed one by one. This ignores the most important efficiency issue. When you are optimizing resource loading due to a choppy game, consider modifying the Message Queue processing. Here, I can add timing: gettickcount ()

 

Initial time = gettickcount (); While (there is a message in the Message Queue) {retrieve the first message from the queue; process this message; current time = gettickcount (); elapsed time = Current Time-initial time; If (elapsed time> 20) {break ;}} if the frame processing time exceeds 20 ms, put the remaining messages to the next frame for processing. With this timing method, you will find that the smoothness of the game has changed dramatically! Before optimization, several people were attacking a large number of monsters with group magic attacks. These guys suddenly moved into the field of view, and the frame rate dropped to a few points at zero, the game experienced severe choppy events, which lasted for a short period of time and quickly increased the frame rate. Now, after modification, you will find that those guys appear smoothly in the field of view without a trace of lag. This effect is simply a miracle, and it's just a few changes.Code. Now we are considering the problems brought about by doing so. If the message volume is very large, the machine is slow, and the average frame rate is very low, the trouble is very high: the amount of messages processed per frame has not been received yet. This is a very serious problem, which will make the client performance seriously different from the actual situation. Here, we need a mechanism to ensure that messages can be processed in a timely manner when they accumulate more than a certain number of messages:

initial time = gettickcount (); While (there are messages in the Message Queue) {If (number of messages in the message queue> 300) {process all messages at a time;} else {retrieve the first message from the queue; process this message; current time = gettickcount (); after time = Current Time-initial time; If (after time> 20) {break ;}}this solves the problem of more and more accumulated messages, when more messages are collected, all messages are processed at one time. However, this will also bring about a problem, that is, when there are too many messages to be processed on machines with a low frame rate, there will be a periodic lag. The reason for choppy is the one-time processing of all messages in that step. The purpose of optimization is to avoid such freezing. For low-end machines, such optimization is not only ineffective, but increases the freezing phenomenon. To make up for the disadvantages brought by this method, we need to do something for that time after 20 ms:

static time threshold = 20; // note that the time threshold is static if (the number of messages in the message queue is greater than 100) {++ time threshold;} else {-- time threshold;} If (time threshold <20) time Threshold = 20; If (time threshold> 40) time threshold = 40;

initial time = gettickcount (); While (there are messages in the Message Queue) {If (number of messages in the message queue> 300) {process all messages at a time;} else {retrieve the first message from the queue; process this message; current time = gettickcount (); after time = Current Time-initial time; If (after time> time threshold) {break ;}}here the static variable time threshold is added, replacing 20 in the previous code, it becomes a variable value determined by the number of message packets of the current frame. When the number of message packets of the current frame exceeds one value, this time threshold is added. Otherwise, the value is reduced by one. In this way, the more message packets, the longer each frame is used to process the message. That is to say, the proportion of message processing time is gradually increasing. In this way, the possibility that the number of messages exceeds the upper limit can be greatly reduced. In the worst case, if there is still a cyclical lag, this machine is really not suitable for running this game. Let's just move back and skip this optimization, this machine is still stuck playing this game. :) Of course, the time threshold range and the maximum number of message packets can be adjusted to suit different games.