Home

Blogs

Forums

News

Portfolios

Projects

Tutorials

13 users logged in

New? Learn about game development.

Before posting, review our community guidelines.

Support GameDev.net with a monthly GDNet+ subscription!

Chat in the GameDev.net Discord!

Back to Hands-On Interactive Game Development

04.06 - It's About Time...

Teej · 2001-08-07T15:29:02

Timing is Everything Without some facility for keeping track of time in our game, we frankly wouldn't have a game in the first place -- nothing would be able to properly move. Our game engine (GAMEMAIN.CPP) is designed to be executed as often as possible, and we're coding our game engine on the premise that each iteration of Game_Main() equates to one frame of animation. So, dear reader, how many frames a second does Game_Main() run? Don't worry, I don't know either. The fact is, the sooner our game can finish executing Game_Main() , the sooner it can be called again, and even this assumes that Game_Main() takes the same amount of time to run every frame (which it won't), and that there aren't any Windows messages to process (which there will be). In other words, the number of times Game_Main() is called in a second is variable. We're going to want to move objects in our game. Movement is really just drawing an object at a different location (offset) from where it was previously being displayed. If we had such an object, say a missile, and moved it one pixel to the right every frame, what would we see? Our missle wouldn't be moving at a steady pace, as that would require that our frames were being displayed at a steady rate. We wouldn't be able to dictate the speed of our missile either, as the more frames-per-second there are, the farther the missle would travel. What you'd end up with is your missile flying at different speeds on different machines, and sporatically speeding-up and slowing-down frame-by-frame. This will not do. There are two common methods of rectifying this situation. One is to regulate how many times a second Game_Main() gets to run, thereby providing a constant frame rate. The other involves planning all movement in terms of real-world velocity (e.g. 10 pixels per second), and keeping track of when it's time to move an object, regardless of what frame it is. I think that it's worth the time to investigate each of these methods a bit further before we settle upon what we'll be using... (1) Constant Frame Rate This method, quite simply, forces Game_Main() to be executed a constant number of times per second. The general idea is to calculate how long Game_Main() takes to run (on a frame-by-frame basis), and add in a delay (if necessary). For example, if we wanted our game to run at 30 frames per second, Game_Main() would have to take 33 milliseconds (msec.) on each iteration. If during one such iteration we found that we took 25 msec. to execute, we would simply force Game_Main() to sleep an additional 8 msec. before finishing. To be more precise, we'd include the overhead cost of the Windows' message loop as well, and say that "It should take 33 msec. to get from the end of Game_Main() to the end of Game_Main() again". The way I see it (and yes, I'm speaking personally), there's one major problem with this method, which has to do with the quality of the animation overall -- if the user's machine can handle 60 frames per second, it seems odd that we're doing so much 'sleeping' in our main game code. As an illustration, imagine that our little missile would like to move at 60 pixels a second. Now, because our game is locked-down at 30 FPS, our missile has to be drawn two pixels over every frame. But, if our game was running at 60FPS, the missile would only be drawn one pixel over each frame -- wouldn't that look nicer, rather than skipping pixels? (2) Time-Based Movement In this scenario, Game_Main() is left to run as many times as it possibly can, but keep in mind that we don't have a constant frame rate any more -- we can't move x pixels per frame, for instance. What we do have though is a game that will run as fast as the user's machine will let it, allowing them to enjoy a better quality of animation. The trick here is to plan all movement in terms of physical time. If I wanted our missile to move at 60 pixels per second, it needs to travel 60 pixels regardless of how many frames were available to move it in. What this involves, in a nutshell, is the ability to keep track of the last time the missile has moved, and see if enough time has elapsed since then in order to move it again. If the missile is moving faster than the frame rate, we'd be checking to see how many pixels the missile has to move this frame in order to be moving at the proper rate of speed. Think about it -- the better the frame rate, the smoother the animation, and everything moves at the proper speed regardless. Excuse Me, Do You Have the Time? There are plenty of ways to get time information from the operating system, but only one of them really shines out for our purposes. Since we're living in the realm of milliseconds, we need a fairly precise timer -- Windows WM_TIMER messages are definitely out of the question. GetLocalTime() does in fact provide the current time right down to the millisecond, but for reasons that will become clear in a moment, this is a bad choice as well. What we're looking for is not the current time, but a relative time. We want to be able to ask the operating system for some time value twice, and be able to tell how many milliseconds have elapsed between the two calls. As you'll soon see, this is all that we need. It turns out that there are three possiblities: multimedia timers, high-resolution timers, and the system timer. The documentation for high-resolution timers suggests that not all machines have the proper capability, so we'll discount that as an option. Of the other two, timeGetTime() and GetTickCount() , either will suit our purpose (and are available on Win95/98/NT/2K). The issue with time functions such as GetTickCount() and timeGetTime() is their resolutuion, i.e. how quickly you can call them in succession and get accurate numbers. If for instance a function can't be called twice within 50 msec., it isn't going to help us if we need to time intervals less than 50 msec. Of the two possible functions, it turns out that timeGetTime() offers the best resolution and machine independance, so that's what we'll be using. It should be noted that these are DWORD (32-bit) values, which means that they'll roll over (start over at 0) 49.7 days after the user's machine was started, so we'll either have to check for this situation in our code, or ignore it and hope that our game isn't running at that time. This all boils down to a few extra cycles devoted every frame for this check, and I'd be interested to see how many game developers bother with it... So, how do we solve all of our timing problems with timeGetTime() ? Like so: Game_Main() { static DWORD lastTickCount = timeGetTime(); DWORD thisTickCount; // Timing thisTickCount = timeGetTime(); G.diffTickCount = thisTickCount - lastTickCount; lastTickCount = thisTickCount; // .. // Game code // ... } The variable lastTickCount is static, which means that it keeps its value between function calls. The first time Game_Main() is called, lastTickCount is set to the current millisecond count, and every other time Game_Main() is called it will still be holding whatever it was when Game_Main() ended the last time. What the timing code accomplishes is to get not only the current time, but the difference between the current time now and the current time last Game_Main() iteration. What we're left with in our new global variable diffTickCount is the number of milliseconds that have elapsed since our last time processing our game code, which can in turn be used to check against sprite movement, or anything else we're timing. Go through this sample a few times in your head, pretending that the game code takes 10 msec. to run, and convince yourself that G.diffTickCount always makes the proper elapsed time available to the rest of our game. By the way, that's why it's a global variable and not local -- other functions (and there will be more in the future) will need to access this value as well. Let's take a look at how this delta (difference in times between frames) can be actually used. Say that our little missile would like to move one pixel per second (a very slow missile indeed). First, we need a variable to keep track of when the missile last moved: static DWORD missileTickCount = 0; ...and every frame, add-in the number of milliseconds that have elapsed: missileTickCount += G.diffTickCount; As you could imagine, this variable will steadily accumulate elapsed frame times. Next, we'd like to trigger the missile's movement when we have 1000 (or more) milliseconds accumulated (which means that it hasn't moved in that long): if (missileTickCount >= 1000) {...} Don't forget the >= as missileTickCount could have contained values like this from frame to frame: ...925, 943, 961, 988, 1004, 1029... ...and we want to catch it as soon as possible when it reaches the one second mark. Finally, we want to perform our movement and note the fact that we've accounted for our one-second movement: if (missileTickCount >= 1000) { // ...move the sprite missileTickCount -= 1000; } It's important that this last line makes sense to you. If the value of missileTickCount was actually 1015 for instance, we've got 15 msec. too much, and that value should be carried over so that the sprite can move properly one second after it was originally supposed to, not one second after we actually moved it. Now, let's play with the example above to take into account an object that wants to move x pixels per second. It might help to show you some sample data first: x = 1 pixel every (msec.) ---- ----------------------- 1 1000 10 100 20 50 50 20 100 10 1000 1 At any one frame, an object might need to move 0 or more pixels. Since our movement counter variable tracks per-pixel movement, we're going to need a loop in case there's more than one movement 'turn' for this iteration of Game_Main() . You should be able to figure out that 1000 / x = the number of msec. to wait before moving one pixel, and here's some code that would do the trick: missileTickCount += G.diffTickCount; while (missileTickCount >= (1000 / missileMovementRate)) { // Move your missile one pixel here... missileTickCount -= (1000 / missileMovementRate); } Be careful that missileMovementRate is never zero else you'll have a division-by-zero problem on your hands. Hey, now that we've got a timing mechanism in place, it's time for a demo! The following code uses BaseCode2, which is the first article so far to do so -- grab a copy on my webpage. It's essentially the same 'ol template code, but adds a DirectDrawClipper for safe blitting, source color-keying for black-background images, and the G.diffTickCount global variable for timing. Once you've got that ready, throw the following in Game_Main() : // We're using the letter 'A' for our sprite #define SPRITE_WIDTH 11 #define SPRITE_HEIGHT 13 ////////////////////////////////////////////////////////////////////////////// // Game_Main // // This function is called once per frame. // void Game_Main() { HRESULT hRet; // Timing static DWORD lastTickCount = timeGetTime(); DWORD thisTickCount; // Sprite static int pos = -SPRITE_WIDTH; // Sprite position int spriteRate = 200; // Pixels per second static DWORD spriteTickCount = 0; // Movement counter // Rendering RECT rectSrc, // Sprite source rectDest; // Sprite destination // Leave if we're quitting if (G.bQuitting) return; //------------------------------------------------------------------------ // Timing //------------------------------------------------------------------------ thisTickCount = timeGetTime(); G.diffTickCount = thisTickCount - lastTickCount; lastTickCount = thisTickCount; //------------------------------------------------------------------------ // Get keyboard input //------------------------------------------------------------------------ while (hRet = G.lpDIKeyboard->GetDeviceState(256, G.KeyState) == DIERR_INPUTLOST) { if (FAILED(hRet = G.lpDIKeyboard->Acquire())) break; } //------------------------------------------------------------------------ // Sprite movement //------------------------------------------------------------------------ spriteTickCount += G.diffTickCount; if (KEYDOWN(DIK_SPACE)) return; // Delay while (spriteTickCount >= (1000 / spriteRate)) { // Move the sprite one pixel over pos++; // Wraparound the display if off the right edge if (pos > SCREEN_WIDTH) pos = -SPRITE_WIDTH; // Update the sprite's movement counter spriteTickCount -= (1000 / spriteRate); } //------------------------------------------------------------------------ // Rendering //------------------------------------------------------------------------ // Clear the back buffer EraseBackground(); // Prepare the sprite's source RECT rectSrc.left = rectSrc.top = 0; rectSrc.right = SPRITE_WIDTH - 1; rectSrc.bottom = SPRITE_HEIGHT - 1; // Prepare the sprite's destination RECT rectDest.left = pos; rectDest.top = 0; rectDest.right = rectDest.left + SPRITE_WIDTH - 1; rectDest.bottom = rectDest.top + SPRITE_HEIGHT - 1; // Render the sprite to the backbuffer G.lpDDSBack->Blt(&rectDest, G.lpDDSRes, &rectSrc, DDBLT_WAIT, NULL); // Flip the surfaces G.lpDDSPrimary->Flip(NULL, 0); } Since we're using clipping, we can't use BltFast() anymore, but that's fine. What we can do now though is draw sprites partially off of the display, as this code does. You'll see the letter 'A' travelling from the left of the display, across to the right at a constant rate of 200 pixels per second. If you press SPACE, the function will abort causing a short delay before the sprite is rendered again. By pressing and holding the space bar, it is demonstrated that regardless of how often the sprite is rendered, it is in fact moving at a constant velocity of 200 pixels per second. As you'll notice in the SDK documentation for timeGetTime() , you need to initialize the function's resolution using timeBeginPeriod() and timeEndPeriod() , so these lines are added to Game_Init() and Game_Term() : // // In Game_Init(): // // Initialize our timer resolution for 1 millisecond timeBeginPeriod(1); // // In Game_Term(); // // Reset our timer resolution to the default (use the same value // (that was used in timeBeginPeriod() to reset) timeEndPeriod(1); Theoretically there's a chance that the call to timeBeginPeriod() will fail by returning TIMERR_NOCANDO, but in this example I didn't bother checking...the worst that can happen is that we're stuck using the timer's default resolution which probably isn't so bad anyhow (1-5 msec.). Now that we're able to tell when a period of time has elapsed, everything in our game code can immediately benefit from it -- sprite animation, game state counters, in-game timers, AI processing...the list goes on and on. Questions? Comments? Please reply to this topic. Edited by - Teej on June 1, 2001 2:22:05 PM

Hands-On Interactive Game Development Workshops

Started by Teej May 29, 2001 09:46 AM

26 comments, last by Teej 23 years, 1 month ago

NewAtThis

122

June 30, 2001 04:48 PM

I finally got Visual C++ and I am getting all of this. This is millions of times better than QBasic game prgramming.

Great job Teej!

saetrum

122

July 02, 2001 01:05 PM

I''ve been following along and have not had problems until we started using BaseCode2.zip. Using just the code without any modifications I can compile and run but the program is immediately minimized, and when I click on it to bring it up it is brought up for about 2 sec (just enough for me to see the A cruising across the screen, then it minimizes itself again... I have a suspicion that it is my Video Card (its a matrox something with 8MB RAM - I don''t know more about the video card since this isn''t my computer, and I don''t have another computer at the momemnt.) Any suggestions, or do you need more information..

Thanks,

Dave

Teej

Author

176

July 05, 2001 12:33 PM

Hmm. It''s almost as if something else on the machine is taking away the input focus, and therefore becoming the currently active program. Is there something else running that demands ''on top'' status? A clue might be where the input focus goes after BASECODE2 minimizes...

Just a guess... anyone else having similar difficulties?

Teej

saetrum

122

July 05, 2001 03:05 PM

The focus just goes back to Visual Studio, I am launching the program from the menu bar build/execute basecode2.exe.

I do have a few other programs running at the time, I'll see if I can run with them off.

Any other suggestions?

Thanks.

****UPDATE - Dang it! I had Norton Anti-virus running, that program is worse than a virus half the time. Once it was off, the program worked just fine. Thanks for the help Teej, sorry to waste your time. I really appreciate your efforts with this tutorial, it's great.***********

Edited by - saetrum on July 5, 2001 4:29:57 PM

Hyatus

122

July 14, 2001 09:38 AM

Regarding the high-resolution timer, I read somewhere awhile
back that it''s been on processors since the 386, so I don''t think
there''s much of a chance that someone doesn''t have one.

-Hyatus
"kopperia no hitsugi"

gxe

122

July 28, 2001 01:42 PM

Been following the excellent tutorial so far with no problems. But when trying this topic 04.06 Timing I'm getting nothing but a blank, black screen.
What I've done:
Got BaseCode2.zip and extracted files to a new BaseCode2 area
Created a new Project and included all the files.
Built the code, no errors but black screen.
Then tried copyng in Game_Main() code from this web page into the editor to replace existing Game_Main() and rebuilt.
Rebuilt the code, again no errors, but just a black screen !
Anyone got any suggestions ?
I guess I've overlooked something :-(
********EDIT********
DOH! Got a cr&ppy old monitor, so the demos only seem to work properly if I set the SCREEN_WIDTH & SCREEN_HEIGHT to match the my windows desktop settings (800x600) - done this and it works great now - had to do this before with BaseCode1, but forgot to change the globals.h in BaseCode2 - sorry for any time wasted !
*******************
P.S. Superb stuff Teej, keep 'em coming - I'm hooked :-)

Edited by - gxe on August 1, 2001 8:50:05 AM

Cheers !eddSoftwww.eddsoft.com

Al Sidan

122

August 07, 2001 10:56 AM

Don''t beat me for this question,

but I don''t understand the code that initializes the sprite position:

static int pos = -SPRITE_WIDTH;

What is " -SPRITE_WIDTH"? Is it equal to -11? Or to --11??

Why inizialize a position to -11 (or --11 = 10)?

Al Sidan

Firemage

122

August 07, 2001 03:26 PM

Al Sidan,

It's -11. It didn't make sense to me either at first. What is going on is that the sprite is being drawn off screen so we can see it enter onto the screen. If I do my math right.. I'm probabyly off by a 1 somewhere... the rightmost pixel of the sprite should be at -1, so after it moves the very first time, the rightmost pixel of the sprite will be at 0, he first visible pixel on the screen.

Make sense?

Hope that helps,

Firemage

To Thine own self be true

No day but Today

Edited by - Firemage on August 7, 2001 4:29:01 PM

To Thine own self be trueNo day but Today

04.06 - It's About Time...

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

04.06 - It's About Time...

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines