To use a universal time or not? That is my question
Author
I am transforming my frame based game into a time based one. Now to do this, obviously I need to use the time elapsed between frames in order to calculate velocity and distance and whatnot.
Now, I have created my game so that the ships and bullets and whatnot update themselves, simply by calling an Update() function every frame. Originally, I just gave each object it's own timer to use, so when the Update() function is called it checks how much time has elapsed since the last time it was called, then restarts it's timer. This seems to work fine.
The other possible way to do this though is to just use one single timer that restarts every time my game loop is called, and then just use that one single elspased time globally for every object.
Now my question is, is one way better or a prefered over the other?
I like my first method because everything that the class needs is contained in the class itself, so it's very portable and loosely coupled. However, some objects elapsed time may be larger than other objects since each object uses it's own timer (but this should even itself out by the next update call).
Using the second method, everything (all objects) will be moving according to the same elapsed time, but I have to pass that time into my Update() function (which really isn't a problem).
Any comments or suggestions would be appreciated. Thanks!
The second method is the better one.
Issue 1 - First movement.
You have two bullets, just coming into existence (0 time). The first bullet is fired by the very first enemy in the game loop. The second bullet is fired by the very last enemy in the game loop.
The second bullet will travel further on the first frame than the first bullet, regardless of any averaging the next frame. This would make any sort of multiplayer game unbalanaced (as the last player to shoot would always win if the distance between the players was equal).
Issue 2 - Overhead
You're most likely keeping track of 3 values in your timer. Start Time, Delta Time and Total Time. That's an extra 24 bytes (assuming doubles) per entity, for no reason.
You should look into the singleton pattern and use that for your timer. This would also give all of your entities access to the application time which a lot of them will need. For example: A grenade has to explode in 4 seconds after being thrown. That will require the application time.
Issue 1 - First movement.
You have two bullets, just coming into existence (0 time). The first bullet is fired by the very first enemy in the game loop. The second bullet is fired by the very last enemy in the game loop.
The second bullet will travel further on the first frame than the first bullet, regardless of any averaging the next frame. This would make any sort of multiplayer game unbalanaced (as the last player to shoot would always win if the distance between the players was equal).
Issue 2 - Overhead
You're most likely keeping track of 3 values in your timer. Start Time, Delta Time and Total Time. That's an extra 24 bytes (assuming doubles) per entity, for no reason.
You should look into the singleton pattern and use that for your timer. This would also give all of your entities access to the application time which a lot of them will need. For example: A grenade has to explode in 4 seconds after being thrown. That will require the application time.
Instead of using the application time, you could just keep decrementing the time-to-explode variable (originally set at 4.0 in this instance) by the elapsed frame time. When it reaches < 0, it blows. That's one method...
A singleton-based timer is the best idea, as you can extrapolate all timed events off that rather than keeping a bunch of timers updating all at once.
Your method of basing objects off time elapsed per frame should also work off the fixed time step approach. This way, every physics update, your time step is always the same. It retains the most numerical integrity in a simulation.
Each frame, you add the last frame's elapsed time to a variable. While this variable is greater than the physics update time, you update the physics. For example, say, 0.30 seconds elapsed, with one physics update every .15 seconds = 2 updates in that time. Each physics update you decrement the amount of total time elapsed.
This is just a really short quick example. Visual anomalies will happen if your frame rate is quicker than the physics rate.. you can introduce interpolation for that which will make everything look a lot smoother, but that's for later :P
[Edited by - sordid on July 18, 2005 2:47:52 PM]
A singleton-based timer is the best idea, as you can extrapolate all timed events off that rather than keeping a bunch of timers updating all at once.
Your method of basing objects off time elapsed per frame should also work off the fixed time step approach. This way, every physics update, your time step is always the same. It retains the most numerical integrity in a simulation.
Each frame, you add the last frame's elapsed time to a variable. While this variable is greater than the physics update time, you update the physics. For example, say, 0.30 seconds elapsed, with one physics update every .15 seconds = 2 updates in that time. Each physics update you decrement the amount of total time elapsed.
// assuming all floats are in fractions of a secondtimeElapsed += frameTime;while (timeElapsed > physicsUpdateTime){ UpdatePhysics(); timeElapsed -= physicsUpdateTime;}This is just a really short quick example. Visual anomalies will happen if your frame rate is quicker than the physics rate.. you can introduce interpolation for that which will make everything look a lot smoother, but that's for later :P
[Edited by - sordid on July 18, 2005 2:47:52 PM]
I would just keep track of how much time elapsed since the previous frame and pass that to all your update functions. Those functions can then use that value, ignore it (maybe to use the timers you already are using), modify it (scale, etc), or what have you.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
