This topic is 3977 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello all, First off I just want to say thank you to everyone who has helping me along so far. This site is an amazing resource. Now here is my problem. I am having a difficult time understanding how/if I should implement timing within my 2D side-scrolling game. When I first started the project I had no limitation on speed and I quickly realized that I needed to cap this somehow. I then wrote a method to cap the FPS at 60 so that I can keep things under control and have different sprites moving at their own velocities. I am now starting to realize that this method has it's limits as well. My questions is...is this something I should worry about right now? Being that I am just working on a fairly simple 2D engine should I look into using some more advanced timing control. I did some tests but couldn't seem adapt my collision routines due to my sprites often moving at less than a frame per second. I have done a ton of searching for some solid example code and haven't really been able to come up with anything of use. Please discuss and layout a few options and pros and cons for me. My progress has really been halted while trying to wrap my brain around this. Thanks. Matt

##### Share on other sites
1. forget about frames. Frames are to be rendered when you can, while game logic (collisions, movement) are to be performed when you must. It is the latter that you are concerned with.

2. determine how many game logic iterations you have to perform at a given moment. For instance, if you decide you need 60 iterations per second, and the game has been running for 10 seconds, then you must have performed 600 iterations by then.

3. if you're missing iterations, just do them. So, if you determine you need 600 iterations, and you only have done 598 so far, you perform two of them. If you already have 600, you don't do anything.

4. if you have nothing to do (for instance, all your required iterations have been performed), draw a frame, read input and perform other non-essential bookkeeping operations.

##### Share on other sites
As I understand the logic you laid out I however don't understand how you would keep everything under control without the use of timing or capping the frame rate.

##### Share on other sites
There is no point in capping the framerate, since framerate should not affect game logic anyway.

As for keeping things under control, I don't. I don't have to keep things under control because they were designed to work correctly in the first place. The number of game logic iterations is a deterministic function of elapsed time, which makes the game behave correctly on all but the slowest computers.

Of course, you still need access to a timer to measure the elapsed time, but this can be done with even the most primitive and elementary timer.

##### Share on other sites
Just a simple question regarding update/frame rate.
What about if one decides, his game logic will be updated 60 times per second but the renderer could easly deliver 180 frames per second with a simple 2D engine. That means that every single frame is rendered 3 times equal and then the logic gets updated. Isn't this a waste of resources?
//Update logic only 60 times a secondif (timeElapsed>1/60 second){UpdateLogic(timeElapsed);}//Render at any costRenderFrame();

Does this make any sense?

##### Share on other sites
To answer Samurai jack: yes, it does. It makes so much sense than even the "mighty" John Carmack did that for Doom3. (doom3 game logic runs at 60hz).

So if the game logic is 60hz but the engine can do 180hz, you have 2 possible outcomes:
1. you render the same frame 3 times. (and you can "brag" about your framerate)
2. you keep a "previous" and "next" state in the game logic and the render logic interpolates between them. Simple example for a sprite:
game logic decides the 'next' position for the sprite is at 60,60 (previous position at 0,0). (again, logic at 60hz, render at 180hz). Without interpolation, after 3 frames (same frame re-drawn), the sprite "jumps" to (60,60). With interpolation, the sprite is draw at 20,20, then at 40,40 then at 60,60 so the movement is smoother (because the framerate is higher).
Of course, that's just an example, I can't imagine a game logic which moves a sprite by 60px each 1/60seconds. :)

##### Share on other sites
Okay. While I understand the logic here I have no clue as how to implement things. Could someone help me out with some pseudo-code for the main loop that will simple handle input, update position and check collision and then output.

I'm trying to keep this as simple as possible as I am just writing this engine as a learning project.

Thanks for the detailed explanations so far.

##### Share on other sites
Something like this:
    int const LOGIC_UPDATE_PERIOD = 10; // 100 times per second (in ms)        int previousTime = GetTimeInMilliseconds();    while ( true )    {        int currentTime = GetTimeInMilliseconds();        while ( currentTime - previousTime > LOGIC_UPDATE_PERIOD )        {            UpdateGameLogic( LOGIC_UPDATE_PERIOD );            previousTime += LOGIC_UPDATE_PERIOD;        }                Render();    }
The value you use for LOGIC_UPDATE_PERIOD can depend on many factors. Ideally, you update at least twice per frame, but that might not be practical.