Improved memory footprint under COCOS2DX Win32

Guess it might be in the main loop using Sleep (0), a search, sure enough to locate the specific code, it is located in the Cocos2dx\platform\win32\ccapplication.cpp, roughly as long as the following:

1	while( 1 ) {

2	if( 有消息 ) {

3	if( 时间到 ) 更新计时, call 主循环函数;

4	elseSleep(0);

5

}

6	// 其他跳出循环判断代码

7

}

In other words, the loop spends a lot of time checking messages and Sleep (0) In addition to executing mainloop.

And, I also found a strange phenomenon (it is unclear why), namely:

There is a line of code in the AppDelegate.cpp file for the Hellocpp project:

// set FPS. the default value is 1.0/60 if you don‘t call this

pDirector->setAnimationInterval(1.0 / 60);

　　

Above 60, if the change is large, does not play any role, the frame rate is always 60 will not change. But if you change to less than 60, it can work.

Thus, the idea of solving CPU usage begins with the idea of "whether the cycle accuracy can be reduced".

Normally, sleep (1) is performed and sleeps for about 1/50 seconds, which is inaccurate and inaccurate and does not seem to meet the fluency requirements of the FPS. However, if the game does not need to run at this high frame rate, such as the FPS?? The programme is feasible.

After the actual test, sleep (0) is changed to sleep (1), and then the above code 60 to 25, the effect is very significant. But here's another question: if you do a little bit more on every game loop, the time is a bit long, then the game will be slowed down.

In the original engine, the synchronization time code is as follows:

QueryPerformanceCounter(&nNow);

if(nNow.QuadPart - nLast.QuadPart > m_nAnimationInterval.QuadPart) {

nLast.QuadPart = nNow.QuadPart;

　　

Because each time in the Nlast record nnow times, and with the difference between the set interval, the time difference will often be greater than the set interval, if it is in the inaccurate Sleep (1) and the burden of each cycle is relatively large, will result in the actual duration of each frame, will exceed the set interval of many, This slows down the speed of the game if the game is timed in the frame step.

To solve this problem, I use the way of time alignment. Actually, it's a change. Update Nlast expression:

nLast.QuadPart = nNow.QuadPart - (nNow.QuadPart %m_nAnimationInterval.QuadPart);

　　

In this way, the total consumption time per frame is quite constant.

The problem solved above is not perfect.　How to maintain 0% fps can also be CPU occupied? The solution I'm considering is to modify the accuracy of Sleep (1).

Find a bit of information, found Winmm.lib Library has timebeginperiod (1);    Timeendperiod (1); The function can be used for this purpose, so that the accuracy of Sleep (1) is increased to 1 millisecond level, then the change:

1. Add a reference to the Winmm.lib library. Here I have taken the way to add #pragma comment (lib, "Winmm.lib") statement in the CCApplication.cpp header.

2. In the while (1) code snippet, put the Timebeginperiod (1) respectively before and after;  Timeendperiod (1); Statement

That would have been finished.

After testing, the frame rate is set within the 0 FPS, and the CPU can be used (i7 2600k). Set to 60, the CPU consumption will be periodically erratic floating, temporarily unknown. and set to 60+, the CPU will be 100%.

However, even if the problem is temporarily over, the program is limited to a good, smooth, no problem, the feeling is also convenient to calculate ...

Improved memory footprint under COCOS2DX Win32