Best FPS method

Hello,
What is the best method for frame based animations/games to get accurate FPS?
The two methods I've tried are:

setInterval(tick, 1000 / 30);

This works well but if the tick() function ever takes longer than the interval time they can begin to stack up on one another.

The second method I've tried is setTimeout from within the tick() function. The only problem I have here is the FPS drop a lot as each frame is tick() excuse time + frame timeout.

function tick() {
  setTimeout(tick, 1000 / 30);
}
tick();

Are there any other methods I can look at, like using the system time to decide when to next call tick()?

Since setTimout() holds execution off until timeout happens, it is not working. But your question goes in the right direction:

1. hold on to current time before invoking nextFrame() (assuming nextFrame() is the 'next' animation step)
   
2. invoke nextFrame()
   
3. on return from nextFrame() invocation, take time again and calculate you 'new' timeout. If it is negative - your nextFrame() execution took 'too logng' - set timeout to 0. (If you want to - smoothly - catch up with time you may keep late information and include it in subsequent calculations.)
   
4. (self)invoke tick(); in setTimout() with calculated timeout.
   
   

This works well if you do not have asynchronous stuff in you nextFrame(). But if you have, it is a bit more complex and you have to figure out a way of chaining within the callbacks. With a chaining approach you get the things most speedy done. Again, this has caveats: if you have only one thing going... if you have multiple asynchronous things going on that can end in different sequence than invocation sequence, you have to pass a shared control object to nextFrame(ctrl) and within that to every callback. In the callbacks the last operation is told about the current, particular completion, and the callback object knows if all has completed to invoke the next tick(). The control object resets itself before invoking tick() with setTimeout() and calculated timeout.

That's an interesting idea. I've also been looking at a similar method where you removed any frame based animation and only use time based animation. So instead of for example "5 spaces per frame" you use "150 spaces per second" and the code decided how to move the item each frame output.

Here is a detailed article on JavaScript game loops and timing: http://www.isaacsukin.com/news/2015/01/detailed-explanation-javascript-game-loops-and-timing

It is usually better to keep independent 'things' independent - in their own 'threads' (timeout or event driven) - and only manage the coop of dependent 'things'.

Nice part about Javascript's single-threaded-ness and the available immense computing power makes 'logical multithreaded' things quite simple. Last but not least - even if you have a multi-core - most software is executed single-threaded anyway... nothing conceptional really new for over 50+ years... just more efficient and more transparent for the application developer, more 'plumbing' moves into the platform/containers. So fare I was not much in gaming but more in efficiently rendering large pages where many resources have to be retrieved from different places and the user experience should still be smooth...

Because MC/IoT/Espruino has even more challenges - almost all communication with any peripheral is callback oriented - I built for myself something like a global controller that allows sequencing of tasks of callback driven components. The challenging part is that 'you have to wait, but you do not know how long'. Of course you can define 'frames' (to show the similarity of the challenges) of 5 minutes or longer for completion of, for example, creating a connection, and after that one to get data across that connection, etc. But what do you do if after waiting overly long things still didn't complete, or worse, failed right away, but only now action can be taken...

Espruino's E.on("init",function(){...}) is kind of an approach to have independent components 'get going'. But as said: independent, and therefore is only of very limited use. Most of the time, the components have very little independent function, but have to line up - in sequence - with one another. So how do you manage that and still have componentized, reusable software... Promises is the solution, but it get's pretty heavy... t0 heavy or MCs, and what I missed the most, is more detailed error/exception handling and retry options. One of my implementations put special focus on retry.

All is still a work in progress... and to have a a single universal component that provides platform with all functions is a challenge.