DoG Wrote:Not sure where that is coming from, but that statement isn't universally valid, and most certainly you can get much finer granularity from a timer, depending on the environmental factors.

Also, I think there's a confusion about what I am saying.

There's two things:
A) use of a second thread
B) use of a custom loop

You can do A) without doing B) by instantiating a run loop on the second thread. Since that run loop would not handle *any* other source than your timer, it should fire at the exact expected intervals, as long as your callback doesnt take too long.

If you have congestion on the main thread, then going to a second thread will help will help with the apparent jitter of the updates, but it will also increase latency, since whatever happens in the main thread and your game thread will have to be executed in parallel, so both tasks will take longer than when running alone. So there's always a trade-off.

A custom loop is a better choice ... it is dead easy to code and having another thread just for handling timing is a waste.

After all, your game is driven by its own update loop and thus you can get just about perfect timing ( if you are done ahead of time , simply forward any further processing to the default loop for whatever amount of time you have left. )