PDA

View Full Version : please help me to control my game speed



raaji
06-01-2011, 04:12 PM
hello

i am new in game programming, i use openGL with c++, my problem is controling my game speed.

when i run the game program in vc++ after i start my PC, it goes in a regular speed in the first time but if i run it again, often it goes very speed, my game release also goes very speed, so i hope you can help me in controling the speed for the game.

thank you in advance.

BionicBytes
06-02-2011, 02:32 AM
Decouple game logic from your rendering loop. Perhaps use a timer to call the game logic every 30ms or something.

NeuroFuzzy
06-02-2011, 04:46 AM
I'd use ctime.h and Windows.h, for the commands clock() and Sleep(somenumber), respectively.

clock() returns the time in milliseconds, and Sleep(somenumber) waits for a number of milliseconds. Using these two functions, you can regulate the framerate:


int lastTick=clock();
int fps=30;
...

function updateDelay()
{
int elapsed=clock()-lastTick;
if(elapsed<1000/fps)
Sleep((1000/fps)-elapsed);
lastTick=clock();
}



Also, I'm guessing english isn't your first language, so as a tip: speed is a noun, fast is an adjective, so,
"but if I run it again, often it goes very fast, my game release also goes very fast, so I hope you can help me in controlling the speed for the game."
(just helping, not being a grammar nazi xD)

mhagain
06-02-2011, 05:26 AM
I wouldn't use Sleep in a game loop. Sleep doesn't guarantee that you're going to sleep for the time you specify; that's just a minimum guaranteed time. You could sleep for that amount of time, or you could sleep for a whole lot longer. The timer resolution is also low by default, so Sleep (1) may actually end up sleeping for 10 or more milliseconds.

http://msdn.microsoft.com/en-us/library/ms686298%28v=vs.85%29.aspx


Note that a ready thread is not guaranteed to run immediately. Consequently, the thread may not run until some time after the sleep interval elapses.

BionicBytes gave the correct solution, although I wouldn't fire it based on a timer either. Instead use a high precision timer, each pass through your loop use it to measure how much time has passed since the previous pass, and use that amount of time as a factor in your update calculations.

raaji
06-02-2011, 07:21 AM
Decouple game logic from your rendering loop. Perhaps use a timer to call the game logic every 30ms or something.

thank you BionicBytes i will try that


I'd use ctime.h and Windows.h, for the commands clock() and Sleep(somenumber), respectively.

clock() returns the time in milliseconds, and Sleep(somenumber) waits for a number of milliseconds. Using these two functions, you can regulate the framerate:


int lastTick=clock();
int fps=30;
...

function updateDelay()
{
int elapsed=clock()-lastTick;
if(elapsed<1000/fps)
Sleep((1000/fps)-elapsed);
lastTick=clock();
}



thank you NeuroFuzzy i will try this too.



Also, I'm guessing english isn't your first language, so as a tip: speed is a noun, fast is an adjective, so,
"but if I run it again, often it goes very fast, my game release also goes very fast, so I hope you can help me in controlling the speed for the game."
(just helping, not being a grammar nazi xD)

ha ha ha, i liked you, thank you very much for the help, you are right english is not my first language.
actualy i am searching for a teacher :D , or somefriends that speak english to learn from them.


I wouldn't use Sleep in a game loop. Sleep doesn't guarantee that you're going to sleep for the time you specify; that's just a minimum guaranteed time. You could sleep for that amount of time, or you could sleep for a whole lot longer. The timer resolution is also low by default, so Sleep (1) may actually end up sleeping for 10 or more milliseconds.

http://msdn.microsoft.com/en-us/library/ms686298%28v=vs.85%29.aspx


Note that a ready thread is not guaranteed to run immediately. Consequently, the thread may not run until some time after the sleep interval elapses.

BionicBytes gave the correct solution, although I wouldn't fire it based on a timer either. Instead use a high precision timer, each pass through your loop use it to measure how much time has passed since the previous pass, and use that amount of time as a factor in your update calculations.

thank you mhagain i will try what you suggested


Instead use a high precision timer


could you suggest one please.

thank you all you really gave me the best of the best

NeuroFuzzy
06-02-2011, 02:10 PM
Huh... isn't it still wise to use a function similar to what I posted (with different clock() and sleep() implementations) to keep away from unnecessary 100% cpu usage

raaji
06-02-2011, 04:33 PM
it seems a good way and i started working with it but i only like to try many methods and compare them to see which one is the best and so i use it.

thank you NeuroFuzzy

mhagain
06-02-2011, 05:30 PM
Huh... isn't it still wise to use a function similar to what I posted (with different clock() and sleep() implementations) to keep away from unnecessary 100% cpu usage
For a game loop you actually want your CPU to be going flat-out, otherwise you've got a real-time app that's not actually real-time. You definitely don't want to be sleeping while the player is moving the mouse and expecting a response, and you want those CPU cycles to be doing useful things like updating physics or sound. Not using them in this kind of scenario is actually wasting them: they're a resource that's there and that could be used for useful things, but it's not being used - ergo, wasted.

Making the shift from being CPU-bound to being GPU-bound is the most effective way of regulating CPU usage. Sleeping is not, and the problems of guaranteed minimum time only and of timer precision still need to be addressed.

If it's not a game the rules are different, but the OP did ask about "game speed".




Instead use a high precision timer


could you suggest one please.

On Windows you have two main options: timeGetTime or QueryPerformanceCounter. timeGetTime can be set to a max of 1 millisecond resolution (via timeBeginPeriod), which may or may not be enough, but has the advantage that it's absolutely rock-solid under all circumstances. QueryPerformanceCounter has much better resolution but can have problems with inconsistent results on some CPUs. So you need to pick which tradeoff is most acceptable to you.

There are plenty of examples of the usage of both on the web, and we're drifting into non-OpenGL territory so it's best to leave it at that.

raaji
06-03-2011, 08:25 AM
There are plenty of examples of the usage of both on the web, and we're drifting into non-OpenGL territory so it's best to leave it at that.

thank you mhagain for the infos about the functions (timeGetTime and QueryPerformanceCounter), what you said is enough, the rest is easy.


Decouple game logic from your rendering loop. Perhaps use a timer to call the game logic every 30ms or something.

actualy i still useing the program struture that is used in nehe's opengl tutorials where he use the function WinMain as the main function of the program and DrawGLScene for drawing the Scene and other functions that are for creating and killing the window and resizing the scene and ....

are these two functions ,WinMain and DrawGLScene, together my rendering loop or what is it?

could you help me briefly to know what is a game logic and what is not a game logic in order to separate them in my game code.

BionicBytes
06-03-2011, 10:19 AM
Anything to do with drawing is not game logic.
Drawing should be a process which reads memory (eg sending a vertex array to OpenGL).
If you need to change your vertex arrays each frame, or every n frames, then building the new vertex arrays is something which you should remove from the code which handles the 'main drawing'. Hence you have just decoupled frame updates from frame rendering.

Now imaging you are animating characters. Updating their positions, rotations, colours, etc is a write process to some memory. This should be decoupled from any rendering code, so that postentially, one thread could be performing an update to your game world, whilst another thread could be reading those memeory contents in order to render them to the screen. Thus game 'logic' would be the process of writing to memory locations to update the 'world', eg clocks, animation, character positions, collision detection, etc.

raaji
06-03-2011, 04:46 PM
thank you BionicBytes, the idea is clear 100%.
now i am going to test GL functions, i sill at the start of the way, i hope the trip will be easy :cool: