Custom Engine Game Loop?

[codingbutter]

Hi all I'm CodingButter

I have been developing a 2d game engine from scratch. I wanted to get some opinions about the tick and render loops. I currently have my render loop executing as fast as requestAnimationframes will let me. And I've also trigger my ticks with setTimeout. I've noticed by doing this I am consistently getting 200 ticks per second. I was wondering what the drawbacks would be for using setTimeout in this way. I personally don't seem to see anything but improvement to my game behavior. but I'm sure there is something big i'm overlooking performance wise. Any thoughts. Also Excited to find a community to chat with.

Codesandbox.io Link Twitch Discord

 

[TadMakesGames]

For your loop you should implement a frame rate.

var throttle = 0;

var frameRate = 60;
var frameTime = (1000/60) * (60 / (frameRate) ) - (1000/60) * 0.5;

var progression;

loop(time) {

       if(throttle === 0) throttle = time;
       progression = time - throttle;

       if(progression >= frameTime) { //progression is going to be 16.something in this case,
             //and frameTime is about 8 when frameRate is 60. Less than 60 will slow the loop.

             //do loop stuff


             throttle = time;          

      }   

      requestAnimationFrame(loop);

}

 

[b10b]

Welcome @codingbutter!

As you may know, whether using setTimeout or requestAnimationFrame the delivered framerate will be limited based upon what is attempted to be done between each redraw (because single thread).  Hitting the CPU bottleneck was more commonplace a few years ago for HTML5 games, these days less so but it's still relevant to the design question.  So a follow-up question might be whether work(ers) can be done off the main thread - and would that help anyway?  Another question is whether inputs can (or should) be resolved on update, or whether they should be resolved (potentially multiple times) between updates.  But back to the original question ... RAF is synchronised with the display, it's almost perfect for a main render loop.  setTimeout may, theoretically, trigger faster, but to what actual benefit (if it can't be seen?), and at what cost in terms of clean up and resync?  There's nothing stopping running the main loop multiple times within a single RAF call - or more usefully running some aspects of the game logic that benefit from fidelity (e.g. physics iterations).  But most physics engines do that by default.  So ... how about embrace RAF and then dig into the finer points on workers, inputs, iterations, etc?