/agdg/ - Amateur Game Development General

Depends in how you do it. Plenty of games used floats for time. Just add the current delta time to the float per update and if it passes beyond a certain number, set the timer off.

What about the <time> library?

Floating-point time KILLS.

Do not use floating-point time.

Represent time in integer units if possible, or fixed-point otherwise.

Well first of all, a double is just a more precise float.

http://gafferongames.com/game-physics/fix-your-timestep/

http://www.isaacsukin.com/news/2015/01/detailed-explanation-javascript-game-loops-and-timing

Your game logic needs to be capable of updating at some minimum frame rate (e.g., 60 hz). While your game can be written to use a variable time step, the size of the time-step should not change between loops (that is, it should be defined as a constant somewhere). This is especially true if you're writing a networked game.

In your main loop, you calculate the time delta between now and the last mainloop execution, and you add this delta time to some accumulator variable (a double, usually). When the accumulator is greater than the fixed time-step (e.g. accumulator >= 1.0/60), then you subtract the timestep from the accumulator and you tic your logic forward by one tic.

Using this method, you can render the game at whatever framerate the user's device will allow. If the game can't render at the same rate that the logic is updating at, then you will have to do several logic updates per main loop. You might also need to interpolate between the current state and the penultimate state (i.e., state at current_tic - 1) and draw things "slightly in the past" in order to make your render more smooth. (But if it's a simple game, you can probably just do logic and drawing at 60 Hz).

So, you should be storing "tics" as an integral value and "time" as a continuous (double) value.

Use milliseconds since start of process opening, in C# it's Environment.TickCount;, in Java it's System.GetCurrentTimeMillis();, it's been a while since I've done C so you'll have to look up a solution.

Basically store time as an int. In your game loop, per frame, you have lastTime and currentTime, and by subtraction, a time differential. That's all you need. Math it out from then on.

>>27832

>Represent time in integer units if possible

This. long long is a thing.

Use a double. Floats have catastrophic cancellation issues after just a day above 30 fps (assuming your game initializes its runtime to 0.0f). Doubles take millenia of constant runtime to lose more than a microsecond of precision.

>>27832

Double-precision is fine. Integers are better if your framerate and system allows for it, but can make it far harder to handle things like 3D animation, or really anything to do with interpolation. If your system allows integer measurement without locking framerate at all, then sure.

>>27900

>Floats have catastrophic cancellation issues after just a day above 30 fps

If someone plays my game for a whole day straight then I've already made it. And they can just restart it.

>>27920

While this might be ok for singleplayer games, remember that occasionally people will want multilayer, and you probably want the servers up 24/7 if they're not installing an update.

(some source engine online RPG's had this issue)

>>27900

Use unsigned long longs for logic/world ticks, and doubles or floats for interpolation/extrapolation. Your game will still look smooth, but your netcode will be saner.

No.