One question to be answered here is: Why would you use fps as your game clock? I could see this as a valid solution in the older games (can't really comment on it as I've never seen code for one - that is the original), but today we have access to machine time which in return gives us the possibility to make rendering and logic updates seperate. This way you can have rendering as fast as possible with logic working at the predicted speed. I can run a game of Snake at literally one million fps and it will run at the same speed as if it is ran at 50 fps. On the same not: If most modern games would use fps based logic they would be unstable at most. Think about it.

For example: My gaming rig can run Minecraft at 500 fps. If I compare that to my old computer which was capable of let's say stable 20 fps that is 25 times slower rendering speed. This doesn't mean I am running around the world at lightning speed but it means that objects (blocks) are rendering faster and the game runs much smoother.

On the other hand I can see a use of frame limiter. It is to decrease the strain on your graphics card.

Final thoughts: Yes, frame limiter is important when we are talking of a final product to be shipped out so the user can decrease the fps (less power consumption, less heat produced,..), but you definitely don't need it in a work in progress in my opinion.

It would be more than welcome if someone can prove me wrong as this way I'll learn new things but untill then this is my way of thinking.

Have a nice day/night,

JKKDev

EDIT: By the way, If you want to see my logic expressed in code let me know. It is in Java but should be easy to understand.

I never said you should use fps as your game clock (actually that's a pretty bad idea). But you should have some type of frame limiter IMO, you can make it so you can toggle it off if you'd like so(it is helpful if you run on low fps to be honest, to have an option to disable fps limiters, smoothing etc.), but I really don't think I need my laptop to melt because it does 500fps per second for god knows what reason . Why would you take that CPU time from other programs, or strain your processor or GPU?

Yes, frame limiter is important when we are talking of a final product to be shipped out so the user can decrease the fps (less power consumption, less heat produced,..), but you definitely don't need it in a work in progress in my opinion.

You said it yourself. However I actually start most of my projects with some kind of fps and clock logic. It's usually useful to have it (for pausing the game, control of events, interpolation/extrapolation of various "things" etc.).

Why do you want to limit your fps?

Try playing an older game that doesn't have some kind of fps limiter and watch that surreal speed of animations, movement etc(it gets basically unplayable).

I can't see the connection you made in this comment without using fps as your game clock, but I agree with you on all the other things you've said. I just think that rendering shouldn't be used to manipulate logic in any way. The relationship between logic and rendering should be in one way only and that is logic manipulates rendering.

I can't see the connection you made in this comment without using fps as your game clock

It's better to have a fps limiter acting as your game clock if you don't have such a clock, rather than have nothing at all. It was just an example, because I remember playing an old game of mine on a newer PC - it was a tragedy, and just because the devs didn't add something as simple as a clock or at least a fps limiter. So I think any game should have an fps limiter, they may not add a game clock, but at least an fps limiter. Basically it's a good idea to have something that goes tick-tock even if it's not really accurate - at least it would be better than nothing.

I just think that rendering shouldn't be used to manipulate logic in any way.

It's true in most cases, but sometimes you don't need to do some processes in between frames, so actually "rendering manipulating some of the game logic" may sometimes prove to be useful and can save you some processing power.

Can you give an example of your last statement? (I'm interested in seeing other peoples view on this topic :))

There are plenty of examples. The most obvious - It can be something you'd need in the rendering later (it may be an algorithm for procedural content generation - for example some type of texture update), so no need to calculate it more than once in between frames. Basically most algorithms that need information from the rendering process or provide information to it. It can be calculations for physical simulations too, most of the times you won't need to do such calculations more than once in between frames. To be honest most of the logic and algorithms may have something to do with the fps to a certain degree. Any algorithms than you can optimize, to make it run every frame and not n times in between frames, would be a good example.

I'm not sure where the FPS limiting comes into play with the game clock.

Older games were designed to run at a certain FPS, lets say, 30. When the game was created they designed the way objects move(for instance how much a worm moves) to be based on 30 update iterations every second. So if they wanted the worm to move say, 30 units a second, then all they do is make the worm move one unit every update frame.

That worked fine for the time period, but on faster machines that weren't using the same hardware always, that inevitably meant everything started moving at super speed. You can do a similar thing these days by using a fixed time step, which basically means artificially limiting your update to running so many times per second.

But honestly in most cases you want to make your movements based on time, not on update iterations. This depends on the object, for instance a 2d ball moving across the screen would probably benefit(graphically) from moving based on time, easiest way to do that is to get a decimal value of the time that passed out of a second and multiply your movement units by it. If you have a physics engine, the physics engine probably moves in steps because physics is much more accurate with round numbers, depending on the engine it may have an update function that either grabs the time or asks you for the delta time. Then it just sits there and does nothing until a certain amount of time has accumulated.

For implementing a timer class in a non-fixed timestep game, you can pretty easily just take the delta time passed from the game loop, and add it to an internal timer. You can even make countdown timers, say you start it at ten seconds, then you just subtract the delta time. When it goes to zero or under zero, you fire your event.

Thanks for the input guys, I will do some work with it in a while, as I am trying to create a random dungeon generator right now.

The reason I limit the fps is because all noob tutorials do it that way, to keep things as simple as possible. Alghough I have seen plenty of examples using delta time it has not occured to me to apply it in a simply dungeon crawl.

I'm not sure where the FPS limiting comes into play with the game clock.

Naturally fps limiting shouldn't come into play with the game clock, actually to be honest an fps limiter usually uses the game clock(ex: you want 60fps to be the limit so you know you need every frame to be 1000/60ms - to check this you'd need "some sort of implementation of a game clock", but in the end I could even use my fps as a game clock in this case as I would know that the time between every frame would be roughly 1000/60ms, that's not better as it could cause some minor errors between the expected time and the actual time - a frame could take more time to be processed than expected etc.). But when you do not have a game clock(for whatever reason), you usually use the fps as some sort of a "clock"(which is kinda terribad).

Older games were designed to run at a certain FPS, lets say, 30. When the game was created they designed the way objects move(for instance how much a worm moves) to be based on 30 update iterations every second. So if they wanted the worm to move say, 30 units a second, then all they do is make the worm move one unit every update frame.

Well, that's the big problem - they weren't designed to run at a certain fps. If something is designed to run at 30 fps - it shouldn't usually run faster. Basically if I design something to run at 30fps, I would have to limit the fps to 30fps. What the devs did in that old game is that they actually made it work only for the average PCs of that time, which is kinda dumb to be honest.

But honestly in most cases you want to make your movements based on time, not on update iterations.

Of course that's the best way to deal with things. For further and more detailed reading - look here: http://gafferongames.com/game-physics/fix-your-timestep/

I prefer this article: http://www.koonsolo.com/news/dewitters-gameloop/