Creating A TickRate Class

Question

I need to implement tickrate into my engine to handle timed events such as pushing out entity updates and I don't know where to start.

I have access to a timer which allows me get the time in milliseconds since the device has been initialized.

When I try to brainstorm on the correct approach to take one of the main things that I get stopped up on is that on the client side I should allow the framerate to run as fast as it can, however if I want the tickrate to run at 60 and the client FPS is less than 60 how can 60 ticks execute if the main loop wont run at least 60 times a second due to it being slowed down by the fps?

Can anyone explain how to properly implement tickrate? Thank you for your time.

I can direct you there: http://www.lwjgl.org/wiki/index.php?title=LWJGL_Basics_4_(Timing). Yes, this is for Java, but the algorythm will be the same for C++. This one is a basic timing loop. — Alexandre Desbiens, Jul 17 '14 at 12:28
Maybe this: https://gamedev.stackexchange.com/questions/1589/when-should-i-use-a-fixed-or-variable-time-step helps you to take a decision. — user743414, Oct 14 '19 at 09:33

Philipp · Accepted Answer · 2014-07-17T16:33:35.427

2

The approach by Narrateur du chaos is commonly called the delta-t approach. But there is also another approach, the game-tick approach. In this approach you keep track of how long the game is running in real-time and how much time the game-world has processed. After each graphics frame you check how far the game world lacks behind the real world and do updates until it has catched up.

 MS_PER_TICK = 1000 / 60  // the time one game-tick represents

 PROCESSED_TIME = currentTimeInMs();     

 while game is running
      drawFrame()
      while (PROCESSED_TIME + MS_PER_TICK) < currentTimeInMs()
        updateGame()
        PROCESSED_TIME += MS_PER_TICK

Personally, I prefer this approach because it makes your update-functions a lot easier to write when you know it always represents a fixed timespan and don't have to take the delta-t into account for every single calculation.

edited Jul 17 '14 at 16:33

answered Jul 17 '14 at 13:18

Philipp

119,250
27
256
336

+1, because I like this method far more than the delta one. Taking the time delta into account can be extremely difficult in some calculations. – Alexandre Desbiens Jul 17 '14 at 13:24
I like this since each tick is a fixed amount of time which helps stepping the physics however can you explain how this guarantees there will be no more or no less than 60 ticks a second? – KKlouzal Jul 17 '14 at 13:31
@KKLouzal It basically calculates 1/60th of a second and process. The only ways that could fail is if your clock is not calibrated or if the processor cannot handle the update process in 1/60th of a second. – Alexandre Desbiens Jul 17 '14 at 13:33
I ask because drawFrame() will take some time to complete especially with a variable framerate. – KKlouzal Jul 17 '14 at 13:34
@KKlouzal Everything should be fine for a small game on decent hardware. If you want more explanation about this type of timing loop, please visit the link I posted in your question's comments. – Alexandre Desbiens Jul 17 '14 at 13:37
3

@KKlouzal When drawFrame takes very long, the while-loop will be executed several times, so game-ticks will be calculated until the game-state has caught up before another frame is rendered. When drawFrame is very fast, (PROCESSED_TIME + MS_PER_TICK) < currentTimeInMs() will likely still be false, so it will immediately render another frame without changing the state. – Philipp Jul 17 '14 at 13:37
2

@KKlouzal There's three performance cases 1) your machine can simulate all the requested ticks faster than time moves and it draws at least as many frames per second as you want; 2) your machine can simulate everything, but cuts down on render frames; 3) your machine cannot even keep up with simulation ticks in realtime. Case 3 is the bad one, as it will enter a death spiral never being able to catch up, and thus appear frozen. A common mitigation for that is to only simulate a particular number of ticks in a row before drawing, essentially ending up with game time running slower. – Lars Viklund Jul 17 '14 at 13:40
Okay I understand, thank you very much. Just to clarify, each tick would represent 1/60th of a second however there is no guarantee each tick will come 1/60th of a second after the previous one but most of them will, especially when there is a high fps? – KKlouzal Jul 17 '14 at 13:43
@KKlouzal Not completely right: The higher the FPS, the more reliable the real-time differences between ticks. When the FPS are lower than the tick-rate, there is a chance that ticks will be executed in quick succession without any real-time passing between them. But considering that all the player sees is the graphics output which is per definition too slow to visualize this, this should be of little concern for you. – Philipp Jul 17 '14 at 13:50
@KKlouzal That means when you have any timers in your game, they should depend on PROCESSED_TIME, not on real-time. When you have a timer-mechanic, I would recommend you to implement it yourself anyway so you can control at which point of your update-function timer events will be processed. When you use a "real" timer provided by some framework, they usually use multithreading and can be executed in the middle of some other procession. This can cause all kinds of funny and impossible to reproduce and debug bugs due to race-conditions. – Philipp Jul 17 '14 at 13:55

score 1 · Answer 2 · edited Jul 17 '14 at 13:49

I'm not an experienced developer, but your question seems straightforward enough. Your main() must look like this:

int main(args)
{
    // Code, declarations, whatever
    MainClass game(arg1, arg2...);

    try
    {
          while (game.continue())
          {
               float ticks = timeSinceThatFunctionWasLastCalled();
               game.update(ticks);
          }

          return EXIT_SUCCESS
    }
    catch (err) { // Ideally, no exception must ever reach this point in
                  // the final version, or it means your game crashed, but
                  // whatever.
          return EXIT_FAILURE;
    }
}

Every class in your code whose instances must be altered every tick must then have some sort of function like void update(float ticks); that is called once every time game::update() is called.

Creating A TickRate Class

2 Answers2