General Timing
July 19, 2002 04:22 PM
I''m building the engine for a 2D DirectX game, and I''m trying to resolve a timing issue. Right now, I have a global counter that keeps track of the number of frames that have been drawn since the program started. I''m thinking of keeping an array of all on-screen animated sprites and using that global counter to implement an animation delay. For example, I could give each sprite object a "delay" integer variable, and every time that number of frames passes (counter%delay==0), the sprite will update its position, animation frame, etc. I figure that way I can limit the speed of the action on-screen. Is this the best way to do it? Is this how its generally done? I''d like a more general solution, rather than giving everything its own delay variable. Also, I''m eventually going to extend this timing method to pop-up text, etc., by maintaining lists of everything that should be updated, and then cycling through my lists once every frame and drawing the object if the delay condition is met. Any suggestions or feedback from people with experience would be helpful. Thanks!
Tolerance is a drug. Sycophancy is a disease.
July 19, 2002 07:16 PM
What I''ve done is this:
In the main game loop, just implement a delay to restrict the number of frames a second. example:
I understand that your point is to delay animation and things like that, but this is an important part of that. If you know that there are about 60 frames drawn each second, you can use that to delay other things. Say you want a character''s walking animation to take a second, and you only have 30 frames. (I know that''s not necessarily reasonable, but the point''s the same and this has easier math) In that case you would simply have a variable for that keeps track of when to draw. In this case you would have that variable increment once every frame. There are a couple of things you could do with this. You might just have it go back to zero every other frame, and update the frame every time the number is 0. There are other ways to do this, but this is probably the simplest I can think of at the moment.
Anyway, I hope I didn''t complicate that too much. Hope this helps!
-Arek the Absolute
In the main game loop, just implement a delay to restrict the number of frames a second. example:
// enter main event loopwhile(TRUE){ // Get current time DWORD dwStart = GetTickCount(); // test if there is a message in queue, if so get it if (PeekMessage(&msg,NULL,0,0,PM_REMOVE)){ // test if this is a quit if (msg.message == WM_QUIT) break; // translate any accelerator keys TranslateMessage(&msg); // send the message to the window proc DispatchMessage(&msg); } // end if // main game processing goes here Game_Main(); // lock to ABOUT 60 fps (1000 / 60 = 16.666....) while ((GetTickCount() - dwStart) < 16); } // end while I understand that your point is to delay animation and things like that, but this is an important part of that. If you know that there are about 60 frames drawn each second, you can use that to delay other things. Say you want a character''s walking animation to take a second, and you only have 30 frames. (I know that''s not necessarily reasonable, but the point''s the same and this has easier math) In that case you would simply have a variable for that keeps track of when to draw. In this case you would have that variable increment once every frame. There are a couple of things you could do with this. You might just have it go back to zero every other frame, and update the frame every time the number is 0. There are other ways to do this, but this is probably the simplest I can think of at the moment.
Anyway, I hope I didn''t complicate that too much. Hope this helps!
-Arek the Absolute
-Arek the Absolute"The full quartet is pirates, ninjas, zombies, and robots. Create a game which involves all four, and you risk being blinded by the sheer level of coolness involved." - Superpig
122
July 19, 2002 07:55 PM
Arek - I don''t think that''s a good way, you should modify it a little like this:
That way, windows can process messages in your game''s ''idle'' time, ie. while waiting to see whether a frame should be drawn (though to be honest, it probably wouldn''t make much difference)
fisheyel83l : The way I do it is to frame-rate independent motion. Basically you set up a high-res timer, and update as often as possible, moving the objects by the frame time.
eg.
Object.x += fFrameTime * 10.0f;
I''m sure there''re plenty of articles/tutorials about this out there.
while(TRUE){ // Get current time DWORD dwStart = GetTickCount(); // test if there is a message in queue, if so get it if (PeekMessage(&msg,NULL,0,0,PM_REMOVE)) { // test if this is a quit if (msg.message == WM_QUIT) break; // translate any accelerator keys TranslateMessage(&msg); // send the message to the window proc DispatchMessage(&msg); } // end if // HERE''S THE MODIFIED BIT else if (GetTickCount() - dwStart < 16) { // Main processing here Game_Main(); }} That way, windows can process messages in your game''s ''idle'' time, ie. while waiting to see whether a frame should be drawn (though to be honest, it probably wouldn''t make much difference)
fisheyel83l : The way I do it is to frame-rate independent motion. Basically you set up a high-res timer, and update as often as possible, moving the objects by the frame time.
eg.
Object.x += fFrameTime * 10.0f;
I''m sure there''re plenty of articles/tutorials about this out there.
144
July 20, 2002 04:45 AM
Well, i''ll reapeat what they said, just making it more general and a bit simplier.
while (gameIsRunning)
{
1. t = GetTime() or GetTickCount()
2. Update everything in your game
3. Wait while GetTime() < (t + delay)
}
The delay must be chosen wisely.
I don''t agree with sibbo. His way to do it makes the frame rate not constant and the game speed too! When they''ll be many elements in the game it''ll be slower than when there are few.
Arek''s way is right, it makes all calculations and then wait until a certain time is over, so that each update of the game is calculated with the same time interval. So, frame rate is also more or less constant.
while (gameIsRunning)
{
1. t = GetTime() or GetTickCount()
2. Update everything in your game
3. Wait while GetTime() < (t + delay)
}
The delay must be chosen wisely.
I don''t agree with sibbo. His way to do it makes the frame rate not constant and the game speed too! When they''ll be many elements in the game it''ll be slower than when there are few.
Arek''s way is right, it makes all calculations and then wait until a certain time is over, so that each update of the game is calculated with the same time interval. So, frame rate is also more or less constant.
July 20, 2002 07:46 PM
Good call, Sibbo2001. To be honest, I just took that from Lamothe''s source, and never really questioned it. I''ve been programming mostly for the Gameboy Advance, so I''ve never really taken the time to optimize DirectX code. Should be self explanatory why. Thanks though. I''ll keep that in mind!
-Arek the Absolute
-Arek the Absolute
-Arek the Absolute"The full quartet is pirates, ninjas, zombies, and robots. Create a game which involves all four, and you risk being blinded by the sheer level of coolness involved." - Superpig
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
