Timing in Games. What technique?
hi!
What is the best technique for constant game timing on different systems? I tried this method:
"dwStart = timeGetTime();
while ((GetTickCount() - dwStart) < 20);"
But its very choppy. Is there a better way? How is it solved in proffesional games?
(sorry if the people asked that question one million times befor, but the search function of the forum is disabled :-) )
bye chris
Hi,
use the high resolution counter instead of timeGetTime. First, get the frequency of the timer with QueryPerformanceFrequency, like this:
LARGE_INTEGER Frequency;
QueryPerformanceFrequency(&Frequency);
The function returns True if a high resolution timer exists on your system (unless you use a computer from the stone age there will be one).
Next you can get the value of the counter using QueryPerformanceCount:
LARGE_INTEGER Time;
QueryPerformanceCount(&Time);
The method I use is querying the timer during the game loop and then determining when it is time to show the next frame.
---------
http://users.pandora.be/koen.van.baelen
---------
use the high resolution counter instead of timeGetTime. First, get the frequency of the timer with QueryPerformanceFrequency, like this:
LARGE_INTEGER Frequency;
QueryPerformanceFrequency(&Frequency);
The function returns True if a high resolution timer exists on your system (unless you use a computer from the stone age there will be one).
Next you can get the value of the counter using QueryPerformanceCount:
LARGE_INTEGER Time;
QueryPerformanceCount(&Time);
The method I use is querying the timer during the game loop and then determining when it is time to show the next frame.
---------
http://users.pandora.be/koen.van.baelen
---------
Your partially on the right track. But rather than wait until the timing is correct, why not move according to the timing
OK, so that was as clear as mud. What I mean is that typically you will take how much time has passed since the last frame and move accordingly. Right now you may have your animation/movement/etc based on pixels/units per frame. Instead make it pixels/units per second. That way when you are told that it has been 0.02 seconds since the last frame (all numbers are estimates/guesses/pulled-out-of-my-ass) you can multiply that by the speed and such. So in pure POOMA psudo-code here you go:
This will move the characters position on x by the correct amount. Still clear as mud?
Always remember, you''''re unique. Just like everyone else.
OK, so that was as clear as mud. What I mean is that typically you will take how much time has passed since the last frame and move accordingly. Right now you may have your animation/movement/etc based on pixels/units per frame. Instead make it pixels/units per second. That way when you are told that it has been 0.02 seconds since the last frame (all numbers are estimates/guesses/pulled-out-of-my-ass) you can multiply that by the speed and such. So in pure POOMA psudo-code here you go:
float time_since_last_frame; //declared for example, but assumed assignedfloat units_per_second; //read above...character->Position->X += time_since_last_frame * units_per_frame;
This will move the characters position on x by the correct amount. Still clear as mud?
Always remember, you''''re unique. Just like everyone else.
Always remember, you''re unique. Just like everyone else.Greven
hi!
Thanks for the replies!
I tried the easy "units per frame" method with 120fps and it runs fluently.
Can you tell me the advantages/disadvantages of both techniques?
How fast must a computer be, to show the 120fps in an average 2D game?
bye
chris
Thanks for the replies!
I tried the easy "units per frame" method with 120fps and it runs fluently.
Can you tell me the advantages/disadvantages of both techniques?
How fast must a computer be, to show the 120fps in an average 2D game?
bye
chris
The first method, i.e. to have a constant number of frames per second, is easier for programming. Therefore I recommend you use this one, at least for your first few games.
The second method has the advantage that faster computers can simulate the game world more accurately. However, having a variable frame length can make the game a lot harder to program, therefore I really recommend you use the first method for now.
The second method has the advantage that faster computers can simulate the game world more accurately. However, having a variable frame length can make the game a lot harder to program, therefore I really recommend you use the first method for now.
quote: Original post by TekBoy
The first method, i.e. to have a constant number of frames per second, is easier for programming. Therefore I recommend you use this one, at least for your first few games.
The second method has the advantage that faster computers can simulate the game world more accurately. However, having a variable frame length can make the game a lot harder to program, therefore I really recommend you use the first method for now.
I would have to disagree. If you can understand the principles of the variable frame length it will make your games much more playable as a general rule. And if you will eventually switch later, why bother with it. At the same time, if you are really *just beginning* it may be recommended to skip that for now and get the basics down first. But again like I said, if you understand it and can implement it, go with it.
[500 error - 4 and counting]
Always remember, you''''re unique. Just like everyone else.
Always remember, you''re unique. Just like everyone else.Greven
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement