I personally prefer the 1st choice. It not only simplifies you work, lets you profile easily and lets you sets a target, it's also better in the sense that most physics engines require you to have a *constact timestep* if not, the physics starts to look all weird.
What I usually do is to update the game based on the current FPS, update the Physics engine with an absolute timestep which is at the framerate you cap (if your framerate cap is 60 FPS, then update the physics engine by 1.0/60.0 ). This provides both stable physics as well as a proper benchmark.
I know that many prefer to use the 2nd or 3rd method, but I personally prefer the 1st one
Bollu
I am just guessing that one of your peeves with #3 is that you consider there is no reason to draw multiple times the same frame over and over.
If logic causes position changes, and that only happens say 30 times per second, then rendering faster than that is useless since objects will still appear to move only 30 times per second, even if the actual FPS is 200.
But #3 is more complex than that, and also requires care in implementing. My next tutorial will be about this since this also just appeared in some code my ex-coworker had me debug.
#3 allows all of the stability required by physics engines and other systems but allows as-smooth-as-possible a framerate as players desire. Making players think their games are running smoothly is a very important aspect, and FPS is often used as a benchmark, so limiting your FPS as mentioned in #1 is never desirable. It also causes inconsistencies in most implementations because programmers who implement it tend to forget that timers, sleeping, and friends are not reliable. Most naive implementations set a timer or somehow force a certain FPS, but forget that no matter how you do this, timers, sleeping, and even while loops are subject to the thread scheduler which may (and will 99% of the time) decide to delay your execution for a few nanoseconds because another thread is busy.
In naive implementations, by forgetting the above, you will be passing a fixed delta each tick, because you assume hardware is reliable and each tick represents exactly that delta. This is wrong and will never ever happen in real life. Your ticks will never ever be the exact same amount apart no matter how hard you try. Method #3 handles this fact.
#3 relies on a bit of experience though. Implementing it incorrectly will actually heavily hinder your performance as my ex-coworker discovered.
I am not going to explain the nuances of that now because it will be more efficient to make a post about it on my site and then post that here. This is a problem that pokes out its head very frequently so I would rather not explain how to do it correctly multiple times.
Just wait about 12 hours.
L. Spiro