🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Timed stuffs!

Published May 27, 2008
Advertisement
First, a thanks to EasilyConfused for his much appreciated comment. :D

Today I coded in a timed delay thing into the game's main loop. This way things don't go lightning-fast on the player... it's limited to doing stuff once every 500 miliseconds now. I guess you could call each interval the game does stuff in a "frame", yes? I also added a keyboard input function, to check if there was a valid keypress, and return its virtual key identifier (for example, VK_ESCAPE)

Here's my main() function, to show you how the main loop looks so far. I think I just need to work on the actual gameplay now...

int main(){    Init(); // Sets up the HUD details and console title        bool quit = false;    int timestat = 0; // Because each frame is half a second, I need                      // a way to know when to increment the HUD's time                      // field - that is, once every two frames.        while (!quit)    {        unsigned long currtime = GetTickCount();        hud.Draw(0, 0); // The arguments specify the x,y coord of the                        // top-left corner of the HUD.            GameInfo.score += 10;            if (timestat == 0) timestat = 1;        else if (timestat == 1) { timestat = 0; GameInfo.time += 1; }            // During the delay time, when nothing is being done, I watch for        // keypresses. I used to have it outside the while, but there was        // a visible delay between pressing and exiting when the key was        // pressed after the check and during the delay. Placing it in the        // loop lets me check as many times as the while iterates per frame,        // and because the game doesn't take long to process what I have so        // far, there's no visible delay in quitting.            while (currtime+500 > GetTickCount())            if (CheckForKeypress() == VK_ESCAPE)            {                quit = true;                break;            }    }	}


EDIT: If you're wondering, and I'm sure you are, the game looks no different now than a month ago. The only differences are internal, except that I'm actually displaying the game's data in the HUD, not just the "static" lines. Nothing new though, just zeroes! (Although I use a line of six zeroes as a static to the right of the Score line, so it looks like we've got a sort of zerofilled score going on when the score is drawn on top of it. I likey.)
Previous Entry Update so far
Next Entry Timers
0 likes 5 comments

Comments

Metorical
I missed the original posts so please forgive me if this comment seems out of place?

Is your goal to achieve a fixed 'frame-rate' simulation? I suspect this is what you're doing (at 2fps) but if you're just trying to change the speed the game runs for your computer then shouldn't you just be basing your updates on the time elapsed?
May 27, 2008 11:16 AM
Twisol
I'm not exactly sure, because I've never done anything like this before, but I'm just trying to keep the game going at a set speed. If a frame is missed because the game is trying to run through things - and I doubt that considering how much even WoW takes up and still gets good framerates - then it doesn't matter, because if the other entities were to move more than what the player expects, and more than the play could move, it could be a bit off.

Basically I think I'm just trying to lock it to 2fps. Also, from playing the original Snipes game I also think it just locks it at a specific fps.
May 27, 2008 02:08 PM
Metorical
Here's an example of how you'd do constant frame-rate physics.

1. Record time between physics calls.
Last call = 1.000 seconds
This call = 1.010 seconds
Time taken = 100ms

2. Divide time in to frames.

Desired frame rate = 25fps or 40ms per frame.
Maximum frames = 2 in 80ms
Remained time = 20ms

3. Do physics calc per each frame
for ( int i = 0; i < frames; ++i) {
doPhysics(25ms);
}

Notice how you do it twice with 25ms rather than once with 50ms. This helps keep things stable in simulations and consistent if you have multiple clients or are resimulating the same data.

4. Render graphics, handle input etc.

5. Next frame add remainder on... so if it takes 100ms next time then do (100+20) / 40 = 3 frames.

You might have noticed this in games before. If your computer isn't fast enough then the game gradually slows down as each frame results in more frames next time round ad infinitum.

Makes sense?
May 27, 2008 02:36 PM
Metorical
Likewise if it only takes 1 ms per game loop iteration then you'll only do a physics update every 40 iterations.

Why is this good? Because you just stick everything in the game loop


while (1) {

handleInput();
doPhysics();
renderScene();

}

then let it runs as fast as possible! You can also output how much time a physics frame is taking to see how close to the limit of your processing you are.
May 27, 2008 02:40 PM
Twisol
I'm not really sure I get what you're saying :| I mean I get the concept, but I'm not sure how it would apply to Cripes...
May 27, 2008 10:00 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement