With the rapid growth of computer speed, the software running is getting faster and faster. But this is not necessarily a good thing in some cases. Games are in different machines, or in different environments that cannot be kept at the same way, the game programmer is plagued. Especially RPG games, running on a relatively high-grade machine, press the keyboard, the protagonist in the game is faster. Even if this doesn't bring trouble to the player, it is also unable to tolerate in the eyes of the very picky player.
Norbightly, a game must maintain the same frame number on all machines, even if you want to implement it. In fact, as long as the frequency of the game role movement is almost the same. You will think about the movement of the object in the game with a certain frequency. A direct idea is to directly put the control function in the clock interrupt function. But imagine ... don't kid, this is absolutely no. The clock interrupt function is not too complicated, and the interrupt function must be guaranteed. In addition to this, think about the data touched by the clock interrupt function in the protection mode (now the game is a protective mode programming), how many questions will this bring?
Therefore, the comparison real-time method is to do two counters. One is incremented in a fixed frequency in the clock interrupt, and the other has incremented with each game cycle. The previous amount indicates that the number of game cycles should be done so far, and it usually incremented speed should be greater than the former; then one is the number of game cycles that have been completed. In the main loop of the game program, we will repeatedly compare these two quantities. If the actual game cycle is behind, let it continue until the number of cars should do. Otherwise, we should stop immediately, you can wait or do other things, such as displaying a frame of images. Why choose a picture picture? Part of the reason is that this work is usually slow, it takes a period of time, which makes the actual game cycle return to the number of game cycles should be made; in addition, some reason is that this process also includes the process of waiting for the screen vertical removal process, in During this time, the clock interrupt function is also incrementing counter at the correct frequency. Of course, we can't continue to handle it when the two counters are equal; and must wait until the drawing is finished. But when we spend the picture, you can clearly know how many time game cycles need to keep up with it.
The rough example of the above algorithm is given below: (Quote Examples of Allegro Vivce 9.4.3 in Grorge Foot)
Volatile Int Target_Cycle;
void target_incrementor ()
{
Target_cycle ;
}
End_of_function (target_incrementor);
Int actual_cycle;
Int end_game;
Void Game_LOOP ()
{
Lock_variable (target_cycle);
Lock_function (target_incrementor);
Install_int_ex (target_incrementor, bps_to_timer (cycles_per_sec);
END_GAME = 0;
actual_cycle = target_cycle = 0; / * Initialization * /
Do {
Draw_one_frame (); / * Draw a frame of Figure * /
While (target_cycle> actual_cycle) / * If the actual backward * /
Do_ONE_GAME_CYCLE (); / * Take a game loop * /
} while (! "
}
Draw_one_frame draws a frame painting, if you need to perform vertical removal synchronization. Do_one_game_cycle is the completion of a game loop, and accumulates `actual_cycle'.cycles_per_sec variable to save the number of target game cycles per second. If you have used Allegro. Other There should be no problem, regarding the Allegro function involved in the program, please review the Allegro VivAceSecion 9.4.3 Regular Game Speed in the Allegro VivassSecion 9.4.3 Regular Game Speed in the Allegro VivassSecion 9.4.3 Regular Game Speed in George Foot
