Hi guys, I''m programming a game similar graphically to worms. I have a problem though, I can''t quite work out how to go about keeping the framerate at a constant 30fps. Right now the framerate is at about 400fps (on the development machines), which i''m sure is going to drop considerably when more objects are on the screen. If anybody could steer me in the right direction I would be very grateful. Thanks Kim Watson QANTM (Game Student 101)

if you really wanna have a constant FPS, then heres how to do it:

    #include <windows.h> //needed for GetTickCount()DWORD ClockStartValue;//..then in main loopClockStartValue=GetTickCount();//.. do game processingwhile((GetTickCount()-StartClockValue)<33);//change 33 to the amount of MS to wait..33 should be fine for 30 fps    

You are thinking about this in the wrong way. A high frame rate is ALWAYS ALWAYS ALWAYS a good thing, unless of course your monitor cannot handle it, but this is very rare. A high frame rate means that your game is doing all it needs to each cycle in a very small amount of time, which is great. It means that there is more time to do other stuff, like intensify the physics system etc.

However, if your grenades are flying around the screen like lightning and your game play is so fast that it is unplayable, and downright humorous, then you are going about business in the wrong way. Ask yourself, why do the rockets in Quake 3 fly at the same speed no matter what the framerate. The answer is this; all the game object are being updated as a FUNCTION OF TIME. Instead of saying I will update the position of my rocket based on its velocity and current tradjectory every frame, i will do it every 1/100th of a second. This means that no matter what the framerate of the game, the game-play is going to be consistent.

Its quite easy to do. Create a new thread and monitor elapsing time like so:

DWORD StartValue = GetTickCount();

void UpdateGameState() { // Thread function
CurrentValue = GetTickCount();
if(CurrentValue >= StartValue + 100) {
// update game objects
StartValue = CurrentValue;
}
}

Its as simple as that, Create thread with the CreateThread function, look it up. Good luck,

NBGH: Exactly, thats how we do it

Hi there...
That method was the one i used before i looked at the DirectX SDK sample game Donuts. The method used in Donuts goes like this:

// Initialize object, this is done somewhere in the game initialization.
Object->XVel = 0.25; // Pixels per 1/1000 sec
Object->YVel = 0.25; // Pixels per 1/1000 sec

// Update the frame, done every frame.
Object->X += Object->XVel * tickDiff;
Object->Y += Object->YVel * tickDiff;

Where tickDiff is the time elapsed since last time we updated the positions.

Is this a good method or should i do like NBGH says???
I mean like this:

// Initialize object, done in initialization of the game
Object->XVel = 2;
Object->YVel = 2;

And then update the objects every 1/50 of a second.

What do you think???

-René

-OneNite- either method is cool, just so long as you don''t update a fixed amount every frame. However, in my experience, with the method your using, if your game needs to freeze at any point (to load a new sound from the hard disk realtime or whatever) then TickDiff can become very large (reletively speaking). This means that any objects that may need a say in thier movement during a locked up period may ''miss the boat'', so to speak, and end up wildly off course. I don''t know if you''ve had this problem but I have!

Threads work for me for two reasons. Firstly because they seperate the code a little bit making things a little friendlier for me to cope with, and secondly, it doesn''t matter one single bit what the rest of the program is doing. Plus, If you''re into networking, then the Thread approach will make your life MUCH easier when keeping gamestates consistent over a LAN or whatever.

Which ever approach suits you is cool, I just happen to be this way inclined